Should You Upgrade or Replace Your Current Software?

Software often fails to meet its users’ needs over time, whether it’s the result of changing requirements or the availability of a better product. This event presents an opportunity for improvement that should minimize risk while maximizing return on investment (ROI). In particular, you’ll need to decide if your current software can do its job with some modifications, or if it’s time to buy a new product. This process is particularly challenging for enterprise software, which typically includes many discrete applications.

The decision between upgrading or replacing software ultimately comes down to a comparison between how well the current software meets its requirements, and how well a new product could do that job. The first step in this process is to determine that the software needs to be modified at all. Next, you need to define the software’s key requirements that it must meet. Finally, a comprehensive analysis of those requirements will help you decide whether to upgrade replace the software.

Signs that Software Needs to be Updated or Replaced

The process of designing your current software undoubtedly involved a great deal of planning. The designers then handed this plan off to another team to develop the software, which then delivered it to another team to maintain it. Your organization has probably grown since then, resulting in many changes to the software’s original purpose. Furthermore, your IT architecture may have devolved from a coherent expression of your organization’s needs into a series of independent decisions on each of its components.

Determining if this is the case is the first step in deciding whether your software needs to be changed at all. The following telltale indicators of aging infrastructure can help you decide if this is the case.

Redundant Applications

All applications should solve at least one business problem for that organization. Over time, it’s only natural for organizations to accumulate more applications, resulting in multiple applications performing the same function. This situation often occurs when the functions of these applications overlap, rather than having different applications that perform exactly the same tasks. Eliminating some of these applications is usually difficult because the applications also support unique functionality. This problem is especially common in modern enterprises using hybrid and multi-cloud architectural models.

Regardless of the redundancy’s cause, the resources needed to support it are being wasted. The impact of redundancy on the architecture is that it drives the need for more interfaces, and platforms. The direct business impact is that these redundant applications take resources away from other activities that could create value, such as the cost of unneeded software licenses.

Collection of Point Solutions

A point solution is an application that performs a specific task. It usually performs this task very well, but the degree of specialization also means that workers must use many point solutions to do their jobs. This situation results in lost time due to multiple logins and duplicate data entry unless the organization builds the interfaces needed to connect all of these point solutions. Fortunately, the increasing use of edge computing and open-source solutions can relieve the problems caused by point solutions to some extent.

The primary impact of point solutions on IT architecture is that they drive the need for more interfaces and platforms. In many cases, they also increase manual rekeying of data. The direct business impact is that point solutions slow business processes, thus increasing operational costs.

Obsolete Technology

Software still requires maintenance even when it meets your current business needs perfectly. Even if those needs never change, inevitable technological advances and loss of support means that the software will eventually lose its value. Assume for this example that your software is written in a version of Visual Basic that Microsoft hasn’t supported in years. That means your software can’t connect to a more recent version of SQL Server. Furthermore, your software won’t even run on a version of Windows that has drivers for the printers you use.

One way the other, you’ll need to spend money to get the software to do what you need to. Obsolete technology is more difficult to maintain, especially when it needs to interface with more recent infrastructure components. This situation increases maintenance costs and hampers your organization’s ability to adapt to changes in business requirements.

Complex Integration

The integration of applications within an enterprise generally becomes more complex over time as the number of applications increases. One common solution to this dilemma is to use some type of middleware like enterprise application integration (EAI) system to create and maintain the necessary interfaces. An EAI system can typically solve easy interface problems, but more difficult problems are another matter. Developers usually end up rebuilding the same complex interfaces within the EAI system.

While this complexity is now transparent to the users, it still exists in the architecture and is just as difficult to maintain. Furthermore, this complex integration requires money and IT resources to maintain, which organization could put to better use on value-creating activities.

Excessive Interfaces

Passing information from one application to another or synchronizing data between the two applications requires an interface. Regardless of the specific reason, adding applications generally increases the number of interfaces you need. However, it also increases the complexity of your architecture, resulting in more time spent building and maintaining interfaces that could be used to add functionality. The architectural impact of more interfaces is more app maintenance, while the business impact is loss of resources from value-creating activities.

Workarounds

A workaround in software is a solution that provides the desired functionality, but not in the efficient and effective manner possible. It also requires less effort to develop than a proper solution, at least in the short term. Workarounds are a routine feature of legacy software due to a variety of causes such as a developer that lowballed a project or a development deadline that was too aggressive. Sometimes, the ideal technical solution compromises the business case for the project. The result of these events is that a system may eventually be held together with workarounds, which may go unnoticed for a long period of time.

Workarounds solve immediate problems at the cost of long-term system stability. However, they also increase the cost of software maintenance services, staff training and complexity of subsequent applications affected workaround.

White Papers

A large number of white papers is a consequence you might not expect of outdated software. This occurs when an enterprise assembles an architectural management group to identify the root cause of their software problems. They may even hire some outside experts who often produce many white papers explaining the changes IT needs to make to recover the software’s lost productivity. However, these recommendations often involve using the expert’s proprietary solution.

The common result is that everyone ignores these recommendations, wasting the salaries of the people in the architectural group. It also increases employee cynicism about this latest management fad.

Redundant Data

Applications often need the same data, even when their functionality is quite different. The general solutions to this problem include storing the data in one database, which isn’t always practical. Another possibility is for each application to store data in a separate database which can become messy when you try to synchronize it. Users can also reenter the data manually, which tends to be highly time-consuming.

The primary architectural impact of redundant data is that it increases the need for more interfaces, and possibly more manual data entry. The direct business impact of this problem is the effort needed to synchronize data, which can still result in discrepancies between databases.

Manual Re-keying

Manual re-keying of data is usually the most obvious consequence of poor architecture, although it isn’t necessarily the biggest one. Hiring temporary workers to enter data is expensive and prone to errors due to the monotony of this task. These errors result in applications using different data and therefore providing different results. It also diverts resources from value-creating activities.

Requirements Definition

Once an organization recognizes that its software requires improvement, it must define the requirements of that application. This process consists of creating a list of requirements and then rating the importance of those requirements, which together form the software’s unique requirement profile.

Existing software typically provides much of the functionality you need already, even if it needs to be replaced. Developers can then reverse engineer features from this software to create the initial requirements list. They can also use this technique on the updated software and potential replacements to complete the requirements list. This step helps capture technological innovations, which may include requirements you don’t know you need.

Creating Requirements

Creating the requirements for software that doesn’t yet exist is a far more challenging task than determining if existing software meets your requirements. Regardless of which approach you use, well-written requirements are essential for minimizing risk during the software selection process. In addition to failing to select the best software, poor requirement descriptions can cause you to miss deadlines, reduce your ROI in the software and even fail to solve the business problems that your current software is causing.

A requirements description must provide the context of that requirement to be useful. Developers often record only the requirements without providing any other information such as the reason for that requirement. This practice often results in a requirement that no one else can understand. Sometimes, not even the developer knows the reason for the requirement if enough time has passed since writing it.

Avoiding these problems when writing requirements takes some practice, but it’s important for the requirement to be understandable without supporting documents. This is especially important when collecting requirements in a library and reusing them in future software evaluations, which is common practice for many enterprises.

Writing requirements is a completely separate task from deciding the importance of those requirements. For enterprises, members of the IT department typically write requirements for software evaluations. However, those writers may not understand the requirement’s relative importance since they aren’t knowledgeable about the organization’s business areas. A team composed of members from these areas will then rate these requirements in a separate step.

Comprehensive requirements profile must have sufficient breadth and depth. Breadth refers to the software’s functional areas, which are often adjusted during the course of the project. Depth is the degree of detail in the requirements description.

Components

The components of a written requirement include an ID, title, description, and history. The ID must uniquely identify the requirement, even the title is changed. The title should be descriptive but short, preferably no more than six words. Readers should be able to use the title as an effective reference to that requirement in conversation. The history allows readers to trace unexpected changes to the requirement back to their source.

The good requirement description expands on the title and removes any ambiguity from it. The description should explain the reason for the requirement in general terms and how developers might implement. Descriptions that contain acronyms or concepts that may be new to the reader should include links to resources for learning more about them. These resources may be general references like Wikipedia or more technical publications. Instructions on how to use the requirement are also a common part of the description.

The following example shows a well-written requirement with these components:

Figure 1: Software requirement example.

Tools

The IT team members with the right software requirements are more likely to have technical expertise than writing skills. Tools like grammar and spell checkers can identify many mechanical writing errors. The free version of Grammarly is a good choice when developers are capturing requirements with a browser-based tool.

Text-to-speech tools can help with additional problems such as awkward phrasing, poor word choices, and incorrect sentence structure that grammar checkers don’t address. These tools are available from multiple sources, including the Quick Access toolbar in Microsoft Word. You can also use the Speakit! tool from the Chrome Web Store if you’re using the Chrome web browser.

Rating Requirements

The relative importance of software requirements can vary greatly, but some general trends apply to many cases. For example, the following 2019 survey shows the common reasons for enterprises to replace their Environment, Health, Safety & Security (EHS&S) systems.

Figure 2: Important User Requirements

This figure shows that 90+ percent of companies replace their EHS&S software because they’re dissatisfied with its overall performance, customer support, user engagement and flexibility of customization. In this survey, integration with IT systems and real-time metrics tracking is important to the majority of users. Additional features with relatively high importance include user-friendliness, mobile accessibility and the ability to customize.

The rating phase of defining requirements includes identifying the group that wants each requirement, why they want it and how important it is to them. This process will result in a unique requirements profile for each organization. An incomplete requirements profile is one of the most common single causes of failure for selecting enterprise software.

Developers will use the requirements profile to generate requests for information (RFIs), which attempt to determine how well each potential replacement product meets the requirements profile. They also allow developers to compare those products with the existing software, so they can decide if they need to replace it. However, RFIs require a significant effort from vendors with little chance of a payoff since the potential client hasn’t even decided to replace the existing software at this point.

It’s therefore essential to make the process of providing the RFI as easy as possible for vendors, so they’ll be more likely to respond. For example, vendors should be able to answer questions with a drop-down box rather than writing text. Furthermore, the requirements on the RFI should be limited to showstoppers, which is typically 10 to 20 percent of all the requirements. This approach minimizes the preliminary work that the vendors need to perform since a detailed analysis of the requirements won’t be needed until the request for proposal (RFP).

The rating scale below shows a widely accepted method of rating a software product’s ability to meet a requirement of the scale of 0 to 6:

Figure 3: Product rating scale

Once vendors return their RFIs, you should use these responses to capture each product’s ability to meet the requirements in a single number known as the Fit Score. You can then use the Fit Score to rank all of the products. Design the Fit Score to use a scale from 0 to 100, such that a score of 100 means the product fully meets all requirements without configuration or compromise.

Scoring

At this point, you now have the information to determine if you should upgrade or replace your existing software. In particular, you can compare the candidate products to each other, the existing software, and the requirements profile.

Assume for this example that your current software scores 65 percent, but you expect it to score 75 percent after upgrading it. However, the best replacement product scores 85 percent out of the box. In this case, you have a strong argument for replacing the existing software.

On the other hand, if your existing software already scores 75 and the best replacement product only scores 80 percent, it probably isn’t time to replace your software yet. Even though the replacement has a higher score, it isn’t enough to justify the investment at this time. In this case, you should retain the evaluation so that you only need to update it when you reevaluate your software in a few years.

Summary

Businesses often delay making changes to their business software, whether it’s upgrading existing software or replacing it. This course of action is easy to justify since doing so avoids upgrade or implementation costs, including training and reorganizing business processes. However, it also deprives organizations of new features that could increase productivity and insight into business processes. In addition, failure to upgrade or replace software increases security risks that could be mitigated with patches.

The arguments for upgrading include running software that isn’t the current version, since good software vendors will continue developing new features to accommodate changing needs. The vendor may have released new features of your current software, provided your software is in the vendor’s current upgrade path. These changes are especially useful when they permit integration with other software that your organization is currently using. This integration has the potential for eliminating redundancy and human error due to data re-entry.

Replacing your existing software is more likely to be the best choice when your organization has grown to the point that it’s exceeding your software’s current capabilities. Software that no longer has a roadmap is also a strong candidate for replacement since the software will be unable to meet future business challenges. Direct communication with your current vendor can determine if they’re unwilling to make these changes or if they’re simply unaware of your needs.