The strangler fig, the tree the pattern is named for, doesn't fell the host tree it grows around — it slowly builds its own structure alongside it until the original is no longer load-bearing. Martin Fowler borrowed the metaphor for a reason: it describes the only kind of legacy migration most businesses can actually afford to run.
The alternative — a full rewrite, cut over on a single weekend — sounds efficient and almost never survives contact with a real system. This is the version of the pattern we run with clients, scaled to a first slice you can complete in weeks, not the whole migration at once.
Why not just rewrite it
Two things make big-bang rewrites fail more often than they succeed: the business can't stop running while the new system catches up to years of accumulated edge cases, and by the time the rewrite ships, the old system has usually changed underneath it too. The strangler pattern avoids both problems by never asking the business to stop, and by shrinking the legacy system in place rather than replacing it in one motion.
The three moving parts
- A façade. A thin routing layer — often just a reverse proxy — sits in front of the legacy system and intercepts every request.
- The new service. A single, bounded piece of functionality, rebuilt independently of the legacy codebase.
- The routing rule. The façade decides, per request, whether traffic goes to the new service or falls through to the legacy system underneath.
Nothing about this requires touching the legacy system's internals on day one. That's the point — the façade is the only new thing in front of production traffic until the first slice is proven.
Choosing the first slice
The single biggest factor in whether a strangler migration succeeds is picking the right first slice. Get this wrong and the pattern gets blamed for a scoping mistake.
- Pick a capability with a clear boundary — one that doesn't reach into five other modules for shared state.
- Pick one with real but bounded risk — valuable enough to matter, contained enough that a rollback doesn't take down the business.
- Avoid the piece everyone agrees is the hardest. Prove the pattern on something real but tractable first; the hardest piece comes later, once the team and the façade have both been tested.
Running the two systems in parallel
This is where most of the real risk in a strangler migration lives — not in the new code, but in the seam between old and new.
- Data synchronization is the sharpest edge. Decide explicitly which system owns which data during the transition, and instrument the seam so a drift between the two is visible immediately, not discovered in a support ticket.
- Shadow traffic — routing a copy of real requests to the new service without acting on the response — is the cheapest way to validate correctness before the façade actually cuts traffic over.
- Roll back at the façade, not in code. If the new service misbehaves, flipping the routing rule back to the legacy path should be a config change, not a deploy.
The failure mode to watch for
Strangler migrations rarely fail loudly. They stall quietly — the team moves the highest-value, easiest slices first, momentum fades, and the legacy system keeps running indefinitely with just enough carved away to make the case for finishing it feel less urgent. Treat the migration as a program with an end date, not a background task.
Repeat, then retire
Each successful slice makes the next one easier — the façade matures, the team develops a rhythm, and the legacy system's surface area shrinks. Eventually what's left of the original system has nothing left to do, and decommissioning it is a formality rather than an event. That's the outcome worth designing for from the first slice: not a faster rewrite, but a migration where no single day is the day everything could go wrong.
Every step delivers value, every step can be reversed, and the business never stops during the process.
Have a monolith you've been circling for a first slice? See how we approach it, or talk to us about where to start cutting.