· architecture · 2 min read
A pragmatic roadmap for modernising legacy systems
Big-bang replacements fail more often than they succeed. A staged approach gets you off risky systems without betting the business on one project.
Every established business has one: the ageing system everyone depends on and nobody wants to touch. The spreadsheet that runs operations. The application whose developer left years ago. The server in the corner that must never be restarted.
The instinct is to replace it all in one go. That instinct is usually wrong.
Why big-bang replacements fail
Full replacements concentrate risk: one cutover date, one budget, one chance. Requirements are gathered from what people say the old system does, not what it actually does, and the gap surfaces after go-live. Meanwhile the business changes underneath a project that takes years.
A staged approach spreads that risk and pays back earlier.
The staged approach
Stage 1: Understand what you actually have. Map the systems, who uses them, what they cost, and what breaks if they fail. This is quick, cheap, and almost always surprising. Some “critical” systems turn out to have two users; some invisible ones hold the business up.
Stage 2: Stabilise the risky bits. Before changing anything, make the current estate safe: backups that restore, documented access, supported versions where possible. This buys time and calm for everything that follows.
Stage 3: Peel off the edges. Most legacy systems bundle several jobs together. Reporting, integrations, and user-facing screens can usually move to modern services one at a time, each step shrinking what the core system has to do.
Stage 4: Replace the core, smaller. By now the core is smaller, better understood, and surrounded by clean interfaces. Replacing it, with a purchased product or a rebuild, is a fraction of the original risk.
Deciding what to do first
Rank each system on two axes: business risk if it fails, and drag on change. Anything high on both goes first. Anything low on both can wait, and waiting is a valid strategy when it is chosen rather than defaulted to.
The role of architecture
This is enterprise architecture doing its real job, not producing diagrams, but sequencing change so each step is affordable, reversible, and valuable on its own. That is how we run modernisation engagements: a clear map, a staged roadmap, and delivery support until the risky systems are gone.
If you have a system nobody wants to touch, that is usually the sign it is time to talk about it.