As a custom software development company, you’d expect us to encourage you to replace your legacy system, because, of course, we can build you something better! But that’s not always the best course of action. In particular, we don’t want to be involved in projects that waste our customer’s time and money.
In this piece, we’ll look at the pros and cons of keeping a legacy system to help you make a more informed choice.
When considering replacing a major system, a good question to ask is: What’s the revenue tied to rebuilding or replacing a system? Is it going to cost more money to replace than a new system would bring in?
Sometimes replacing an old system simply isn’t a priority because there are other projects that have more value tied to them. There are new systems you could be focusing on that can bring in revenue streams or increase the company’s overall productivity, for instance.
If you continue to allocate a smaller amount of your budget to maintain the legacy system while putting more of your budget into something that has more value, then you’re keeping your engine running while upgrading other parts of your tech stack that will better serve your company.
However, if your company’s revenue is taking a hit because of the system, that’s another scenario altogether.
Routine maintenance is one thing, but unfixable flaws are another. If the system simply doesn’t have the functionality to support your company and the functionality cannot be added, perhaps it is time to consider replacing it.
Signs this is the case:
- Your developers are getting buried by service requests and can’t focus on other projects.
- Your employees are consistently losing time and money because of the system’s flaws at a rate that dramatically outweighs the time and cost it would take to fix it.
- If it’s a public-facing system that your customers hate, and they’re leaving the business because of it.
Another way you could be losing revenue on an old system is if it’s getting in the way of major upgrades, such as integrations, modern browser or mobile support.
If you’re losing revenue or customers or the system creates extra strain on employees (or a loss of productivity), then it’s probably time to replace it.
Summary:
- Keeping legacy system allows you to focus on other projects that can increase revenue or company productivity.
- Legacy system has flaws that are hurting revenue or productivity.
What have you invested in the system already? People often come to us asking our opinion about what it would cost to replace their legacy systems. In many cases, these are twenty-plus years old and robust with decades-worth of feature building and debugging. When we respond honestly, probably a million bucks, we get a lot of shocked faces in response.
Here’s an example of how this works:
| Developer spent 75% of their time over two years developing the system and 30% of their time over the next 18 years upgrading and maintaining it (Ave salary: 90K) | $621,000 |
| Supervisor spent 30% of their time over the first two years and 5% of their time the next 18 years managing system development (Ave salary: 90K) | $135,000 |
| Training manager spent on average 10% of their time over 18 years learning system & training employees (Ave salary: 60K) | $108,000 |
| 2 support staffers spent 2% of their time over 18 years assisting employees on the system (Ave salary: 60K) | $43,200 |
| Total spent on employee labor on system | $907,200 |
Beyond the financial aspect, consider the accumulated human knowledge of the system and the technical capacity of a system that has had years of work put into it.
Well-built older systems do not age like older cars.
When a car is getting up there in age, there are more and more mechanical issues. Owners have to weigh what they’ve spent on the car versus the cost of keeping the car running. But with an older system, it’s very possible to have a thirty or forty-year-old system that’s perfectly reliable and fast. If it’s well-built to begin with, then it hasn’t gotten slower. There is mainframe software out there that is super robust.
With older systems, you’ve had years to debug the system and work out the kinks; whereas newer systems will absolutely be buggier and less robust.
But there’s one way that the old car analogy really fits: for many older cars, it can become increasingly difficult to find mechanics that know those types of cars well. Similarly, it’s likely that your legacy system was developed in a language that fewer developers are comfortable with. And even when there is a programmer on staff well-versed in that old-school language, the languages themselves are slower to develop in. So any upgrades you want to make will probably take longer than it would in a newer system.
If the system doesn’t need major developments, is there someone on staff that can simply maintain the program with minimal effort?
(Another possibility is to outsource to a company like ours that are experienced in maintaining legacy systems).
Summary:
- Money and time investment, years of feature development and debugging are hard to replace.
- Legacy systems are more difficult to improve on and support.
Alternatives to an All-Out Replacement
Sometimes the answer isn’t an all-out system replacement. If you’re not losing money on the system, you have staff that can maintain the system with minimal effort, and there are other projects you’d like to prioritize, consider alternatives such as:
- Developing a separate mobile app (in situations where a system isn’t mobile-compatible). This can be a cheaper alternative than an all-out system replacement.
- Only upgrade parts of the system if it’s technically doable and can help the system meet your needs for a couple of years, it can be more cost-effective than replacing the entire system.
- Integrate with another system that can add needed functionality.
How We Can Help
If you do decide it’s time to replace your legacy system, check out our custom development services.
But if you’ve come to the conclusion to hold on to it a bit longer, we also offer monthly maintenance plans for cheaper than the cost of an in-house developer.
