Zero-Downtime Migrations: The Strangler-Fig Playbook

Why the Big Bang Keeps Failing

Every failed migration post-mortem reads the same. Months of parallel build, a frozen legacy system drifting out of date, a heroic cutover weekend, and then Monday: the edge cases nobody knew existed, the batch job nobody documented, the customer data that meant something different than assumed. Rollback is impossible because the old system is already three days stale. Everyone works 20-hour days until it stabilises, and the organisation vows never to modernise again.

The failure isn't execution. It's the shape of the bet: all risk, concentrated on one irreversible moment.

The Strangler-Fig Shape

Named for the fig that grows around a host tree until it stands on its own, the pattern replaces a system capability-by-capability while the whole remains live:

• 1. Put a front door in place. A routing façade — API gateway, reverse proxy, or an anti-corruption layer in code — through which all traffic to the legacy system flows. This is the control point everything else depends on.
• 2. Carve a seam. Pick one capability with clean edges — a document store, a pricing calculation, a customer-facing read path. Build it new, to current standards, with its own data store.
• 3. Shadow, then shift. Run the new slice in shadow (receiving real traffic, results compared, not served) until the diff report is boring. Then shift traffic gradually — 1%, 10%, 50%, 100% — with instant rollback at every step because the old path still exists.
• 4. Decommission and repeat. Only when the new slice has carried full production load do you retire the old code. Then pick the next seam.

The strangler-fig's real product isn't the new system. It's the ability to be wrong safely, a hundred times, instead of needing to be right once.

Data Is the Hard Part — Dual-Run Honestly

Routing logic is easy; state is where migrations die. During transition, a capability's data exists in two places, and you must choose a consistency strategy per domain:

• Legacy-master, new-replica: new system reads from a synced copy; safest for read-path migrations.
• Dual-write with reconciliation: writes go to both; an automated reconciliation job compares every record and reports drift daily. If you can't measure drift, you don't have dual-write — you have two diverging databases and a delayed disaster.
• Event-sourced bridge: legacy emits change events the new system consumes — the cleanest option when you can add even minimal eventing to the old estate.

On a recent multi-site ERP modernisation, the nightly reconciliation report was the programme's heartbeat: 14 months, every module migrated, zero production downtime — because "old and new agree" was proven daily, not assumed.

Sequencing: Steel Thread First

Choose the first slice for learning, not impact: meaningful enough to exercise routing, deployment, monitoring and reconciliation end-to-end; small enough to ship in 4-6 weeks. That steel thread de-risks every subsequent slice. Then sequence by a simple score: business pain × technical coupling. High-pain, low-coupling capabilities first; the terrifying tangled core last, by which time it's smaller, better understood, and surrounded by clean interfaces.

What It Costs, Honestly

Strangler migrations trade peak risk for duration: you run two systems for a while, and the façade layer is real work. Budget 10-20% overhead versus the theoretical big-bang cost — then remember the big-bang's actual cost includes the material probability of a failed cutover, a frozen business, and a write-off. Across 25 years of modernisation programmes we have never regretted the overhead. Organisations that survived a failed big-bang never regret it either — they just learned the price the expensive way.