The strangler pattern replaces a legacy system incrementally, one piece of functionality at a time, instead of freezing feature work for a big-bang rewrite. Martin Fowler named it after the strangler fig, a vine that grows around a host tree and gradually replaces it while the tree keeps standing until it does not. Applied to software, the old system keeps serving traffic for anything not yet migrated, while new functionality is built and cut over incrementally behind a routing layer.
How it works
The core mechanism is a routing layer sitting in front of both the old and new systems, deciding per request which one handles it.
- Put a routing layer in front of the legacy system first, even before any new code exists — an API gateway, reverse proxy, or load balancer rule that currently routes 100% of traffic to the old system.
- Pick the first piece to migrate. Choose a bounded, well-understood capability, not the most complex or highest-risk one first. Build confidence in the pattern before tackling the hard parts.
- Build the replacement alongside the legacy system. The new implementation runs in parallel; it does not need to be deployed together with the old code.
- Route a slice of traffic to the new implementation. Start with internal traffic or a small percentage of production requests, and compare outputs against the legacy path.
- Increase the routed percentage as confidence grows, monitoring error rates and output parity at each step.
- Decommission the legacy code path once 100% of relevant traffic is on the new system and it has run safely for a full business cycle.
- Repeat for the next piece, until the legacy system has nothing left to serve.
Strangler pattern vs the alternatives
| Approach |
Risk profile |
Feature freeze required |
Rollback |
| Strangler pattern |
Low, incremental |
No, old system keeps shipping |
Route traffic back per slice |
| Big-bang rewrite |
High, all-or-nothing |
Yes, often for months |
Difficult, reverting means un-launching everything |
| Parallel run, hard cutover |
Medium |
Partial |
Possible but abrupt |
| In-place refactor (no new system) |
Low-medium |
No |
Standard code revert |
The strangler pattern costs more in total engineering time than a clean rewrite would in the best case, because you maintain two systems during the transition. It wins because the worst case is so much less catastrophic — a bad slice of traffic can be routed back instantly, and the business never stops shipping.
Common mistakes
Migrating the hardest, highest-risk piece first. Build confidence and tooling on a low-risk capability before tackling the piece with the most business impact or the most tangled dependencies.
No clear data ownership during the transition. If both the old and new systems can write to the same data, you need an explicit strategy, such as a single writer with the other reading, or a reconciliation process, or you will get silent data corruption.
Treating the routing layer as an afterthought. Retrofitting request-level routing after the new system is half-built is far more expensive than putting a router in front of the legacy system on day one, before any new code exists.
Never finishing the migration. Without a forcing function, teams migrate the easy 80% and leave the hard 20% running on the legacy system indefinitely, which means maintaining three systems instead of one.
FAQ
Where does the name "strangler pattern" come from?
Martin Fowler coined it, drawing on the strangler fig, a vine that grows around a host tree and gradually replaces its structure while the original tree is still standing.
Do I need microservices to use the strangler pattern?
No. The pattern is about incremental replacement behind a routing layer — it applies whether the replacement is a new monolith, a set of services, or a rewritten module within the same deployable.
How long does a strangler migration typically take?
It varies widely with system size, but expect months to a few years for a large legacy system, migrated piece by piece rather than on a fixed calendar deadline.
What happens to data that both systems need during the migration?
You need an explicit ownership model: designate one system as the source of truth for a given piece of data at any time, or implement careful dual-write with reconciliation, and avoid ambiguity about which write wins.
Where to go next
Read refactoring legacy code, a safe process for 2026 for how to handle the pieces you are not replacing outright, and API deprecation strategy for 2026 for retiring the legacy endpoints once traffic has moved. For the infrastructure side of routing traffic between old and new systems, see Kubernetes explained in 2026.