The Strangler Fig Pattern: How to Replace a System Without Ever Shipping a Rewrite
Every "let's rewrite it" project I've watched fail has failed the same way: the team disappears for six, nine, eighteen months to build the replacement, the business requirements keep moving underneath them the whole time, and the cutover day arrives with a system that's already behind the one it was meant to replace. Martin Fowler named the alternative after a tree: the strangler fig germinates in the canopy of a host tree, sends roots down around it, and gradually takes over the host's structural role — until one day the host is gone and the fig stands on its own, without a single day where nothing was standing.
Replace the system without ever turning it off
The pattern's mechanics are almost boringly simple, which is exactly what makes them trustworthy. You put a facade — a router, a reverse proxy, an API gateway — in front of the legacy system, so every request already passes through a layer you control. Then you pick one capability, build it as a new, independent service, and change the facade's routing so requests for that capability go to the new service instead of the old one. Everything else keeps flowing to the legacy system unchanged. You repeat that, one capability at a time, and the legacy system's share of total traffic shrinks with every pass. Eventually it's handling nothing, and you turn it off — which by then is a formality, not an event.
The property that makes this worth the extra ceremony, compared to a rewrite, is that at every single point in the process you have a working system in production. There's no six-month stretch where the team is heads-down and the business is flying blind. Every extracted capability ships, earns confidence, and starts paying down risk immediately — instead of all the risk being backloaded onto one terrifying cutover weekend.
Why this is close to mandatory for AI retrofits
I don't reach for this pattern out of purism. I reach for it because AI retrofit projects have a specific failure mode that makes rewrites even more dangerous than usual: the target keeps moving. If you spend a year building "the new AI-powered version" of a system as a parallel rewrite, you're not just risking the normal rewrite failure modes — requirements drift, scope creep, the team's context aging out. You're also betting that eighteen months from now, the model landscape, the retrieval techniques, and the eval practices you designed around today are still the right ones. Given how fast that ground has been moving — I wrote about this directly in the Stanford AI Index piece — that's a bet I don't think is worth making.
The strangler fig sidesteps it. You're not committing to one big AI architecture up front and hoping it's still right when you ship. You're extracting one capability — say, search — putting a modern retrieval pipeline behind it, shipping it, learning from production traffic, and only then deciding what the next capability's AI architecture should look like, informed by what you just learned. Each slice is small enough to redesign if the field moves again before you get to it.
The facade is the part people underinvest in
The single most common mistake I see is treating the facade as a throwaway routing shim instead of what it actually is: a piece of infrastructure that will sit in the critical path of every request for the entire migration, possibly for years. That facade needs the same rigor as any other production system — observability into which capability is serving each request, a fast rollback path if a newly extracted service misbehaves, and a routing configuration that's reviewed and versioned, not a pile of conditionals someone's afraid to touch. Skimp on the facade and you've just added a second legacy system for the price of one.
The second mistake is picking extraction order by what's technically easiest instead of by what's actually risky to leave in place. I extract the capability that most needs an AI rewrite first — the search relevance that's been quietly bad for years, the classification logic nobody trusts — not the capability that happens to have the cleanest existing interface. Easy extractions feel like progress; risky ones are where the migration is actually earning its keep.
Where this fits with the rest of the toolkit
Cynefin tells you how to approach the unknown parts of a migration — probing with a small extraction before committing to the pattern for a capability you don't understand well yet. Team Topologies tells you who should own the facade and the newly extracted services, so the migration doesn't become another queue behind a single overloaded team. The strangler fig itself answers the question underneath both of those: how do you actually get from the old system to the new one without ever being down, and without betting the whole migration on a single architecture decision staying right for the next two years. In a field that reinvents its best practices every few months, that's not a nice-to-have. It's the only version of "rewrite it" I actually trust anymore.