Insights
The instinct when a system becomes painful is to replace it, and replacement is often the most expensive, most disruptive and most risky option on the table. Sometimes it is right. Often something cheaper achieves most of the benefit at a fraction of the risk. Here is a framework for making that decision on evidence rather than frustration.
By Christopher Fagan
Before choosing an answer, be precise about the question. A system can be a problem for very different reasons, and the right response depends on which.
Leave the system as it is and manage around it. Legitimate more often than people admit, particularly for a stable system that works and simply is not liked.
Move it to modern infrastructure with minimal change. Addresses cost and some risk without touching the application.
Make moderate changes to modernise it while keeping its core. Captures much of the benefit of replacement at lower risk.
Rebuild it or move to a new system. The most disruptive and expensive, justified when the functional gap is fundamental or the system is genuinely at the end of its life.
Replacement is chosen too often because it feels decisive, because vendors sell it, and because the cheaper options are less visible and less exciting. But replacement carries the migration, data and adoption risks that sink programmes, and much of the time a re platform captures most of the value without them. The discipline is to solve the actual problem with the least disruptive option that genuinely solves it.
A legacy system is an older application or platform that is still critical to the business but hard to change, support or integrate, often because of outdated technology, scarce skills, ending vendor support or years of customisation.
We assess legacy estates and give an independent recommendation with no system to sell. See legacy system modernisation or get in touch.
If any of this is live for you right now, the senior people who wrote it are the people you would work with.