The strangler fig pattern replaces a legacy system gradually, one piece at a time, instead of rewriting it all at once. It is named after the strangler fig vine, which grows around a host tree, gradually replacing its structure until the original tree is no longer needed. Applied to software, new functionality is built alongside the old system and traffic is incrementally routed to it, feature by feature, until the legacy system can be retired with no single risky cutover moment.
What changed in 2026
- Big-bang rewrites continued to have a poor track record publicly documented in postmortems, reinforcing incremental migration as the default recommended approach for any legacy system still handling real production traffic.
- API gateway and service mesh tooling made traffic-splitting and routing-by-route far easier to configure, lowering the operational cost of running old and new systems side by side during a migration.
- Feature-flag platforms increasingly added first-class support for gradual traffic shifting per user segment, which made partial migrations safer to roll back if the new implementation had bugs.
How the pattern works
A routing layer — typically a reverse proxy, API gateway, or load balancer rule set — sits in front of both the legacy system and the new system. Initially, all traffic goes to the legacy system. As each piece of functionality is rebuilt in the new system, the routing layer is updated to send that specific traffic to the new implementation instead. The legacy system keeps running, shrinking in scope, until eventually it handles nothing and can be decommissioned.
Strangler fig vs a full rewrite
| Factor |
Strangler fig (incremental) |
Big-bang rewrite |
| Risk of a single catastrophic failure |
Low - each cutover is small and reversible |
High - one release replaces everything at once |
| Time to any user-visible benefit |
Fast - new features ship as each piece migrates |
Slow - nothing ships until the full rewrite is done |
| Ability to run old and new in parallel |
Yes, by design |
Typically no, or only for a short overlap window |
| Total engineering effort |
Often higher, due to routing and dual-maintenance overhead |
Can be lower, if the rewrite genuinely finishes on schedule |
| Track record on large legacy systems |
Generally strong |
Frequently abandoned or over budget |
When it is worth the overhead
The pattern earns its extra complexity when the legacy system is large, actively used, and cannot tolerate an extended outage or a single risky cutover. It is often not worth it for small systems, where a full rewrite genuinely can be finished quickly and safely. Clear domain boundaries — the kind described in domain-driven design basics — make it much easier to decide which piece to strangle first, since well-bounded functionality is easier to route independently.
Common mistakes
- Never finishing the migration. Without a forcing function, the legacy system can persist indefinitely at 5 percent of its original scope, still requiring maintenance and expertise from people who would rather be doing something else.
- Migrating the easiest pieces first instead of the highest-value or highest-risk pieces, leaving the hardest, most important parts of the legacy system for last, when migration fatigue has already set in.
- Underestimating the routing layer complexity. Keeping two systems in sync — shared data, shared sessions, shared authentication — is often harder than either system individually.
- Skipping a circuit breaker or fallback around the new system during migration. Bugs in a newly migrated piece should degrade gracefully back toward the known-working legacy path where possible; see the circuit breaker pattern for how that mechanism works.
FAQ
Does the strangler fig pattern only apply to monolith-to-microservices migrations?
No. It applies to any incremental replacement — monolith to microservices, one legacy monolith to a new monolith, an old frontend to a new one, or swapping out a third-party dependency piece by piece.
How long does a strangler fig migration usually take?
It varies enormously with system size and organizational bandwidth — anywhere from months to multiple years for large legacy systems. The upside is that value ships continuously throughout, unlike a big-bang rewrite.
What is the biggest risk with this pattern?
Never finishing. Without executive sponsorship and a clear target end state, teams can end up maintaining three systems (old, new, and the routing layer) indefinitely instead of retiring the legacy one.
Does this pattern require microservices?
No, though it pairs naturally with them. You can strangle a monolith into a new, better-structured monolith just as validly as into microservices — the pattern is about incremental replacement, not about the target architecture.
Where to go next