Every strangler fig explainer covers the same routing diagram and stops. What it usually skips is the part that actually kills these migrations: not the p attern, but the moment nobody’s left to finish it. Here’s the mechanism, a real government-scale case study, and the six signals that tell you whether yours is on track or quietly becoming a second legacy system.
Every strangler fig explainer walks through the same diagram: a facade sits in front of an old system, new functionality gets built behind it, traffic shifts over piece by piece, the old system eventually goes dark. It’s a good diagram. It’s also where most of these articles stop, which is a problem, because the diagram was never the hard part of a strangler fig migration. The hard part is everything that happens after month three, when the facade is still routing half the traffic to a system nobody wants to touch, and the team that started the migration has been reassigned to something more urgent.
That gap, between explaining the strangler fig pattern and actually finishing one, is what this piece covers. Six things worth knowing before starting a strangler fig migration: what the pattern actually is and where the name comes from, why teams choose it over rewriting from scratch, what a real strangler fig migration looks like at government scale, where the pattern’s own creator says it gets hard, the specific technical risks worth planning for before they show up, and the one signal that predicts whether yours finishes or quietly stalls.
None of this is theoretical: every claim below traces back to either the person who named the pattern, the cloud provider whose customers implement it most, or a government team that actually finished one at a scale most engineering teams will never attempt.
Where the strangler fig pattern actually comes from
The name comes from a real plant, and the metaphor is more precise than most engineering-pattern names manage to be. Martin Fowler coined the term “strangler fig” after seeing the actual vines in the Queensland rainforest: a fig germinates in a nook of a host tree, gradually grows around it drawing nutrients, and eventually can stand on its own once it reaches the ground and canopy, sometimes outliving the tree it grew around entirely.
He first wrote up the strangler fig pattern in 2004 and has revised the piece since, most recently in August 2024, because the pattern has stayed exactly as relevant two decades on. Legacy systems didn’t stop existing just because the tooling around replacing them changed.
The facade is the whole mechanism
This is the part every strangler fig explainer gets right, so it’s worth stating plainly once and moving on. A strangler fig migration works by putting a routing layer (a facade, or in AWS’s own terminology, an anti-corruption layer) between users and the legacy system. At the start of a strangler fig migration, the facade routes everything to the old system, unchanged. As new services get built, the facade starts routing specific calls to them instead, one feature at a time, until nothing is left pointing at the legacy code and it can be safely retired. The legacy system never has to be touched more than necessary; it just gradually does less and less until it does nothing at all.
GOV.UK’s own Service Manual describes a useful variant worth knowing before committing to a direction: the reverse strangler fig, where instead of routing users to the new system, the facade presents the old interface to systems that depend on the legacy code while the real work migrates behind it. It’s the same mechanism aimed the other way, useful when the dependents are other internal systems you don’t control the release schedule for, rather than end users who can simply be routed to the new experience directly.
It begins small, on purpose
Fowler is specific about this: a strangler fig migration “begins with small additions, often new features, that are built on top of, yet separate to the legacy code base.” That’s a deliberate design choice, not a limitation: new work goes into the new system from day one, so the team gets a working example of the target architecture immediately instead of waiting years for a rewrite to catch up to feature parity. It also means a strangler fig migration produces something shippable in week one, which matters enormously for keeping organizational patience intact over what’s usually a multi-quarter effort.
Why teams choose this over rewriting from scratch
The alternative to a strangler fig migration is usually a full rewrite, and the case against that isn’t theoretical or abstract risk-modeling. It has a company attached to it, a product failure serious enough to trigger a leadership change, and a regulatory filing confirming exactly when.
Sonos’s exact mistake
In May 2024, Sonos shipped what it called a “completely reimagined” app: a from-scratch rebuild with no fallback path to the version it replaced, instead of anything resembling a strangler fig approach. It launched broken, missing accessibility features, missing sleep timers and alarms, and carrying bugs severe enough that Sonos itself later admitted it had “mishandled the rollout.” There was no facade routing cautious users to the old experience while the new one stabilized. Everyone was moved over at once, on day one, whether the app was ready for them or not.
Old code is not the same thing as bad code
The underlying lesson holds regardless of the specific disaster: a legacy interface that users have already learned represents real, accumulated value, not just technical debt waiting to be deleted. Sonos’s revenue declined 4% for fiscal 2024, with the app cited as a contributing factor, serious enough that the company’s own SEC filing documents a leadership transition in its wake. A strangler fig migration keeps the old, understood version running and reachable for exactly as long as the new one needs to prove itself, instead of betting a product’s reputation on a rewrite working perfectly the moment it ships.
What a strangler fig migration looks like at government scale
The clearest real-world example of a strangler fig migration isn’t a case study written by a vendor with something to sell. It’s open-source code from a government department, still publicly inspectable today.
Bouncer’s entire job was routing
The UK’s Government Digital Service built a Rack application called Bouncer as the facade for consolidating hundreds of separate government websites onto a single platform, GOV.UK. Every request for a legacy government URL hit Bouncer, which checked a mapping table and returned either a redirect to the new page or an archive notice. A companion Rails app called Transition let departmental teams manage those mappings themselves without touching Bouncer’s code directly, a deliberate separation that meant the facade’s own code barely had to change for the entire length of the migration.
Over 300 agencies, no big-bang cutover
According to GDS’s own account, published the day the effort finished, over 300 agencies and arm’s-length bodies moved their content onto GOV.UK over roughly 15 months, department by department, with GOV.UK’s own Service Manual now recommending the same strangler fig approach to other government teams facing the same problem. Nobody had to pick a single night to cut over the entire UK government’s web presence. Each department finished its own strangler fig migration on its own schedule, and Bouncer simply absorbed the difference one redirect at a time, invisible to the public using the sites.
Where the pattern’s own creator says it gets hard
None of this makes a strangler fig migration easy, and Fowler, the person with the least reason to oversell his own pattern, is explicit about that rather than glossing over it.
The transitional architecture is the part teams resist
Building a facade and the routing logic behind it is extra work that a straight rewrite doesn’t require, and Fowler notes teams often hesitate to invest in it for exactly that reason: it feels like effort spent on something that will eventually be deleted once the strangler fig migration is complete.
He argues the reduced risk is worth that cost, and the GOV.UK numbers above back that up, but the hesitation is real and it’s usually where a migration’s momentum first stalls, long before any of the technical risks below ever come into play.
A strangler fig migration won’t fix an organization on its own
Fowler’s sharper warning is about what doesn’t change: without a real shift in culture and development practice alongside the technical migration, “the new systems will end up in a similar mess” to the one being replaced.
A strangler fig migration changes the architecture. It doesn’t automatically change the habits that produced the legacy system in the first place, and those habits will happily recreate themselves in the new code if nothing else shifts, which means a strangler fig effort run purely as a technical project, without anyone owning the practices around it, tends to just relocate the original problem rather than solve it.
The specific technical risks worth planning for
The facade itself can become a single point of failure
Every request in a strangler fig migration has to pass through the routing layer, which means a proxy outage takes down both the legacy system and everything already migrated behind it, the exact opposite of the resilience the migration was supposed to be building toward.
AWS’s guidance is direct about this: the proxy layer “can become a single point of failure or a performance bottleneck,” and recommends building it on infrastructure designed for that load from the start rather than treating it as a throwaway shim that can be hardened later. Later has a way of never arriving once the facade is quietly handling production traffic.
Data consistency between old and new is eventual, not guaranteed
When a migrated service owns its own data store but the legacy system still needs some of that data, teams typically sync the two with a queue and an agent process. AWS calls this explicitly a “tactical solution,” not a permanent one, because the two data stores end up eventually consistent rather than perfectly in sync, a gap that’s easy to miss until a report or a downstream system reads stale data at exactly the wrong moment.
A quieter strangler fig risk sits earlier in the process, before any of that syncing infrastructure gets built: getting the service boundaries wrong in the first place. AWS’s guidance is specific that premature decomposition is costly, especially when the domain isn’t well understood, and recommends domain-driven design and a technique called event storming specifically to surface the real boundaries before committing code to them.
A strangler fig migration that draws those lines in the wrong place doesn’t fail cleanly; it just produces microservices that still call each other constantly, which defeats most of the point of extracting them. AWS’s own guidance also flags that a strangler fig approach isn’t automatically the right call for every system: for small applications, where a full rewrite’s complexity is genuinely low, it can be more efficient to just rewrite than to build and maintain transitional routing infrastructure for something that was never going to take long to replace outright.
The signal that actually predicts whether it finishes
Put the case study and the risks together and one pattern stands out: every strangler fig migration that stalls, stalls for the same reason a rewrite fails, just slower and quieter.
Continuous ownership, not facade elegance
GOV.UK’s migration finished because each department had continuous ownership of its own piece until it was done. Transition existed specifically so teams could manage their own mappings rather than waiting on a central team that might get reassigned partway through.
That’s the actual signal worth watching on any strangler fig effort: not how elegant the facade is, but whether the people responsible for finishing it are still dedicated to it three months in, or have quietly become responsible for something else while the migration sits half-done. A beautifully designed facade with nobody assigned to keep extracting services behind it is worth exactly as much as no facade at all, arguably less, since it’s now infrastructure someone has to keep running.
A facade still routing half of production a year in isn’t strangling anything
A facade that was meant to last one quarter and is still routing half of production traffic a year later isn’t a strangler fig migration anymore. It’s a permanent second system, and now there are two things to maintain instead of one.
This is also where a lot of internal teams lose the thread, not from a lack of technical skill, but because the people who understood the legacy system well enough to migrate it safely are also the people every other deadline in the organization is competing for. Growin’s own piece on the common pitfalls software development teams run into covers the same root issue from a different angle: unclear ownership and constant context-switching kill more projects than any specific technical decision does.
Finishing a migration needs the same team on it, month after month
A strangler fig migration is exactly the kind of work that benefits from a dedicated software team: engineers whose actual job is the migration, not a side priority squeezed between feature requests. For teams that already have the migration plan but not the hands to execute it at a steady pace, IT staff augmentation adds exactly that capacity without a full re-scope of who owns what, and nearshore software development capacity closes the same gap with engineers working close enough to the same hours to pair on the trickier parts of the cutover in real time.
And for teams building the new side of the facade (the target architecture the legacy system is being migrated into), check out our blog on internal developer platforms that covers how to make sure that new system doesn’t just become tomorrow’s legacy code with extra steps. It’s the same question we’d ask before signing any long-running engineering engagement, covered in more depth in what a CTO should ask before committing to a nearshore team: not just who starts the work, but who’s still accountable for it in month nine.
GOV.UK finished because Transition let ownership stay distributed and current for the full 15 months, not because Bouncer was a particularly clever piece of routing code. That’s the part worth taking from a strangler fig migration before starting one: the facade is the easy half, and most of the technical risks above are solvable with enough attention on any given week. What’s harder to manufacture after the fact is a team that’s still showing up in month nine with the same care it had in week one. Get in touch to talk through what steady, dedicated ownership would look like for yours.
