Strangler Fig Pattern
Concept
The strangler fig pattern, a metaphor coined by Martin Fowler after the rainforest vine that grows around a host tree and gradually replaces it, describes an incremental approach to legacy system replacement: instead of a big-bang rewrite, a new system is built alongside the old one, and functionality is migrated piece by piece behind a routing/proxy layer, until the legacy system has nothing left to do and can be decommissioned.
Mechanically: a facade or proxy sits in front of both systems. Initially, all traffic routes to the legacy system unchanged. As each capability is rebuilt in the new system, the router is updated to send just that slice of traffic to the new implementation instead — the legacy system keeps serving everything not yet migrated. Over time, the proportion served by the new system grows until the legacy system's traffic share reaches zero and it can be safely retired.
Tradeoffs
| Approach | Risk profile | Time to full delivery | Cost during transition |
|---|---|---|---|
| Big-bang rewrite | High — all value delivered (and all risk realized) at one cutover moment | Long, with zero incremental value until the end | Running one system, but a large, high-stakes deploy at the end |
| Strangler fig (incremental) | Low per-slice — each migrated piece is independently validated in production | Longer overall, but value delivered continuously | Running two systems in parallel for the duration — real ongoing cost |
The core tradeoff: strangler fig trades a large one-time risk for a smaller, more manageable risk spread over a longer timeline, at the direct cost of maintaining two systems (and the routing layer between them) simultaneously for the migration's duration. It is a deliberate choice to buy risk reduction with calendar time and operational overhead.
When to use / when not to
- Fits legacy systems that are large, business-critical, and can't tolerate an all-at-once cutover failure — exactly the systems where a big-bang rewrite's failure mode (discovering a critical gap only at final cutover) is least acceptable.
- Especially well suited when the legacy system must keep serving production traffic throughout the migration — there's no maintenance window large enough for a full replacement.
- Poorly suited to small systems where the overhead of building and maintaining a routing layer exceeds the actual migration risk — for a system a small team can safely rewrite and cut over in a single deploy, strangler fig is unnecessary process weight.
- Requires the legacy system's boundaries to be identifiable enough to carve into independently-migratable slices — a system with deeply tangled, inseparable internals may need boundary-drawing work (or an anti-corruption layer) before strangler fig migration is even possible.
Common pitfall
Underestimating how tangled legacy system dependencies actually are before committing to the pattern — the incremental approach assumes capabilities can be cleanly sliced off one at a time, but legacy systems often have deeply embedded cross-cutting dependencies (shared database tables, implicit coupling through shared state) that resist clean slicing. When that's true, "incremental" migrations stall indefinitely with both systems running in parallel far longer than planned, turning the transitional cost into a permanent one.
Principal Engineer Lens
Strangler fig is the organizational-complexity pillar's signature pattern: it's not really about technology, it's about managing risk and stakeholder confidence over a multi-quarter (sometimes multi-year) migration where a single big-bang failure would be catastrophic to the business, not just the system. The Principal-level framing in a review is naming the specific slicing strategy (which capability migrates first and why) and the specific cutover criteria (what proves a slice is safe to fully redirect) — not just invoking "strangler fig" as a buzzword for "we'll migrate gradually." This maps directly onto both a legacy monolith-to-microservices modernization at a BigTech scale and a Network-tooling migration off an aging platform (e.g., legacy NetBox instance) — the incremental-proxy logic is identical.
Reel Script
Setup: Ask: would you rather replace a 15-year-old business-critical system in one high-stakes weekend cutover, or replace it one piece at a time over a year, with the old system still running the whole time as a safety net?
Concept walkthrough: Explain the fig-vine metaphor briefly, then the mechanics — a routing/proxy layer sits in front of both old and new systems, all traffic starts on the legacy system, and each rebuilt capability gets its traffic slice redirected to the new system once validated, until the legacy system has nothing left to serve.
Real example tie-in: Walk a concrete slice-by-slice migration: an e-commerce platform migrating off a legacy monolith rebuilds the search feature first (a well-bounded, independently testable slice), routes just search traffic to the new service, watches it in production, then moves to the next capability — checkout, inventory, etc. — one at a time.
Tradeoffs & alternatives: Contrast explicitly with big-bang rewrite — faster in theory, but all risk lands at one cutover moment, versus strangler fig's real cost of running two systems in parallel (and maintaining the routing layer) for the whole migration window.
Principal Engineer takeaway: The strong review answer isn't "we're doing a strangler fig migration" as a buzzword — it's naming the specific first slice to migrate, why that slice was chosen (well-bounded, low-risk, meaningful value), and what concretely proves a slice is safe to fully cut over.
Related
Sources: