Architecture Practice

Strangler Fig Pattern

Also known as: strangler pattern, incremental migration

Definition

The strangler fig pattern replaces a legacy system incrementally: a facade routes traffic, new functionality is built alongside the old, and routes are cut over one at a time until the original can be removed. It avoids the big-bang rewrite by keeping the system shippable throughout.

Last reviewed · Part of the Architecture Glossary

In practice

The mechanism is a facade at the edge — a reverse proxy, an API gateway, or a routing layer inside the monolith — that can send each route to old or new independently.

The sequence that works:

  1. Put the facade in front of the unchanged legacy system. Ship it. Nothing else changes yet, and this step alone is where most migrations stall.
  2. Pick the first slice by a specific criterion: high change rate, clear boundary, low coupling, and not the hardest part.
  3. Build it new, run both, compare. Dark launch — send the read to both and diff the results in the background. This is how you find the undocumented behaviour that nobody could tell you about.
  4. Cut over behind a feature flag, percentage by percentage, with the rollback being a flag change rather than a deploy.
  5. Delete the old path. The step that gets skipped, which is how organisations end up permanently running two systems.

When it matters

Any legacy replacement large enough that a rewrite would take more than a quarter — which is most of them.

Common mistake

Starting with the hardest module to "prove it can be done." The team burns six months, ships nothing, and the migration loses its funding. Start with a slice that delivers visible value in weeks and establishes the routing, testing and comparison machinery for everything after it.

See also

Go deeper