The Strangler Fig Pattern: How to Replace a Legacy System Without a Big-Bang Rewrite

Every few years, a team decides their old system is too messy to keep working with, and someone says the magic words: “Let’s just rewrite it from scratch.” Six months later, the rewrite still isn’t done, the old system still has bugs nobody is fixing because “we’re replacing it soon anyway,” and the business is starting to ask hard questions. This story repeats so often in software that it has a name: the Big Rewrite Trap.

There’s a better way, and it’s called the Strangler Fig Pattern. It’s not new or exotic. It’s just a disciplined way of replacing an old system a little bit at a time, while it keeps running the whole time. By the end of this post you’ll understand what it is, how it works step by step, and when it’s the right call.

Where the name comes from

A strangler fig is a real plant. It starts as a seed dropped in the branches of a big tree. Slowly, it grows roots down around the trunk of that tree, wrapping around it more and more each year. Eventually the fig’s own structure is strong enough to stand on its own, and the original tree underneath can die and rot away completely — the fig doesn’t even notice, because it’s no longer relying on the tree for support.

Martin Fowler borrowed this image for software back in 2004. The idea: instead of tearing down your old system and building a new one in its place (risky, slow, all-or-nothing), you grow the new system around the old one, one small piece at a time, until the old system just isn’t needed anymore.

The core idea, in plain terms

Imagine your old system is a single big application that handles everything. You don’t touch it directly. Instead, you put a thin layer in front of it called a router (sometimes called a facade — a stand-in that other systems talk to instead of talking to the real thing directly). Every request from users or other systems goes through this router first.

At the start, the router sends 100% of requests straight through to the old system, unchanged. Nothing about the user experience is different yet. Then, feature by feature, you do this:

Pick one small piece of functionality to rebuild — ideally something well-understood and not too risky.
Build a new version of just that piece, using whatever modern approach you want (a new service, a new database, a new language, whatever fits).
Update the router so that requests for that one piece go to the new version instead of the old one. Everything else still goes to the old system.
Watch it closely. If something’s wrong, flip the router back to the old system for that piece. Nobody outside the team even notices.
Once you trust it, move to the next piece. Repeat.

Eventually, every piece of functionality has been rebuilt and routed to its new home. At that point, the old system isn’t handling any real traffic anymore — it’s the dead tree inside the fig. You can retire it.

A concrete example: OrderCore at a mid-size online store

Let’s make this real. Imagine a company called Fairway Goods that sells outdoor gear online. For eight years, all of their order handling — placing orders, searching past orders, calculating shipping, processing refunds — lives in one large application internally called OrderCore. It was written a long time ago, it’s slow to change, and the two engineers who understood it best have both left the company.

The team is tempted to rewrite OrderCore from scratch. But OrderCore handles real money for real customers, every minute of every day. A big-bang rewrite means picking a date where the old system is fully switched off and the brand-new one takes over instantly — and if anything is wrong, thousands of orders could be affected before anyone notices.

Instead, they apply the Strangler Fig Pattern:

Step 1 — Add the router. They put a lightweight routing layer in front of OrderCore. All existing traffic (placing orders, searching, refunds, shipping) flows through the router exactly as before. This is a small, low-risk change on its own, and it doesn’t change any behavior yet — it’s just a passthrough.

Step 2 — Pick the first piece: order search. Order search is read-only (customers just look up their past orders), so if something goes wrong, no one loses money or data. That makes it a safe first candidate.

They build a brand-new Order Search Service with a fast, modern database optimized for search. It reads from the same underlying order data as OrderCore (kept in sync during the transition) so results stay consistent with what OrderCore itself would show.

Step 3 — Flip the switch, just for search. The router is updated: requests for “search my orders” now go to the new Order Search Service. Every other request (placing an order, refunds, shipping) still goes to OrderCore, completely untouched.

Step 4 — Watch, and be ready to roll back. For a couple of weeks, the team watches search response times and error rates closely. If the new service misbehaves, they flip the router back to OrderCore for search — a change that takes minutes, not a weekend of firefighting.

Step 5 — Repeat for the next piece. Once search is stable, they move on to shipping calculation, then refunds, then order placement — each one following the same pattern: build it standalone, route to it, watch it, keep the rollback switch handy.

A year later, every feature has been migrated. OrderCore isn’t receiving any real traffic anymore. The team can finally shut it down — and by this point, it’s a formality, not a leap of faith.

The router is the only thing that decides where a request goes — old system or new — and that decision can change per feature, at any time.

Why teams choose this over a full rewrite

Lower risk. You’re never betting the whole system on one big cutover. Each migrated piece is small enough to reason about and roll back on its own.
Value keeps shipping. The business gets improvements piece by piece (faster search, for example) instead of waiting a year for one big release that might slip further.
You learn as you go. The first piece you migrate teaches you things about the old system’s quirks that make the next piece easier and safer.
Rollback is cheap. Flipping a router setting back is nothing like trying to “undo” a full system replacement after the fact.

The trade-offs — this pattern isn’t free

Nothing in architecture is a pure win, and this pattern has real costs:

It takes longer in calendar time. A full rewrite might sound faster on paper, even though it rarely actually finishes on time. The strangler fig approach is deliberately slower and steadier, and some stakeholders find that hard to accept up front.
You run two systems at once, temporarily. During the transition, both OrderCore and the new services need to stay working and, often, stay in sync with the same underlying data. That sync logic is real engineering work, and it’s easy to underestimate.
The router becomes critical infrastructure. Every request flows through it, so it needs to be reliable and simple. A buggy router undermines the whole strategy.
It requires discipline to actually finish. Because nothing is on fire, it’s tempting to migrate 80% of the features and then quietly stop, leaving the old system alive forever as a permanent, half-retired liability. Someone has to own seeing it through to the end.

When it’s not worth it

If your system is genuinely small — a service two people fully understand, with low risk if it breaks for an afternoon — a full rewrite might really be faster and simpler than setting up a router and doing this piece by piece. The Strangler Fig Pattern earns its cost when the system is large, business-critical, or poorly understood, which is exactly when a big-bang rewrite is most dangerous.

The takeaway

The Strangler Fig Pattern isn’t a clever trick — it’s really just an application of an idea good engineers already believe in: make changes small, reversible, and observable. Instead of replacing your legacy system in one terrifying leap, you let the new system grow around it, feature by feature, until the old one simply isn’t needed anymore. The tree doesn’t fall — it just quietly stops mattering.