What makes a system legacy
Age is not the test. Software written fifteen years ago that is understood, documented and cheap to change is not legacy. Software written three years ago that nobody dares touch is.
The working definition is simpler: a system is legacy when the cost of changing it is out of proportion to the size of the change. Everything else — the old framework, the unsupported database, the developer who left — matters only because of the effect it has on that number.
Legacy system modernisation — legacy modernization in American English — is the work of bringing that number back down. Software modernisation of this kind is not automatically the same thing as replacing the software.
There are four options, not two
The conversation usually collapses into rebuild or do nothing. Two other options sit between them, and they are often the right ones.
- Leave it alone
- The system is stable, the business is not asking it to change, and it is not a security liability. This is a legitimate answer and is under-used. Software that is finished does not need a project.
- Maintain and contain
- Keep it patched, monitored and secure, and stop adding to it. New work goes elsewhere. Buys years of time cheaply, and is the right first move when the rebuild case is not yet proven.
- Modernise in place
- Replace parts of it while it keeps running — one module, one integration, one screen at a time. Slower per unit of work, but the business never stops and each step is reversible.
- Rebuild
- Start again with the same business need and a new implementation. The most expensive and the riskiest, and occasionally the only honest answer — usually when the platform itself is finished, not merely dated.
Which legacy modernisation approach fits
There is no single right way to modernise legacy systems. The decision is easier if you stop asking how old the system is and start asking what it is costing you.
Maintain and contain fits when the system does its job, changes are rare, and the complaints are about appearance rather than function. Nothing here justifies a project.
Modernise in place fits when specific parts of the system generate most of the pain. If four fifths of your change requests touch one module, you have located the problem and it is not the whole application.
Rebuild fits when the platform underneath is genuinely at its end — a runtime with no security updates, a vendor that has gone, a database that cannot be licensed any more — or when the business the software models has changed so completely that the data model is wrong rather than just old.
A system that is expensive to change everywhere, with no concentration of pain, usually has a documentation and knowledge problem rather than a technical one. That is cheaper to fix than either modernising or rebuilding, and it is worth ruling out first.
Why rebuilding is the wrong default
Rebuilding is attractive because the new version exists only as an idea, and ideas have no edge cases. The system being replaced has fifteen years of them, most of them undocumented, many of them load-bearing.
The second problem is duration. A rebuild delivers nothing until it delivers everything, which means the business runs two systems, funds two teams and freezes the old one for the length of the project. Meanwhile competitors ship.
The third is that rebuilds re-learn expensive lessons. The strange rule in the pricing logic is usually there because of something that happened, and the person who remembers what has often left. You find out which rules mattered when the rebuild reaches production without them.
None of this makes rebuilding wrong. It makes it the option that has to be argued for, rather than the one everyone assumes.
Modernising in place, in practice
Legacy application modernisation of this kind works by putting the new system in front of the old one and moving functionality across a piece at a time. Traffic is routed to whichever implementation currently owns that piece, and the old system shrinks as the new one grows.
The value is that every step is small, releasable and reversible. If a step is wrong you route back and fix it, rather than discovering the problem two years in.
The cost is real: for a period you run two systems and the routing between them, which is more complexity than either alone. That is the price of not stopping the business, and it is usually worth paying.
It also changes the funding conversation. Incremental modernisation can be paid for out of ordinary development budget alongside feature work, where a rebuild needs a capital decision and an executive sponsor who stays in post.
What waiting actually costs
Deferring the decision is itself a decision, and it has a price worth naming.
Change gets slower every year, so the same roadmap costs more to deliver. Recruitment gets harder, because engineers are reasonably reluctant to spend years on a platform with no future. Security exposure compounds, since unsupported dependencies do not stop having vulnerabilities discovered. And the knowledge keeps leaving with the people who hold it.
None of these forces a decision this quarter. Together they explain why the systems that get rebuilt in a panic are almost always the ones that were left for one more year, several years running.
Questions to answer before committing
- What does a typical change cost now?
- Compare a small change today against the same change five years ago. If nobody can answer, that is the first thing to measure — the whole decision rests on this number.
- Where is the pain concentrated?
- Look at the last fifty changes and which parts of the system they touched. Concentration points to modernising in place; an even spread points elsewhere.
- What happens if you do nothing for two years?
- If the answer is that it keeps working and nothing is exposed, you have more time than the conversation suggests. If it is an unsupported runtime or a vendor that has gone, you have less.
- Who still understands the current rules?
- Whatever you decide, that knowledge has to be written down before those people leave. This is worth doing before the project rather than during it.
- Can it be funded incrementally?
- A plan needing three uninterrupted years and one sponsor is fragile. One delivering value each quarter survives changes of budget and management.