There is a particular kind of confidence that arrives with a new leadership team and a legacy system everyone agrees is a problem. The instinct is to replace it wholesale: define the requirements, select a platform, run a multi-year programme, and switch over on a single go-live date. It has a certain appeal on a slide. It almost never survives contact with a live business.
The failure mode is depressingly consistent. The legacy system, however unloved, has accumulated years of undocumented business logic that nobody remembers writing down because it was never written down anywhere except the code itself. A big bang replacement has to rediscover all of it before go-live, under a fixed deadline, while the business keeps running on the old system in parallel. Something gets missed, usually something that only shows up during a specific month-end process or a specific regulatory filing, and the go-live either slips repeatedly or ships with a painful defect that erodes trust in the new system before it has had a chance to earn any.
The case for the strangler pattern
The alternative that consistently performs better is incremental replacement, sometimes called the strangler pattern: build the new capability alongside the old system, route a slice of real traffic or a specific business function to it, verify it behaves correctly under real conditions, and only then move the next slice. The old system is gradually starved of responsibility until what remains can be switched off without drama, because by that point it is doing almost nothing.
This approach trades the emotional satisfaction of a single dramatic cutover for something much more valuable: the ability to be wrong about a small piece of the system without that mistake taking down the whole business. When a slice of functionality behaves unexpectedly under real load, the blast radius is that slice, not the entire operation, and it can be rolled back without headline consequences.
The blast radius of being wrong is the whole point. A slice that fails is a bad week. A big bang that fails is a bad year.
Sequencing is the actual skill
Incremental modernisation lives or dies on sequencing: choosing which slice to move first, second and last, in an order that manages risk rather than simply following whatever is technically easiest. The naive approach starts with the simplest component, which often turns out to be the one nobody actually cared about, and leaves the genuinely risky, business-critical logic for last, precisely when the team has the least remaining budget and patience to handle it properly.
A better sequence starts with a slice that is meaningful enough to prove the pattern works under real conditions, but contained enough that a mistake is recoverable. From there, the sequence should deliberately tackle the riskiest and most business-critical logic while the programme still has the time, attention and goodwill to do it carefully, rather than rushing it at the end because the deadline has already slipped.
- 路Move a meaningful but contained slice first to prove the pattern works
- 路Sequence the riskiest business logic while the programme still has time and attention
- 路Keep the old and new systems reconcilable at every stage, not just at the end
- 路Decommission legacy components deliberately, not as an afterthought once traffic has moved
Why rewrites fail even when the technology is right
It is worth being honest that most big bang rewrites do not fail because the new technology was wrong. They fail because a fixed, distant deadline concentrates all the risk into a single event, and because the business logic embedded in a legacy system is almost always larger and stranger than anyone estimated at the outset. Incremental modernisation does not make that logic smaller, but it does mean discovering it in manageable pieces over time rather than all at once under deadline pressure.
It also produces something a big bang programme rarely does: continuous evidence of progress that keeps sponsors confident and funding intact. A programme that can show working, in-production improvements every few months is far more resilient to the inevitable pressure to cut scope or budget than one whose only visible output, for two years, is a slide describing what will eventually exist.
The discipline this actually requires
Incremental modernisation is not simply a technical choice, it is an organisational commitment to running two systems in parallel for longer than feels comfortable, and to resisting the temptation to declare victory before the old system has genuinely been retired. That parallel running is expensive and unglamorous, and it is precisely the part that gets cut when a programme is under budget pressure, which is usually the moment it becomes most necessary.
Done properly, this approach takes longer to reach the final headline than a big bang programme promises on its opening slide. It also reaches that final state considerably more often, which is the only comparison that actually matters.
If a modernisation programme's plan depends on everything going right until a single go-live date, it has already accepted a level of risk that incremental approaches were designed to avoid. The organisations that get this right are rarely the ones that moved fastest. They are the ones that never bet the whole system on one weekend.