{"post":{"slug":"strangler-fig-pattern-2026","title":"The Strangler Fig Pattern Explained in 2026","excerpt":"The strangler fig pattern replaces a legacy system piece by piece instead of a risky big-bang rewrite. Here is how the pattern works, and when it is worth the overhead.","category":"code","date":"July 3, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">T</span>he 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.\n\n## What changed in 2026\n\n- 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.\n- 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.\n- 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.\n\n## How the pattern works\n\nA 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.\n\n## Strangler fig vs a full rewrite\n\n| Factor | Strangler fig (incremental) | Big-bang rewrite |\n| --- | --- | --- |\n| Risk of a single catastrophic failure | Low - each cutover is small and reversible | High - one release replaces everything at once |\n| Time to any user-visible benefit | Fast - new features ship as each piece migrates | Slow - nothing ships until the full rewrite is done |\n| Ability to run old and new in parallel | Yes, by design | Typically no, or only for a short overlap window |\n| Total engineering effort | Often higher, due to routing and dual-maintenance overhead | Can be lower, if the rewrite genuinely finishes on schedule |\n| Track record on large legacy systems | Generally strong | Frequently abandoned or over budget |\n\n## When it is worth the overhead\n\nThe 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](/blog/domain-driven-design-basics-2026) — make it much easier to decide which piece to strangle first, since well-bounded functionality is easier to route independently.\n\n## Common mistakes\n\n- **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.\n- **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.\n- **Underestimating the routing layer complexity.** Keeping two systems in sync — shared data, shared sessions, shared authentication — is often harder than either system individually.\n- **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](/blog/circuit-breaker-pattern-2026) for how that mechanism works.\n\n## FAQ\n\n**Does the strangler fig pattern only apply to monolith-to-microservices migrations?**\nNo. 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.\n\n**How long does a strangler fig migration usually take?**\nIt 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.\n\n**What is the biggest risk with this pattern?**\nNever 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.\n\n**Does this pattern require microservices?**\nNo, 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.\n\n## Where to go next\n\n- [Domain-driven design basics in 2026](/blog/domain-driven-design-basics-2026)\n- [Circuit breaker pattern in 2026](/blog/circuit-breaker-pattern-2026)\n- [Hexagonal architecture explained in 2026](/blog/hexagonal-architecture-explained-2026)","hue":305,"metaTitle":"Strangler Fig Pattern Explained 2026","metaDescription":"The strangler fig pattern in 2026: how to replace a legacy system incrementally instead of a risky big-bang rewrite, with real tradeoffs explained.","keywords":["strangler fig pattern 2026","legacy system migration","incremental rewrite strategy","strangler fig vs big bang rewrite","legacy modernization pattern","microservices migration strategy","proxy routing legacy migration","software rewrite risk"],"tldr":["**The strangler fig pattern replaces a legacy system incrementally** — one piece migrates at a time instead of one risky cutover.","**A routing layer sends traffic to the old or new code path by path** — as each piece is rebuilt, its traffic moves over.","**Big-bang rewrites keep having a poor track record** — reinforcing incremental migration as the safer default.","**The biggest real risk is never finishing** — without a forcing function, a shrinking legacy system can persist indefinitely.","**Skip:** migrating the easiest pieces first instead of the highest-risk ones — momentum fades before the hardest parts get done."],"readTime":"4 min read","wordCount":814},"related":[{"slug":"legacy-migration-strangler-pattern-2026","title":"Strangler Pattern for Legacy Migration in 2026","excerpt":"The strangler pattern replaces a legacy system piece by piece instead of all at once, routing traffic to new code gradually while the old system keeps running. Here is how to apply it in 2026.","category":"code","date":"August 6, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":322},{"slug":"parallel-run-migration-pattern-2026","title":"Parallel Run Migration Pattern in 2026: Verify a Rewrite","excerpt":"A parallel run tests a rewrite by running old and new systems side by side against real traffic and comparing outputs before cutting over, without risking user-facing side effects.","category":"code","date":"August 7, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":310},{"slug":"how-to-refactor-legacy-code-2026","title":"How to refactor legacy code in 2026: a safe, incremental approach","excerpt":"Legacy code is not bad code — it is code without tests and without context. This 2026 guide gives a practical, low-risk strategy for improving it safely.","category":"code","date":"April 17, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":306}],"sameCategory":[{"slug":"bazel-build-explained-2026","title":"Bazel Explained: What Hermetic Builds Actually Cost","excerpt":"Bazel delivers reproducible, precisely cached builds and demands that you describe everything. Here is what you get, what it costs, and who should say no.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":145},{"slug":"graphql-federation-2026","title":"GraphQL Federation: One Graph, Many Teams","excerpt":"Federation composes independently-owned subgraphs into a single API. Here is what it solves, the operational cost it adds, and when a simpler gateway is enough.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":300},{"slug":"hermetic-builds-explained-2026","title":"Hermetic Builds Explained: Same Inputs, Same Output","excerpt":"A hermetic build depends only on declared inputs. Here is what that property gives you, the common leaks that break it, and how to move toward it incrementally.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":130},{"slug":"monorepo-tooling-compared-2026","title":"Monorepo Tooling Compared: What You Actually Need","excerpt":"Monorepo tools solve task orchestration and caching, not repository layout. Here is what each tier provides and how to tell when you have outgrown the simple option.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":150}],"newer":{"slug":"stock-buybacks-explained-2026","title":"Stock Buybacks Explained for 2026: Why Companies Do It","excerpt":"What a stock buyback actually does to a company and its shareholders in 2026, how it compares with dividends, and the real criticisms worth knowing.","category":"finance","date":"July 3, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":290},"older":{"slug":"tech-debt-tracking-2026","title":"Tracking Technical Debt Without a Graveyard Backlog","excerpt":"Debt tickets accumulate in a backlog nobody reads. Here is how to track debt so it stays visible and gets paid down, rather than becoming a list of regrets.","category":"code","date":"July 3, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":306}}