Organisations running older software tend to hold one of two views. Some say that if it is not broken it should not be fixed. Others want it gone, but cannot make a business case that persuades the people holding the budget. Both views miss that there are three options, and the one most often overlooked is usually the right one.
What makes a system “legacy”
Age alone does not. A fifteen-year-old system that fits the business and can be changed safely is simply an established system. It becomes legacy when one or more of these is true:
- the platform it runs on no longer receives security fixes from its vendor;
- nobody available understands it well enough to change it with confidence;
- changes that ought to take days take weeks;
- staff keep spreadsheets and side systems to make up for what it cannot do;
- it cannot connect to the other systems the business now uses.
Each of these is a separate problem with its own remedy, which is why “replace it” is too blunt an answer.
The three options
Keep maintaining it
Right when the system still fits the way the business works, runs on a supported platform and has people who can look after it. The work is steady upkeep: security updates, fixes, small changes and a yearly review of where it stands.
It is also right when the system has only a short life ahead. If a merger or a change of process will retire it in two years, heavy investment makes no sense.
Modernise it in stages
Right when the system is worth keeping but parts of it are holding you back: an out-of-support database, a user interface that only runs in an old browser, a codebase with no tests. Those parts are replaced one at a time while the system stays in use.
This is the option people overlook. It preserves the years of business rules built into the existing system, spreads the cost, delivers improvements as it goes and can be paused after any stage.
Replace it
Right when the system no longer matches how the business works, when a packaged product now does the job well, or when the source code is lost and the system cannot be changed at all.
Replacement is the most expensive and the riskiest of the three. The old system has to be kept running until the new one is complete, and the new one has to rediscover every rule the old one quietly enforced.
A checklist for the decision
Count how many of these are true.
Signs you should keep it:
- People rely on it and seldom work around it.
- Everything it depends on is still in vendor support.
- A team or supplier can change it safely.
- The process it supports is specific to your business.
Signs you should modernise it:
- Some of what it depends on is out of support, or soon will be.
- Only one person can change it, or nobody can.
- Small changes are slow and risky.
- It is deeply connected to other systems, so swapping it out in one go would be dangerous.
Signs you should replace it:
- Much of the real work now happens outside it.
- A packaged product would do the same job.
- You do not have source code that can be built.
- The data in it cannot be trusted.
Our ten-question check works through the same reasoning and gives a recommendation.
Making the business case
A case for change that rests on “the system is old” will fail, and deserves to. A case that works puts numbers on specific costs:
- Risk. Which components are out of support, and what would an incident cost? The end-of-support dates for common platforms are a starting point.
- Time lost. How many hours a week go on manual workarounds, re-keying and waiting for slow screens?
- Cost of change. What did the last three changes cost, and how long did they take?
- Dependence. What happens if the one person who understands it leaves?
Set those against the cost of each option. Very often the figures favour fixing the two or three things that hurt most over replacing everything.
If you do replace it
Three things are routinely underestimated.
Data migration. Moving years of data into a new structure takes longer than building the screens. Start it early and rehearse it.
Hidden rules. The old system does things nobody remembers asking for. Run old and new side by side and compare the results before switching.
People. Staff will need time to learn the new system, and the process around it will change. Plan for that as part of the project.
Getting an independent view
If you are unsure which option fits, a code audit gives you a written assessment of the system’s condition and a recommendation, at a fixed price. We describe how we approach each route under software maintenance and legacy software modernisation.