Strangler Fig Pattern: Replacing Legacy Systems Incrementally Without a Big Bang
How the strangler fig pattern replaces legacy systems step by step: routing layers, slicing by capability, data strategies and anti-corruption layers.
How does the strangler fig pattern work?
Place a routing layer (a proxy, API gateway or facade) in front of the legacy system; choose a first slice of capability with clear boundaries; build it in the new system, with an anti-corruption layer translating between old and new; route that slice's traffic to the new system, often gradually; resolve data ownership for the slice; repeat; and retire the legacy system when nothing depends on it. It trades a longer period of coexistence for much lower risk than a big-bang rewrite (Martin Fowler).
This guide is for CTOs and engineering leads. For the business decision of whether and how to modernise, see legacy software modernisation.
Key takeaways
- Intercept first: you need a place to route traffic.
- Slice by business capability, not by technical layer.
- Decide data ownership for each slice.
- Protect the new design with an anti-corruption layer.
- Measure and retire old parts as you go.
Steps
- Map the legacy system's capabilities, users, integrations and data.
- Intercept requests with a proxy, gateway or facade; for batch jobs and integrations, find equivalent interception points.
- Choose a first slice: valuable, reasonably independent and low risk, such as reporting or a single product line.
- Build it in the new system with tests and monitoring.
- Route traffic gradually, comparing results where possible.
- Move data ownership for the slice.
- Retire the legacy code for that slice; repeat.
Data strategies
| Strategy | How it works | Trade-off |
|---|---|---|
| Read legacy data | New components read the old database temporarily | Fast start; keeps coupling |
| Synchronise | Change data capture or events keep old and new stores aligned | Complexity; conflict handling |
| Move ownership | New system owns the data; legacy reads from it | Cleanest end state; needs legacy changes |
Testing and parallel runs
For critical calculations, run old and new side by side and compare outputs before switching, sometimes called shadowing. Use feature flags or routing rules to move users in stages, and keep the ability to route back. Reconcile data between systems during the transition. See feature flags and data migration.
When it does not fit
- You cannot intercept traffic or integrations.
- The system is small and well understood; replace it in one go.
- A packaged product replaces it entirely; plan a migration instead.
- Core data cannot be separated by capability.
- There is no commitment to finish; half-strangled systems cost more than either end state.
Hypothetical example: an insurer's policy system
This example is hypothetical. An insurer's 20-year-old policy administration system handled quotes, policies, renewals and claims. The team put an API gateway in front of it, rebuilt quoting first for one product line with an anti-corruption layer translating legacy policy codes, and ran old and new quote calculations in parallel for a month before switching. Renewals followed, with change data capture keeping policy data in sync. Claims remained on the legacy system until a later phase.
Common mistakes
- No interception point, so traffic cannot be moved.
- Slicing by technical layer instead of capability.
- Copying the legacy data model into the new system.
- Never retiring old parts.
- No reconciliation between old and new.
Related guides
- Modular monolith vs microservices for the target architecture.
- Software architecture review for assessing the legacy system.
- Integration architecture patterns for intercepting integrations.
- AI legacy code modernisation for understanding old code.
Conclusion
The strangler fig pattern replaces legacy systems through many small, reversible steps: intercept, slice, build, route, move data and retire. It needs patience and commitment to finish, and it usually beats a big-bang rewrite on risk.
Planning to replace a legacy system?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on incremental modernisation and new platforms. If it would help to find the first slice, we are happy to talk it through.
Common questions.
An approach to replacing a legacy system gradually: put a routing layer in front of it, build new functionality alongside, move capabilities and their users across one slice at a time, and retire the old system when nothing depends on it. Martin Fowler named it after strangler fig vines that grow around a host tree.