What Is the Strangler Fig Pattern?

Somewhere in every large company is a system too critical to touch and too old to keep. The instinct is to rewrite it — build a clean replacement, switch over, move on. The strangler fig pattern is the alternative that has quietly become the default for serious modernization: don’t replace the system, outgrow it. This series is about that pattern in depth — the mechanism, the engineering, and the discipline that makes it finish.

The tree the pattern is named for

Martin Fowler coined the term in 2004, after the strangler fig vines he’d seen in the rainforests of Queensland, Australia. A strangler fig seeds in the canopy of a host tree, sends roots down its trunk to the ground, and slowly grows into a lattice around it. The host isn’t cut down. It’s enveloped — and by the time the fig is self-supporting, the original tree is gone, having fed the thing that replaced it.

It is an unusually honest metaphor for legacy modernization. The old system isn’t demolished. It’s outgrown.

What it means in software

The strangler fig pattern replaces a legacy system incrementally, from the edges in, while the legacy system stays in production the entire time. Rather than build a parallel replacement and switch at a single cutover, you stand up the new system alongside the old and move responsibility across one capability at a time.

Three things have to be true for that to work:

1. Something routes the traffic. A layer sits in front of the legacy system and decides, per request, whether the legacy implementation or a modern one handles it. This is the strangler facade, and it is what holds the seam together while the system is half-old and half-new. Part 3 is entirely about it.
2. Work moves across in slices. A slice is a vertical cut of business capability — not a layer, not a module, but a whole thread of behavior the business would recognize. You build the modern version of one slice, prove it behaves like the legacy one, and shift that slice’s traffic across. The rest of the system keeps running untouched.
3. The legacy system is retired piece by piece. As each slice moves over, the legacy system has less to do. Eventually nothing routes to it. Only then — emptied, not amputated — is it decommissioned.

There is no big-bang cutover. There are many small ones, each reversible, each shipping value while the next is still being built.

Why this shape, and not a rewrite

A rewrite concentrates every risk in the program onto a single future date. The strangler fig pattern does the opposite: it distributes risk across dozens of small, independent promotions, each of which can be validated before it carries load and rolled back if it misbehaves. The business gets working software every few weeks instead of waiting years for one delivery — and the people who understand the legacy system’s behavior are in the room for each slice, not handing it off to a clean-slate team that never saw it run.

That contrast — strangler fig versus big-bang rewrite — is the most consequential decision in a modernization program, and it deserves its own treatment. Part 2 makes it the whole subject, including the honest case for when a rewrite really is the right call.

What the pattern needs from a system

The strangler fig pattern is powerful, but it isn’t free, and it doesn’t fit everything. It needs seams — places where the system can be intercepted and split, where a slice’s traffic can be routed independently of the rest. A system with clean service boundaries, an API surface, or a message bus offers those seams readily. A tightly woven monolith with no network boundary offers them grudgingly, and finding or creating the seam becomes part of the work.

It also needs a system worth the apparatus. Standing up a facade, isolating slices, running old and new side by side — this is real engineering you take on specifically to make the migration safe and gradual. For a small system one engineer could cleanly rewrite over a few weeks, that apparatus can cost more than the risk it removes.

When the pattern is overkill

Respect for the legacy system is the starting point here — it encodes decades of business reality, and the people who keep it running are not the problem to be solved. But respect doesn’t mean the strangler fig pattern is always the answer. It is the wrong tool when:

• The system is small and well understood enough to rebuild cleanly in weeks — the facade overhead exceeds the risk it removes.
• The system is genuinely isolated, with no live coupling to anything else, and can be swapped behind a simple switch with a clean rollback.
• An external constraint forces wholesale replacement with no possibility of coexistence — a platform at hard end-of-life with no path to run alongside its successor.

The deciding variables are size, entanglement, and how much the running business depends on the system staying up. The larger, more interwoven, and more critical it is — which describes most systems worth modernizing at all — the more decisively the strangler fig pattern wins. That’s not a coincidence. It’s the same property that made the system legacy in the first place.

Where this leads

This part defined the pattern and named the metaphor it’s built on. The next part makes the central choice explicit: Part 2, Strangler Fig vs Big-Bang Rewrite, lays the two approaches side by side, traces why rewrites fail for structural rather than accidental reasons, and makes the honest case for the narrow situations where a rewrite is still the right move. Everything after that goes inside the machinery — the facade, the translation layer, and the discipline that keeps the strangle moving until it’s done.