Strangler Fig Pattern: Definition

The strangler fig pattern is named after a plant. A strangler fig germinates in the canopy of a host tree, sends its roots down around the trunk, and grows until it has formed a structure of its own, at which point the original tree is gone, but the shape it gave is preserved. Martin Fowler used the image to describe a way of replacing a legacy system: build the new one around the old, let it take over function by function, and retire the old only once nothing depends on it.

What it is

The mechanism is a routing layer, the strangler facade, placed in front of the system. Every request passes through it, and the facade decides whether the old implementation or the new one handles it. At the start, everything routes to the legacy system. As each capability is rebuilt, the facade redirects that slice of traffic to the new implementation. Over time the new system handles more and the old handles less, until the legacy system can be switched off entirely. The facade itself is not exotic infrastructure. Depending on the system it can be a reverse proxy, a rule in an API gateway, or nothing more than a routing flag inside the application.

How it works, step by step

Step	What happens
1. Insert the facade	A routing layer goes in front of the legacy system, everything still routes to the old code
2. Build the replacement slice	The new implementation of one capability is built and tested against the same inputs as the old
3. Prove parity	The new slice’s output is validated against the legacy path until they agree, not assumed to
4. Shift traffic	The facade routes that slice’s traffic to the new implementation, often gradually
5. Repeat	The next capability migrates the same way, while the facade routes a growing share of overall traffic to the new system
6. Retire the old path	Once nothing routes to a piece of the legacy system, that code is decommissioned

Why it matters

The pattern exists to defeat the failure mode of big-bang rewrites: concentrating all the risk on a single distant cutover. Research on large digital transformation programs puts the failure rate at up to 70% (BCG, 2023), and the shape of a big-bang project, everything bet on one date, with no way to prove it works until it is already live, is a recurring reason why. With a strangler approach, each slice goes live on its own, behind its own routing decision, and can be rolled back independently without touching the rest of the system. The business keeps running throughout, value ships continuously instead of arriving years later, and a problem in one slice is contained rather than catastrophic. Surprises become tickets, not outages.

A concrete example

Consider a telecom carrier whose call-and-data rating engine, the logic that turns raw usage records into a customer’s bill, has run in a COBOL batch job for twenty years. Nobody wants to touch it. It settles real money, runs overnight, and a wrong number becomes a wrong bill. A strangler approach starts by placing a facade in front of the billing pipeline that can route individual usage records to either the legacy rater or a new service. Data-plan rating, the simplest product line, is rebuilt first and run in shadow, its output compared line by line against the legacy batch job for a full billing cycle before it takes a single live record. Once it matches, the facade shifts that product line’s traffic over. Voice and roaming, each more convoluted, follow the same path one at a time. Two years in, the legacy rater handles nothing, and every part of its behavior was replaced with something proven equivalent before a customer ever saw a bill generated by it.

When it might not be worth it

• A small system with few integration points, where a rewrite behind a single feature flag can be validated and shipped in one release, gets little from the extra machinery of a facade.
• A system being retired outright, with no replacement, does not need a strangler approach at all. It needs a decommission plan.
• Running old and new in parallel is not free: real infrastructure for both, and often logic to keep data consistent between them while a capability is mid-migration. For a short-lived or genuinely low-stakes system, that overhead can exceed the risk it is protecting against.

How it relates to modernization

The strangler fig pattern is the backbone of incremental modernization, and it is what makes refactoring, re-architecting, and even a slice-by-slice rewrite safe to do in production. It pairs naturally with parity validation: before the facade shifts live traffic to a new slice, that slice is proven to behave identically to the legacy code it replaces. The facade controls when traffic moves. Parity validation establishes whether it should. Together they turn a rewrite from a gamble on a date into a series of small, reversible steps, the approach detailed on our parity-first delivery page.

Common confusion

The strangler pattern is sometimes pictured as simply running two systems at once, which misses the point. The defining element is the facade that routes incrementally and the discipline of migrating one capability at a time. Running old and new in parallel with no gradual, reversible traffic shift is just duplication. The strangler pattern is what makes the parallel period a controlled migration rather than a standing risk.