Legacy technology: “an old method, technology, computer system, or application program of, relating to, or being a previous or outdated computer system”.
“We’ve been using the same technology for 25 years. It’s worked well for us in the past, but over the years, its performance has been steadily declining; we’ve encountered an increasing number of issues. At first, nobody wanted to believe it, but all the signs were there: bugs, bad user experience, missing functionality, huge costs, and massive delays… Although everyone agrees that the system is flawed, nobody is really sure what to do. Some say we should move on, and others say it’s not financially viable since it’ll require a whole new investment of time and money. The board is split, what should we do?”
Can you relate to this? Many business owners are in this situation today; they know that their legacy technology has issues, but they’re not sure what to do about it. In most cases, these are the 3 available options:
- Fix the legacy technology
- Pay for a solution add-on from a third-party company (e.g. integration)
- “Rip and Replace”: remove everything and start from scratch
In this post, I won’t tell you what to do, but I will give you information that may help you make a more informed decision regarding your legacy technology.
“OK, but why should I even consider replacing my technology?”
First of all, why are we even talking about replacing legacy technology? Let’s look at some of the reasons why replacing a legacy technology may be a good idea:
High technical debt
When it comes to legacy systems, it’s important to understand technical debt. Techopedia defines technical debt as “a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer”.
Every software has a direct and an indirect (i.e. implied) cost associated with it. The direct cost is what you’ve actually paid for it initially (in time and money), and the indirect cost is how much you may be paying for it in the future (i.e. for upgrades, repairs, maintenance, etc.). For example, a cheap car may have a low direct cost but a high indirect cost for all the money you need to spend on maintaining it in the future.
In terms of technical debt, the direct cost of technology is the loan, and the indirect cost is the interest on that loan; the interest is the amount of time and money necessary to fix/maintain/upgrade the technology. For example, a low-quality technology may be a small initial loan, but one with a high-interest rate; initially, it has a relatively low technical debt, but over time it will gain debt as the customer will spend time and money to fix it.
Of course, every software has technical debt; that’s unavoidable. The more important question is: which software (or combination thereof) will have the least?
Looking at the 3 options outlined above, which one is least likely to accrue technical debt?
To figure that out, we must understand the factors that affect technical debt:
1. Age
The older the solution, the more fixes and upgrades it will require (and hence technical debt). In addition, as a rule, solutions gain technical debt over time; so the older a solution, the more debt it has on average and the more it will gain in the future.
2. Level of dependency
Every software has components; some or all of these components are linked together. When components are linked they are said to be “dependent”; if a linked component fails, the others will too. The level of dependency of software varies based on how closely linked each of the components are; a software in which many components are linked to one another has a high level of dependency, whereas one whose components are only linked to a few other components has a low-level dependency.
Dependency is linked to technical debt because it affects the ability of a software to make changes or repair issues when they arise. If a problem arises in a highly dependent system, it’s harder to identify where the problem is coming from (because each component is linked) and harder to fix because programmers need to repair every single dependent component instead of just a few.
The higher the dependency, the higher the debt.
3. Compatibility with other systems
Often, a software will be paired with another to increase or add functionality for clients. For that to occur, the technologies must be able to “communicate”; they must be able to send and receive information to/from each other in a language and format they both understand. On average, it’s much more complicated for older systems to be able to do this than newer systems; it takes a lot more time and money to accomplish, hence the higher technical debt.
4. Ability to fix, maintain and/or rework
Every software will need to be fixed, upgraded and/or reworked eventually. How easy it is for a company to do that is crucial.
5. Quality of code and software design
The lower the code quality, the higher the technical debt. Older systems tend to have lower code quality relative to newer ones because of modern programming and software design.
So, let’s evaluate the 3 options:
- Legacy technology
- High initial debt (i.e pay more in the short-term)
- High interest in the future (pay more in the long-term)
- Solution add-on from a third-party company (e.g. integration)
- Low initial debt (i.e pay less in the short-term)
- High interest in the future (pay more in the long-term)
- Remove everything and start from scratch
- High initial debt (i.e pay more in the short-term)
- Low interest in the future (pay less in the long-term)
🎉 Option 3 is the winner! 🎉
High maintenance costs
To continue being relevant, legacy systems must be updated regularly. However, unlike newer technologies, older ones are not easily updated; it takes developers much longer to update and maintain older systems because they tend to have more system dependencies than newer ones. Not to mention, older systems require more frequent updates and maintenance than newer systems.
Legacy systems are not flexible
Customer needs change over time; a good technology needs to be able to adapt when new situations arise and changes are called for. Because of the reasons stated above, older systems are less capable of adapting.
Lack of integration
Many modern systems have the flexibility to integrate with other systems, simply by virtue of the way they were designed. Older ones don’t; this is because their programming code and design does not match that of the newer ones. Generally, integrating new systems is difficult for legacy technologies, requiring much time and money.
Data breaches
With outdated legacy technology, the risk of data breaches is very real. In addition, security upgrades are often rare, and many are difficult to access for legacy solutions.
The recent ransomware attack on one of the largest and oldest workforce management vendors in the world, caused thousands of organizations to shut down their time tracking, scheduling and payroll operations during the holidays, their busiest time of year, leaving millions of workers uncertain about their next paycheck, and HR departments scrambling and rethinking their oftentimes outdated operations.
Costs of fixes/improvements
As business needs change over time, technologies must change as well. With legacy solutions, fixes, improvements and/or redesigns are usually very costly and take very long to complete.
Compliance penalties
As the business landscape changes over time, so do required compliance standards. To prevent extremely costly legal trouble due to non-compliance, existing systems must have the right measures in place to ensure that their customers remain compliant at all times. Since these measures must be added to older solutions, this will cost you even more time and money.
Effect on employees
Nobody experiences the effects of outdated legacy technology more than the ones who use it the most: your employees. Not only does their productivity suffer, their morale does too. Keeping an old solution despite repeated negative feedback also sends an indirect message to your employees that you think they’re not worth investing in. Don’t underestimate the effect outdated technology can have on your employees.
Effect on clients
With reason, clients do not and will not tolerate technology-related issues. If a technology does not work properly or is not up to par, they’ll go elsewhere; they will not think twice. Customers do not care why it’s not working (that’s your problem), they just want it to work.
Bad reasons not to consider a “Rip and Replace” solution
Some people don’t even want to consider new solutions . Why? Here are some of the most common reasons not to:
💬“Well, we’ve already invested so much time and money into this solution.”This is a tendency we all have; it’s called the sunk-cost fallacy. The sunk-cost cost effect is “the general tendency for people to continue an endeavor, or continue consuming or pursuing an option, if they’ve invested time or money or some resource in it”.
In other words, this is like saying: “We can afford to pay another $100,000 for our legacy technology to get fixed; after all, we’ve already invested $10 million and 6 years into implementing it.” The problem occurs when people justify present investments of time/money/effort by their past investments, even if they have (or are) providing a negative return.
💬 “It’s going to take too long to implement and/or learn the new system.”All solutions take time to implement; your legacy technology took time to implement when you first acquired it. This is not a good reason to reject a new solution outright.
💬 “It’s too risky.”Really? In many cases, sticking with a legacy technology is more risky than switching to a new one. If you’re worried about risk, researching and trying a prospective solution before buying is a good way to measure risk.
“What should I consider when looking at a new solution?”
When considering a new solution, keep in mind these 6 factors:
- “Is it functional?”
- Does it actually do what it purports to do?
- Does it work well?
- “Does it meet my needs?”
- “Is the solution flexible?”
- In other words, can the solution meet my needs if they ever change in the future?
- Can the solution grow with me?
- “Does the vendor understand my needs well?”
- “How long will it take to implement?”
- "Can I trust this company?"
- Are they reliable? Can they deliver on their promises?
Key points to remember
Before investing your money in a solution, consider these important points first:
- Do your research beforehand.
- Test before you buy.
- Focus on the item, not the packaging.
When considering a new solution, it’s easy to be persuaded by the “exterior” of the solution; new tools and gadgets, flashy icons and buttons, the design, etc. However, it’s not about the bells and whistles; it’s primarily about whether the solution meets your needs, whether it works and whether it’s reliable. When considering a new solution, stick to the most important factors: cost, functionality, effect on productivity, efficiency, etc.
- Remember that it’s not only a business decision
Although considering the business impact of a solution is important, it’s not the only thing that is. Businesses are run by people, and people will be using the technology; hence, you need to consider the user’s experience. Ask yourself: “Is this something that my employees and/or clients will actually enjoy using?”. In other words, don’t forget the elements relating to the user experience; user interface, usability, etc.
- When evaluating a solution, be aware of your own biases.
If you’re going to reject a solution, reject it for the right reasons.
It’s so easy to turn something down for the wrong reasons. As previously mentioned, the pull of our own bias is deceptively strong; most of the time we aren’t even aware of it. Our tendency to want to stick with what’s familiar to us (i.e. “This is what I’ve always used!”) and to overvalue something because we’ve already invested time/money into it often blinds us to real possibilities. Be aware of these next time you’re considering a new solution.
Moving forward, I hope you will consider the above points. Fixing a legacy technology or adding a third-party solution may be good in the short-term, but not always in the long-term. Sometimes, it’s best to rip and replace the existing infrastructure, and start anew.
Think about it, you will need to replace your legacy technology eventually, right? Maybe this is the right time. Will you consider it?
COMMENTS