Strangler Fig
Replace a legacy system incrementally, routing traffic to the new one piece by piece.
By the end of this lesson, plan a safe, incremental migration off a legacy system without a big-bang rewrite.
Named after a vine that grows around a tree until it replaces it, the strangler fig pattern replaces a legacy system gradually. You put a facade (router/proxy) in front, then move one capability at a time to a new implementation, redirecting that slice of traffic — until the old system carries nothing and can be retired.
First, see the whole system. Then we’ll open it up.
Facade routes old vs new
- A facade routes migrated routes to the new service and everything else to the legacy system, shifting more over time.
flowchart LR client[Clients] --> facade[Facade / router] facade -->|migrated routes| new[New service] facade -->|not-yet-migrated| legacy[Legacy system]
You know what happens. Now see why it works.
Big-bang rewrites are notorious for failing: they're all-or-nothing, hard to test against reality, and freeze feature work for months. The strangler fig delivers value incrementally, keeps the system running throughout, and lets you roll back a single slice instead of the whole migration.
You run old and new side by side for a long time — double the surface, a facade to maintain, and data that may live in both. That coexistence cost buys dramatically lower risk than a big-bang cutover.
What does the facade do in a strangler-fig migration?
It routes each request to either the new or the legacy implementation, so traffic can be shifted incrementally.