Modernising Without the Big Bang

The case for a full replacement is always well argued. The current platform is expensive to change, the people who wrote it have moved on, and every new requirement takes longer than the last. A clean build is the obvious answer.

It is also the option with the worst record, for a reason that has nothing to do with engineering skill. A replacement has to reach parity with fifteen years of accumulated behaviour before it can deliver anything new — and much of that behaviour is undocumented, load-bearing, and only discovered when something downstream breaks.

Parity is larger than the specification

Every long-lived platform contains decisions nobody remembers making. A rounding rule that matches a partner’s file format. A retry that exists because a downstream service was unreliable in 2019. A field that is technically optional but which three reports assume is present.

None of it appears in the requirements, because nobody knows it is there. It appears during cutover, as a series of small surprises arriving faster than they can be diagnosed. The programme does not fail on the hard problems it planned for. It fails on the accumulated weight of things it did not know to plan for.

Change the shape, not everything at once

The incremental route is less satisfying to present and much easier to survive. Take one capability at a time, put a boundary around it, and move it — with the old path still running until the new one has proven itself on real traffic.

That means running two implementations concurrently for a period, which sounds wasteful and is the entire point. It is what converts a cutover into a reversible step. If the new path behaves differently, the difference is visible while both are live and the cost of being wrong is a rollback rather than an incident.

Keep the roadmap moving

The strongest argument for incremental work is not risk. It is that a multi-year replacement requires a freeze on everything else, and the business rarely has a multi-year period in which nothing needs to change.

Teams that modernise successfully tend to run both at once: new functionality shipping from the parts already moved, remediation continuing behind it. Progress stays visible, the case for continued investment does not have to rest on a promise about a future date, and the organisation never has to choose between improving the platform and using it.

The trade-off is real. Incremental modernisation leaves you with two ways of doing something for longer than anyone finds comfortable, and it requires the discipline to finish the migration rather than stopping once the pain has eased. That is a manageable problem. A cutover that goes wrong on a business-critical platform is not.