Strangler fig migration pattern infographic: big-bang rewrite step function vs gradient migration behind a facade router, with a health test chart of routes handled over time

System Design · Migration Strategy

The Vine That Replaces The Tree Without Cutting It Down

The Strangler Fig pattern — how you replace a running system without ever stopping it.

Core Concept

The strangler fig pattern is a migration strategy, not a design pattern for new systems. It answers one question: how do you replace a system that is running in production, without stopping it?

Why the name: a strangler fig germinates in the canopy of a host tree, grows roots down alongside the trunk, and eventually replaces the host's root system entirely — the host tree dies standing, already enclosed. The engineering parallel is exact: the new system grows around the old one, using the old one as scaffolding, until the old one carries no traffic and can be removed.

Key Components

1The Big-Bang Alternative

Build the whole replacement first, then flip one switch. Forces a feature freeze on the old system, a binary cut-over date where both must be perfect, and a rollback that is just "put the old one back" — which degrades the more the rewrite drifts.

2The Facade

A routing layer — reverse proxy, API gateway, or in-code abstraction — that intercepts every request and decides which system handles it. Nothing downstream is special; all decisions live here.

3Sliced Migration

At first the facade routes everything to the old system. Each time a slice of new functionality ships, the facade routes that slice to the new system. The transition is a gradient, not a step function — no freeze, no cut-over date.

4The Two-System Trap

The failure mode the metaphor hides: a strangler that stalls leaves you running two systems forever — the old one still live but unmaintained, the new one incomplete. Strictly worse than either alone, and the most common real outcome.

How It Works

Stand up the facade in front of the old system. It routes 100% of traffic to the old one — behavior is unchanged, but now all routing decisions have one home.
Decompose the old system into slices small enough that each one can ship and be routed before the next begins.
Build slice N of the new functionality, ship it, and flip the facade route so that slice now hits the new system.
Repeat. The new system's share of traffic climbs gradually; the old system shrinks without a single moment of downtime.
When the facade routes nothing to the old system, remove the old system — and then, critically, remove the facade too.

The Concrete Test

Count the routes the facade handles

If that number is rising, the migration is alive. If it has been flat for a quarter, you are in the two-system trap — commit to finishing, or cut losses and revert to one system. The real discipline of this pattern is not starting the strangler — it is finishing it. A "temporary" coexistence that hardens into the architecture is the pattern's signature failure.

Where You'll Meet It

Monolith → services, service by service Legacy on-prem → cloud Old API → new API, endpoint by endpoint Framework upgrades behind a proxy Payment/identity vendors, route by route

Checkpoint — answer before you move on

Three Questions

Name the three things a big-bang rewrite forces on you (freeze, cut-over, rollback), and say how the facade removes each one. The facade's power is that it makes routing a decision you can change per slice, not a date.
A team reports their facade has routed the same set of routes for a full quarter — no new slices shipped. What does that tell you, and what are the only two honest moves left? Flat route count = the two-system trap. Finish, or revert.
Why is a half-finished strangler (two systems running indefinitely) strictly worse than just running the old system alone? Think about what gets maintained, and what the facade becomes when it stops being temporary.