Most failed migrations share one trait: the plan asked everyone to wait until a single cutover date. The strangler fig pattern is the usual alternative. It lets you replace a legacy system gradually, with the old one still running, instead of betting on one switch. This article explains how it works, walks through an example, and covers where it does not fit.
What the strangler fig pattern is
The name comes from a vine that grows around a host tree and, over years, takes over its shape. In software terms, you put a routing layer in front of the old system, build new code for one capability at a time, send traffic for that capability to the new code, and repeat. The old system shrinks until nothing depends on it and it can be switched off.
A big bang rewrite delivers nothing until the end, and every mistake lands on the same day. Incremental replacement spreads value and risk across many small releases, each of which can be checked and, if needed, reversed. That reduces risk. It cannot remove it, and it adds its own costs, which we cover below.
A worked example: monthly customer statements
Picture a mainframe batch run that produces monthly statements for several products, and a portal that lets customers fetch a statement through an online transaction. A team wants to move statement generation to a modern service. Here is how the pattern could run, in words.
- Find the seam. The statement request from the portal is a clear boundary. Everything behind it can change without the portal noticing.
- Put a facade in front. An API gateway or routing proxy now receives every request and passes it to the legacy path.
- Build one product first. The new service generates statements for a single product, reading from a copy of the data kept current by change data capture.
- Run it in shadow. The new service produces statements that nobody sees. A comparison job checks them against the batch output field by field and lists differences.
- Route a small group. After differences are resolved, internal staff accounts are routed to the new output. Then a small share of customers.
- Widen, product by product. The routing switch stays in place the whole time, so any step can be reversed by changing a rule, not by redeploying anything.
- Retire the old step. When every product has moved and a full cycle, including year-end, has matched, the legacy statement job is switched off.
The facade, the seam and the data
The facade can be a reverse proxy, an API gateway, a message router or, on a mainframe, an integration layer in front of a transaction. What matters is that callers talk to it and not to the old system directly. If callers are hard-wired to the legacy system, the first job is to add that indirection.
A good seam is a stable interface: an API, a queue, a file hand-off or a screen. Between old and new, an anti-corruption layer translates concepts so the old data model does not leak into the new design.
Data is usually the hardest part. At any moment, each piece of data should have one system of record. Writing to both systems from application code is tempting but fragile, because one write can fail while the other succeeds and the two drift apart. Safer options are a single writer with replication to the other side, or an outbox that records changes and publishes them.
Rollback, and where the pattern is a poor fit
Rollback is the pattern's main strength, since the old path stays intact. It has a condition: the old path must stay alive and, once the new system starts writing, it must stay fed with current data. Plan for that return flow before the first cutover.
The pattern is a poor fit when there is no seam, for instance when logic is tangled through shared global state. It is also a poor fit for small systems where a rewrite costs less than running two systems side by side, and when a fixed date forces you off a platform before an incremental path can finish. In that last case, rehosting first and refactoring afterward may be the realistic route.
Running two systems also has a cost. Every release has to be tested on both paths, operators have two sets of runbooks, and the facade becomes critical infrastructure that deserves its own monitoring. Teams that adopt the pattern budget for this overlap and for the effort of finally turning the old system off, which tends to slip when nobody owns it.
To see how this applies to your estate, read about monolith to microservices and mainframe modernization, or start with how to assess a legacy codebase before migrating.
A note on limits: tools, cloud services and practices change, and results depend on the system. This article is general guidance and not a plan for any particular estate.