The strangler pattern lets you replace a legacy system piece by piece, by routing traffic to new components while the old system keeps running. The main benefit is lower risk: you avoid a single high-stakes cutover and instead ship small, reversible changes. The legacy estate shrinks gradually until there is nothing left to retire.
TL;DR:
- Use the pattern when teams can isolate modules or workflows and must keep delivery running; heavy coupling or shared mutable state can make slices impractical.
- Put a simple pass through façade in front of the legacy system, dark launch each new slice against copied production traffic, and compare outputs before routing live requests.
- For stateful slices, keep old and new data stores synchronized in both directions until the new store is authoritative, then retire the legacy path.
- Map system boundaries and data assets, confirm tests and monitoring, set compatible API rules, and define a rollback plan for every slice before migration starts.
Table of Contents
- What is the strangler fig pattern?
- How the strangler pattern actually works
- When does the strangler pattern make sense?
- Prerequisites and best practices before you start
- Running a strangler migration step by step
- How an experienced delivery team runs a strangler engagement
- The practical verdict on strangler migrations
- What the pattern gets right and where teams overthink it
- Modernising your legacy estate without the downtime
- FAQ
- Sources
What is the strangler fig pattern?
The name comes from the strangler fig, a plant that grows around a host tree, slowly taking over its structure until the host is no longer needed. Martin Fowler applied the image to software: you build new functionality around the edges of a legacy system, and over time the legacy system is retired as the new one takes its place.
The core idea is deliberately unglamorous. Instead of rewriting everything at once, you intercept specific pieces of functionality, redirect them to new services, and leave the rest of the legacy system untouched until its turn comes.
- The legacy system stays live and serving traffic throughout.
- New components absorb functionality incrementally, one slice at a time.
- The migration can run for months or years rather than finishing in one release.
This contrasts with a full rewrite, where the old and new systems run in parallel only briefly before a hard cutover, and where a failure in the new build has nowhere to hide.
How the strangler pattern actually works
The mechanics rest on a small set of techniques, each solving a different part of the interception problem with migration plugins for headless CMS.
- Façade or proxy layer: a thin interception point sits in front of the legacy system and routes requests to either the old or the new implementation, based on URL path, header, or feature flag. The Azure Architecture Center describes this façade/proxy approach as the standard entry point for a strangler migration.
- Content-based routing: once the façade exists, routing rules decide which requests go where, letting you shift traffic percentage by percentage rather than all at once.
- Event interception: for systems built on events or messages, you intercept specific event types and route them to the new service, leaving the rest of the event stream untouched; Fowler’s own write-up on rebuilding a strangler system treats event interception and asset capture as the practical mechanism for moving both behaviour and state.
- Asset capture and bi-directional migration: stateful data needs special handling. You pick which asset types move first, then keep the old and new stores synchronised in both directions until the legacy store can be switched off, a technique Fowler calls asset capture.
- Dark launches and comparison testing: before routing real traffic to a new component, send it a copy of production traffic and compare the responses, a method the Gov recommends specifically to validate replacements without disrupting dependent teams.
Wrappers make sense when you only need to intercept and redirect calls without changing behaviour; building a new API-first service makes sense once that slice needs new logic, new data ownership, or independent scaling.
Pro Tip: Start the façade with a simple pass-through before adding routing logic, so you can prove the interception point works before anything depends on it.
When does the strangler pattern make sense?
The pattern fits best when a system can be cut into independent slices and the business cannot tolerate downtime during migration.
- Domains can be isolated: a module, API, or workflow can be identified with clear boundaries and limited coupling to the rest of the system.
- Delivery has to continue uninterrupted: the business cannot accept a long freeze while a rewrite is built and tested.
- Risk reduction matters more than speed: stakeholders would rather migrate in small, reversible steps than bet everything on one release.
- Heavy coupling or shared mutable state across modules can make slicing impractical; Gartner’s analysis of modernisation strategy names coupling and complexity as the main blockers that push teams towards refactor or rehost instead.
- Your organisation already runs CI/CD, automated testing, and has governance in place for cross-team changes; without these, each slice becomes its own mini-crisis.
Prerequisites and best practices before you start
A strangler migration succeeds or fails on groundwork done before the first façade is deployed.
- Automated test coverage and observability across the legacy system, so you can tell whether a new slice behaves the same way as the old one.
- API versioning and backward compatibility policies, so consumers of the legacy interface are not broken mid-migration.
- Domain discovery work to map bounded contexts and pick small vertical slices rather than horizontal layers.
- Governance and deployment automation, including rollback plans for every slice, not just the first one.
- Early involvement of domain architects and clear decision rights, which practitioner accounts from technical teams at DWP Digital link to materially better outcomes on long-running modernisation programmes.
Pro Tip: Treat the rollback plan as part of the slice definition, not an afterthought: if you cannot describe how to revert a slice in one sentence, it is too large.
Running a strangler migration step by step
A strangler migration follows a repeatable sequence, slice after slice, rather than a single project plan.
- Map bounded contexts and assets. Identify the modules, data stores, and integration points in the legacy system, then rank candidate slices by business value and coupling.
- Pick a small first slice. Choose something that delivers visible value quickly and has minimal dependencies on the rest of the system; Fowler’s guidance on asset capture specifically recommends this for the first move.
- Build the façade and routing rules. Put a proxy in front of the legacy endpoint and route a defined percentage of traffic to the new implementation.
- Dark-launch and compare. Send production traffic to the new slice without exposing its responses to users, then compare outputs against the legacy system before cutting over, following the approach set out in the Gov.
- Add bi-directional migration for stateful slices. Keep old and new data stores synchronised until you are confident the new store is authoritative.
- Monitor, iterate, decommission. Track error rates and latency on both paths, fix discrepancies, then retire the legacy path for that slice and move to the next.
The strangler approach reduces large-scale rewrite risk by allowing frequent, small releases that prove value and let teams adjust strategy as they go, according to AWS’s prescriptive guidance on the pattern.
A mobile-specific proof of concept documented by Thoughtworks showed teams embedding a modern micro-app inside a legacy app, which shortened time to first value and improved cycle time compared with waiting for a full rewrite. That pattern, with incremental embedded progress before full replacement, repeats across many successful strangler programmes regardless of platform.
How an experienced delivery team runs a strangler engagement
Running a strangler migration well depends less on the pattern itself and more on who is holding the map. We bring senior nearshore teams to legacy modernisation work, which matters because slicing decisions need people who have seen where coupling hides in enterprise estates.
- We use AI-assisted analysis to accelerate the discovery phase, mapping dependencies and candidate slices faster than manual audits.
- Our CTT Locky transition is one example of the kind of seamless platform migration this approach supports.
- A typical engagement runs in three phases: an assessment of the legacy estate and its coupling, a pilot slice delivered and validated in production, then scaled delivery across the remaining slices.
The practical verdict on strangler migrations
The strangler pattern earns its reputation: incremental replacement reduces risk and keeps the business running while legacy code is retired piece by piece. The next step is concrete: pick one small, low-coupling slice and run a short proof of concept before committing to a full programme. Our legacy modernisation page has more on how that pilot phase typically works.
What the pattern gets right and where teams overthink it
The strangler pattern’s real value is not the façade or the routing table, it is the discipline of shipping in small, reversible increments. Teams that treat it as a technical recipe, bolt on a proxy, route some traffic, call it done, tend to underestimate the governance and data-synchronisation work that makes each slice safe to retire.
Conventional advice often frames the pattern as a purely technical exercise: pick a tool, build a façade, route traffic. That misses where most strangler programmes actually stall, which is domain discovery. Teams that skip careful bounded-context mapping end up with slices that are too large, too coupled, or too entangled with shared state to migrate safely, and they rediscover the big-bang risk they were trying to avoid.
If we had to prioritise one thing for a reader starting this work, it would not be the routing layer. It would be spending real time identifying the smallest possible first slice with the least coupling, even if that slice looks too modest to justify the effort. Momentum and trust in the approach matter more early on than scope.
— Polarising Team
Modernising your legacy estate without the downtime
We help enterprise teams run strangler-style modernisation without stopping the business to do it, using senior nearshore engineers who have experience with the coupling and governance problems that slow these programmes down.
If you are weighing up where to start, our AI-assisted legacy system analysis service maps your bounded contexts and coupling before you commit to a slice, so the first move is the right one.
FAQ
What is the strangler pattern in software development?
The strangler pattern is an incremental migration approach where a legacy system is gradually replaced by new components built around its edges, rather than rewritten in one release. Traffic is routed slice by slice to the new system until the legacy system can be retired.
What is a strangler?
In this context, a “strangler” refers to the new system or component that progressively takes over functionality from a legacy application, the way a strangler fig plant grows around a host tree. The legacy system keeps running underneath until it is no longer needed.
Why is it called the strangler fig pattern?
The name borrows directly from the strangler fig plant, which grows around a host tree and eventually replaces its structure entirely, a metaphor Martin Fowler used to describe software built incrementally around a legacy system. The host tree, like the legacy system, is not removed, it is gradually displaced.
What is a strangler fig application?
A strangler fig application is a system built using this incremental approach: new functionality is added around a legacy application’s edges, intercepting and replacing pieces of behaviour until the original application is fully retired. It differs from a rewrite because the legacy system stays in production throughout the process rather than being replaced in a single cutover.
Sources
- Strangler Fig
- Strangler fig pattern – Azure Architecture Center
- Gov
- Using the Strangler Fig with Mobile Apps