Two-year replacement programmes fail for structural reasons, not execution ones. The alternative is less dramatic and considerably more likely to work.
Every organisation running a system built more than fifteen years ago eventually faces the same question, usually prompted by a business request the system cannot accommodate: do we replace this?
The instinctive answer is to specify a modern equivalent, build it, and cut over. It is a clean plan, it is easy to present to a board, and it fails with remarkable consistency.
Why big-bang replacement fails structurally
The first problem is that the requirements are unknowable. A legacy system that has run for two decades encodes thousands of business rules, most undocumented, many added to handle a specific situation years ago. The people who understood the reasoning have left. A replacement specified from current documentation will be missing behaviour the business depends on, and will discover this at cutover.
The second is that requirements move faster than a two-year delivery. By the time the replacement is complete, the business has changed, and the new system encodes a snapshot of how things worked at specification time.
The third is risk concentration. All value is realised at a single cutover event that carries enormous operational risk. Because that risk is so high, the cutover gets deferred — and a deferred cutover means both systems run in parallel, at double the cost, indefinitely.
The incremental alternative
The strangler pattern — named for the fig that grows around a host tree until the host is gone — inverts this. Rather than building a replacement alongside the legacy system and switching, you extract capability from it one service at a time.
A routing layer sits in front of the legacy system. Initially it passes everything through. As each capability is rebuilt, the router directs the relevant traffic to the new service while everything else continues to the legacy system. Over time, less and less reaches the original — until it can be switched off with no ceremony at all.
Why this changes the risk profile
Each extraction is small enough to understand fully and reverse quickly. If a newly-extracted service misbehaves, the router sends traffic back to the legacy path — an operation measured in seconds rather than a rollback plan measured in days.
Value arrives continuously. The first extracted capability delivers benefit in month three, not month twenty-four. That matters commercially: a programme showing results is a programme that keeps its funding.
And requirements are discovered by observation rather than archaeology. Because the legacy system is still running, you can instrument it — observe real traffic, real edge cases, real frequencies — and build the replacement against demonstrated behaviour rather than remembered behaviour.
Where to start
Not with the most painful part. Start with something at the edge of the system, with clean boundaries and manageable dependencies. The first extraction is where the team learns the pattern, builds the routing infrastructure and establishes the testing approach. You want that learning to happen on something forgiving.
Then sequence by a combination of business value and dependency structure. Capabilities that many other things depend on generally come earlier, because extracting them unblocks later work. Capabilities that are genuinely peripheral may never justify extraction at all.
The honest tradeoffs
Incremental modernisation is not free of cost. You run two systems for an extended period, with the operational overhead that implies. The routing layer is real infrastructure requiring real engineering. And the end state can be less architecturally pure than a clean rebuild would have produced.
There are also cases where replacement genuinely is the answer — where the legacy platform is unsupportable, where a commercial product fits the process well, or where the system is small enough that the risk is manageable.
But for a large, load-bearing system that the business runs on, incremental extraction trades architectural elegance for a dramatically better chance of finishing. That is usually the right trade.
