There is a quiet bias in the IT consulting industry that says legacy systems are, by definition, problems waiting to be solved. They are old; therefore they are risk; therefore they should be replaced. It is a comfortable position to take, particularly if you also happen to sell the replacement.
We take a different view. Some of the most reliable software running in British SMBs today was written twenty years ago, has been continuously refined since, and does its job better than any modern equivalent the team has demoed. Replacing it for the sake of modernisation is, in plain English, an own goal.
The honest test for a legacy system
Before deciding what to do with an older system, we walk clients through a short, deliberately unromantic test:
- Does it currently do the job the business needs? Not "could a modern system do it better in theory" — does this one do it now?
- Is it supportable? Can it be patched? Are the people who understand it still in the business or reachable?
- Is it safely contained? Network isolation, modern authentication in front of it, decent backups.
- Does it integrate with what it needs to integrate with — or can it be wrapped to do so?
A system that passes all four is not a problem. It is an asset most of the rest of the industry is too distracted to appreciate.
Keep, wrap, replace
For each system that doesn't pass cleanly, there are three honest options.
Keep means stabilising it: isolation, patching, monitoring, documentation. Often the right answer for a year or two while bigger decisions are made.
Wrap means adding a modern shell — APIs, reporting, a friendlier front end — so that the legacy engine can keep earning its keep without dragging the rest of the estate backwards.
Replace is the right answer when the system genuinely no longer fits, when support has truly evaporated, or when the business model has moved past it. Replacement is expensive, slow and risky; choose it on evidence, not on style.
The cost of moving for the wrong reason
We have watched a few SMBs spend several hundred thousand pounds replacing a legacy ERP that everyone was quietly happy with, because the board had absorbed the message that "modernisation" was overdue. The new system, two years in, did roughly what the old one did, only slower and with more outages. The lesson is not that modernisation is bad. It is that modernisation, like any other large IT decision, deserves a proper business case.
Legacy, treated with respect, is often a strategic advantage. The systems that do not change every eighteen months are sometimes the ones that have given the business its competitive edge for the last decade. Worth keeping in mind before the next refresh cycle.
