Age is not what makes a system legacy. 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. A working definition: a system is legacy when the cost of changing it is out of proportion to the size of the change. Modernisation is the work of bringing that cost back down, and it 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 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. It buys years cheaply and is the right first move when the case for a rebuild 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 riskiest option, and occasionally the only honest answer, usually when the platform itself is finished rather than merely dated.
Which one fits
Ask what the system is costing you, not how old it is.
- Maintain and contain fits when the system does its job, changes are rare, and the complaints are about appearance rather than function.
- Modernise in place fits when specific parts 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 can no longer be licensed) 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, so rule it out first.
Why rebuilding is the wrong default
The new version exists only as an idea, and ideas have no edge cases. The system being replaced has years of them, most undocumented and many load-bearing. A rebuild also delivers nothing until it delivers everything, so the business runs two systems and funds two teams while the old one is frozen. And 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 may have left.
None of this makes rebuilding wrong. It makes it the option that has to be argued for, not the one everyone assumes.
Modernising in place
The new system goes in front of the old one and takes over functionality a piece at a time. Traffic is routed to whichever implementation owns each piece, and the old system shrinks as the new one grows. Every step is small, releasable and reversible. The cost is real: for a period you run two systems and the routing between them. It is the price of not stopping the business, and it can often be funded from ordinary development budget alongside feature work.
What waiting costs
Deferring is itself a decision. Change gets slower every year, recruitment gets harder, security exposure compounds as unsupported dependencies keep gaining known vulnerabilities, and knowledge keeps leaving with the people who hold it.
The full article is on the Cognivise blog. If you are deciding what to do with an ageing system, planning and technical advice starts with an honest look at its current state.
Top comments (0)