Strangler Fig: Replacing a System Without a Big-Bang Cutover
Named after a vine that gradually envelops and eventually replaces its host tree, this pattern lets a new system take over a legacy one piece by piece — so a single bad cutover night can never take down the whole business.
Software architect Martin Fowler named this pattern after strangler fig vines, which grow around a host tree, gradually take over its structural role, and eventually outlive it entirely — the tree is replaced, but never all at once. Applied to software, the same idea avoids the single riskiest moment in most modernisation projects: the night everything switches over at once.
This is a companion piece to our legacy modernisation guide.
Why the big-bang cutover is the riskiest part of any rewrite
A full cutover concentrates months or years of accumulated risk into a single event. Every assumption made during development, every edge case that testing did not cover, and every piece of undiscovered business logic gets tested simultaneously, in production, usually under time pressure, with the old system already switched off and unavailable as a fallback.
The evidence on IT project risk supports treating this concentration as dangerous in itself. The largest peer-reviewed study of project costs found overrun risk follows a long-tailed power-law distribution with no statistically significant relationship to project size (p = 0.863) — meaning even a carefully scoped cutover is not inherently protected from the tail risk that produces the worst outcomes. (JMIS, 2022) A pattern that reduces the size of any single failure event, rather than trying to eliminate the possibility of failure entirely, is addressing the actual shape of the risk.
How the pattern works
Instead of replacing the legacy system in one move, a routing layer sits in front of both the old and new systems. Traffic, or specific functionality, is redirected to the new system incrementally — one feature, one user segment, or one business process at a time — while everything not yet migrated continues to flow to the legacy system unchanged.
Over time, more functionality moves to the new system. The legacy system's responsibilities shrink. Eventually, once everything has been migrated and verified, the legacy system can be decommissioned, having been gradually "strangled" rather than switched off in a single event.
What this actually buys you
Each increment is independently testable and reversible. If migrating one feature reveals a problem, only that feature needs to be rolled back — not the entire programme. Compare this to a big-bang cutover, where a single serious issue can mean reverting the whole system, at cost of the elapsed time since go-live.
Real production behaviour becomes visible incrementally. Legacy systems accumulate undocumented behaviour, discussed in detail in our piece on data migration risk. Migrating incrementally surfaces this behaviour in small, manageable batches rather than all at once during a single cutover weekend.
The business keeps running throughout. A programme that takes eighteen months does not require the business to accept eighteen months of frozen functionality on the legacy side, nor a single high-risk night at the end of it.
Confidence builds empirically rather than by assertion. Each successfully migrated increment is evidence the approach is working, rather than a plan the team simply hopes will hold together at the end.
What it costs you
The pattern is not free. Running two systems in parallel, with a routing layer directing traffic between them, is genuinely more complex than running one system and then switching to another. That complexity has to be built, and it has to be removed again once migration completes — it is not a permanent architecture, and a strangler-fig routing layer left in place indefinitely after migration is finished becomes its own form of technical debt.
It also takes longer in elapsed calendar time than a theoretical instant cutover, though "theoretical" is doing real work in that sentence — the JMIS data above suggests few cutovers are actually instant or risk-free in practice.
When a big-bang cutover is still the right call
Not every system justifies the added complexity of a strangler-fig approach. Small, low-risk systems with limited blast radius if something goes wrong may reasonably be replaced in a single cutover, particularly where the system's traffic can be paused entirely during a low-usage window without meaningful business impact. The pattern earns its complexity on systems where the cost of a bad cutover night would be severe — customer-facing systems, systems processing money, or systems with no acceptable downtime window.
What we do
We default to incremental replacement for any system where a failed cutover would be seriously damaging, and we build the routing layer to be genuinely temporary, with its removal scheduled as part of the project rather than left for someone to notice later.
If you are planning to replace a critical system and want the transition sequenced to avoid a single high-risk cutover, that is a conversation we are glad to have.
Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions.