Key takeaways
- A big-bang replacement concentrates the risk into one weekend and one decision. Incremental replacement spreads it across many small, reversible ones.
- The strangler fig pattern puts an interface in front of the old system and moves capabilities behind it one at a time.
- Choose the first slice for what it will teach you and how loosely it is coupled, not for how important it is.
- Run old and new side by side, compare their outputs, and move traffic over gradually.
- A slice is not finished until the old code path is switched off.
Why big bang keeps failing
A full replacement asks the business to stop changing the old system for the length of the project, then bets everything on a cutover that cannot be rehearsed at full scale. Requirements drift while the new system is built, the data migration surprises everyone, and the rollback plan is usually hope.
The strangler fig pattern
Martin Fowler named the pattern after a vine that grows around a host tree until it can stand on its own. An interface layer sits in front of the legacy system, and callers talk to the layer rather than to the system. One capability at a time is rebuilt behind it, and the layer sends that capability’s traffic to the new service. When nothing is routed to the old system any more, it can be switched off.
Choosing the first slice
- Loosely coupled: a capability with few calls into the rest of the core.
- Clearly bounded: inputs and outputs you can describe without drawing the whole estate.
- Real traffic: enough use to prove the approach under load.
- Instructive: it should exercise the hard parts — data synchronisation, identity, monitoring — so the next slices go faster.
Resist starting with the most important capability. The first slice is where you learn how to do the rest.
Run in parallel, then switch
Shadow
The new service receives a copy of real traffic. Its outputs are compared, not used.
Compare
Differences are investigated until they fall within an agreed tolerance.
Shift
A small share of live traffic moves to the new service, growing as confidence does.
Retire
The old code path and its data are removed, and the removal is recorded.
The data is the hard part
Two systems that both own the same record will eventually disagree. For each slice, decide which system is the source of truth, how changes flow between the two during the transition — events, change data capture or a scheduled sync — and how differences are reconciled when they appear.
Keep the architecture visible
Incremental modernisation runs for months or years, and the picture of what has moved changes every few weeks. Keep one current view of which capabilities sit where, linked to the work that moved them, so planning starts from the estate as it is rather than last quarter’s slide.