What is the strangler fig pattern?
Engineering culture and software practice
The strangler fig pattern is a way to replace a legacy system gradually: you build the new system around the edges of the old one, route more and more behaviour through it, and retire the old system piece by piece until nothing is left. Named by Martin Fowler in 2004 after the fig that grows around and eventually replaces a host tree, it is the safe alternative to the high-risk "big bang" rewrite.
What this means
Old systems are dangerous to replace. They are often poorly understood, business-critical and full of undocumented behaviour that people quietly depend on. The tempting approach, build a shiny replacement and switch over on a single day, has a long history of expensive failure, because the new system almost never covers everything the old one did.
The strangler fig pattern offers a calmer route. Instead of one big switch, you grow the new system gradually around the old one. You put a layer in front that decides, request by request, whether the old system or the new one handles each job. At first almost everything goes to the old system. Over months, more and more is handled by the new, until the old system is doing nothing and can be switched off.
The name comes from nature. A strangler fig germinates in a tree, grows down around its host, and eventually the host dies and rots away, leaving the fig standing in its place. The metaphor captures the strategy exactly: surround, take over gradually, and let the old thing fall away.
Why it matters
Most organisations depend on at least one system that is too old to love and too important to switch off: the fifteen-year-old customer portal, the accounting system nobody fully understands, the CRM that has grown barnacles for a decade. Replacing these is one of the riskiest things a business does with technology, and the strangler fig pattern is the main technique for making that risk manageable.
Its central advantage is that value and safety arrive throughout the project rather than only at the end. Each piece moved across delivers a benefit and can be checked before the next piece starts, so a problem is caught while it is small. If something goes wrong, you have only moved one feature, not the whole business, and you can often route back to the old system while you fix it. Compared with a big-bang rewrite, where nothing works until everything works, this is a profound reduction in exposure.
The pattern also changes the conversation with vendors and stakeholders. When a supplier proposes to rip out your system and replace it wholesale on a fixed date, that is a warning sign worth probing, because it concentrates all the risk into one moment. Understanding the strangler fig approach lets a non-technical leader ask the right question: can we do this incrementally, keeping the business running throughout, and see value along the way?
The same idea now applies to AI modernisation. Running an AI-assisted process alongside the existing manual one, and moving work across gradually as confidence grows, is a strangler fig migration in all but name, and it carries the same benefit of bounded, reversible risk.
How it works
Where the term came from
Martin Fowler coined the metaphor in a 2004 article on his website, originally titled "Strangler Application", after seeing the huge strangler figs in the rain forests of the Queensland coast in Australia. He described them as plants that seed in the upper branches of a tree and gradually work their way down until they root in the soil, meanwhile strangling and killing the host. His prescription was to "gradually create a new system around the edges of the old", letting it grow over several years until the old system is strangled.
In 2019 Fowler renamed the piece "Strangler Fig Application", because the bare word "strangler" carried an unpleasantly violent connotation and the botanical "fig" better fit the intended metaphor. The concept has since become a standard modernisation pattern, discussed in the academic migration literature and in books such as Sam Newman's Monolith to Microservices, published by O'Reilly in 2019, which treats it as a core technique for evolving a large system into smaller pieces without a rewrite. Many vendor architecture guides also describe it, though those are marketing material rather than primary sources.
The mechanics
Three moving parts make the pattern work. First, an interception or routing layer sits in front of the old system and decides where each request goes; this is what lets you move behaviour across without users noticing. Second, migration happens feature by feature: you pick a slice of behaviour, build it in the new system, switch the router to send that slice to the new code, and confirm it works before moving on. Third, and hardest, is data. The old and new systems usually need to share or synchronise data during the transition, and getting that right, avoiding duplication, drift and corruption, is typically the most difficult and most underestimated part of the whole exercise.
How it is governed
A strangler fig migration needs deliberate governance or it drifts. Someone must decide what to move first, usually a piece that is valuable, reasonably self-contained and not too risky, so the team learns the mechanics on something survivable. Progress must be measured concretely, by how much traffic or behaviour now runs through the new system, not by vague optimism. And, crucially, the plan must include actually switching the old system off. The discipline that separates success from a permanent mess is finishing the job: decommissioning the host tree rather than leaving it standing beside the fig forever.
How experienced teams handle it
Experienced teams treat the interception layer as temporary scaffolding, not a permanent fixture, and budget for removing it. They keep each migrated slice small enough to reverse. They watch the data-synchronisation cost closely, because it grows quietly. And they hold their nerve on the end game, resisting the very common ending where the easy eighty per cent is migrated, the hard twenty per cent is left on the old system, and the organisation ends up running and paying for both indefinitely.
Examples
A retailer needs to replace a fifteen-year-old customer portal that no one dares touch. Rather than rebuild it wholesale, the team puts a routing layer in front of it and rebuilds one area at a time: first the login, then the order history, then returns. Each area is switched to the new system once it is proven, while everything else continues to run on the old portal. Customers notice nothing except that things gradually improve, and at no point is the whole business exposed to a single risky switch.
A council department modernises a licensing system that other services quietly depend on. It moves the public-facing application form to the new platform first, keeping the old system as the record of truth and synchronising data between the two. Progress is tracked by the share of applications flowing through the new system. The hard lesson comes with data: reconciling two systems during the transition proves far more work than building the new form, exactly as the pattern predicts.
A professional services firm introduces an AI-assisted process for drafting client reports. Instead of switching overnight, it runs the AI process alongside the existing manual one, routing a growing share of low-risk reports through it as confidence builds, with human review throughout. This is the strangler fig pattern applied to a workflow rather than to code: the manual process is strangled gradually, and if the AI process disappoints on a class of work, that work simply stays with the manual route.
Common misunderstandings
People think the strangler fig pattern is just a slower rewrite. It is not. A rewrite builds a replacement separately and switches over in one event; the strangler fig runs old and new side by side, moving behaviour across incrementally so the business keeps working throughout and risk is spread over time rather than concentrated in a single day.
People assume it is mainly the opposite of the rewrite trap and leave it there. The rewrite trap explains why building a replacement from scratch so often fails, and it names the strangler fig as the alternative. This article is about the alternative itself: how you actually run, govern and finish an incremental migration, which is a different body of knowledge from simply knowing that big-bang rewrites are dangerous.
People believe the pattern guarantees success. It does not; it changes the risk profile. It replaces one catastrophic risk with a series of smaller, manageable ones, but it introduces its own hazards, chiefly the cost of the interception layer, the difficulty of data migration, and the temptation to stop halfway.
People think you always finish a strangler fig migration. Painfully often you do not. The most common real-world result is a half-strangled estate: the easy parts moved, the hard parts left behind, and two systems running in parallel forever. Finishing the job, and switching the old system off, is the part that requires the most discipline.
People assume incremental is always right. For a tiny system, or one on a dead platform that must be abandoned wholesale, a straight rewrite can genuinely be simpler and cheaper than building and maintaining a routing layer. The strangler fig pattern is the default for large, business-critical systems, not a universal law.
Risks and boundaries
The signature risk is the migration that never ends: two systems running in parallel indefinitely because the difficult final slice was never moved. This doubles the maintenance burden, confuses staff and quietly consumes the savings the project was meant to deliver. Avoiding it requires treating decommissioning the old system as an explicit, funded part of the plan, not an afterthought.
The interception layer is itself a cost and a risk. It is real software that must be built, maintained and eventually removed, and if it becomes permanent it is simply new legacy. Data is the other persistent hazard: while both systems are live, keeping their data consistent is hard, and duplicated or drifting data can cause errors that are worse than anything in the original system.
There are also boundaries to where the pattern fits. It shines for large, long-lived, business-critical systems where a single switch would be catastrophic. It is overkill for a tiny system that could be rewritten in a fortnight, and it may not apply cleanly when the underlying platform is being abandoned entirely and there is nothing to route to. The honest position is that the strangler fig pattern is the sensible default for risky modernisation, but a big-bang rewrite is occasionally still the right call, and pretending otherwise is its own kind of dogma.
What to do next
When facing a legacy replacement, ask first whether it can be done incrementally. If a vendor or team proposes to switch everything over on a single date, treat that as a risk to be justified, not a plan to be accepted, and ask what an incremental route would look like.
Insist that the plan includes switching the old system off. Fund and schedule decommissioning explicitly, and track progress by how much real behaviour now runs through the new system, so "we are making progress" has a number behind it.
Pay early attention to data. Ask how the old and new systems will keep their data consistent during the transition, because that is usually the hardest and most underestimated part, and a project that has not thought about it is not ready to start.
Sequence the work sensibly. Move something valuable but survivable first, so the team learns the mechanics on a slice you can reverse, and keep each subsequent piece small enough to roll back.
Apply the same logic to AI modernisation. Run the AI-assisted process alongside the existing one, move work across gradually as confidence grows, keep humans in the loop, and be willing to leave a class of work with the old process if the new one does not earn it.
FAQs
Who named the strangler fig pattern?
Martin Fowler, in a 2004 article on his website originally called "Strangler Application", inspired by the strangler figs he saw in Queensland, Australia. He renamed it "Strangler Fig Application" in 2019.
Why is it called strangler fig?
A strangler fig germinates in a host tree, grows around it and eventually replaces it as the host dies away. The metaphor captures a new system growing around an old one until the old one can be removed.
How is it different from a rewrite?
A rewrite builds a replacement and switches over in one event. The strangler fig runs old and new side by side, moving behaviour across gradually, so the business keeps working and risk is spread over time.
What is the hardest part in practice?
Data. While both systems are live they usually need to share or synchronise data, and keeping that consistent without duplication or drift is typically the most difficult and most underestimated part.
What is the biggest way it goes wrong?
The half-finished migration. Teams move the easy parts, leave the hard parts on the old system, and end up running both forever. Finishing the job and switching the old system off is the crucial discipline.
Is a big-bang rewrite ever the better choice?
Yes, occasionally. For a tiny system, or one on a platform being abandoned entirely, a straight rewrite can be simpler and cheaper than building and maintaining a routing layer.
Does it apply outside software?
Yes. Running an AI-assisted or new manual process alongside an old one and moving work across gradually is the same pattern applied to a workflow, with the same bounded, reversible risk.