Strangler Fig

Definition

A facade — usually a routing layer at the edge — sits in front of the legacy system. Capabilities are reimplemented one at a time behind the new system, and the router is updated to send that traffic to the new implementation. The legacy system shrinks until it can be switched off.

Why it matters

The alternative is a rewrite: build the replacement in parallel, then cut over. Rewrites of long-lived systems fail at a well-documented rate, for structural reasons rather than incompetence. The requirements are not written down anywhere except in the legacy code's behaviour, including the behaviour nobody intended. The business does not stop changing during the rewrite, so the new system chases a moving target. And there is no value delivered until the very end, which means the project is cancellable for its entire duration and has no feedback.

Strangler inverts all three: value lands incrementally, each slice is validated in production, and the project can be paused at any point in a stable state.

Implementation patterns

• Put the routing facade in first, with everything still pointing at the legacy system. This is a no-op release that proves the routing works, and it is the highest-value first step.
• Choose the first slice for learnability, not importance. Something real enough to prove the path, small enough that being wrong is cheap.
• Route on a business dimension — capability, tenant, geography, customer segment — not on a percentage of random requests, so behaviour is explicable and rollback is comprehensible.
• Run both and compare for read paths: send the request to both, serve the legacy result, log the differences. This finds the undocumented behaviour that no specification contains.
• Decide the data direction explicitly. This is the hard part, not the routing.

The data problem

Routing is easy; data is not. Three options, each with real costs:

Most real programmes use different answers for different slices, and the discipline is to state which one applies to each rather than letting it be decided implicitly.

Industry example

Large retail modernisation programmes — the kind Walmart-scale organisations run against decades-old order management and inventory systems — are typically strangler-shaped by necessity. The legacy system cannot be paused for a weekend, because stores are transacting; and its behaviour encodes years of accumulated commercial rules that exist in no document. Routing by capability and geography, with the mainframe remaining the system of record until a capability's data is fully migrated, is the shape that survives contact with that reality.

Failure scenarios

• The strangler that never finishes. The last 20% is the hardest, funding runs out, and the organisation now operates two systems permanently — strictly worse than either alone. Budget the decommissioning explicitly or do not start.
• The facade becomes a permanent translation layer with its own business logic, so a third system has been created.
• Dual writes without reconciliation, so the systems diverge invisibly.
• No rollback for a slice, so the first surprise becomes an incident rather than a reversal.

Trade-offs

You gain incremental value, continuous validation and bounded risk. You pay for a period — sometimes years — of running two systems, a routing layer that adds a hop, and synchronisation complexity. The decisive question is whether you have the organisational stamina to finish.

Interview question

"You are strangling a 20-year-old order management system. Which capability do you move first, and where does the data live during the transition?"