Free — no signup required

The Three Phases of Strangler Fig Migration

2 min read

A Structured Approach

While the analogy is organic, the actual implementation follows a disciplined three-phase structure. Understanding these phases prevents teams from jumping ahead and creating chaos.

Phase 1: Intercept — Place a routing layer (proxy) in front of the legacy system. Initially, it passes 100% of traffic through unchanged. This is the "seed in the canopy" moment. The system behaves identically to before, but you now have a control point.

Phase 2: Replace — Build new services that implement specific slices of functionality. Route traffic for those slices to the new services via the proxy. Keep the legacy system handling everything else. This is the "roots growing down" phase. Each slice migrated reduces the monolith's responsibility.

Phase 3: Retire — Once a piece of legacy functionality has zero traffic and the new service is proven stable, delete the old code and decommission the old infrastructure for that slice. This is the "host tree decomposing" phase. Code deletion is a first-class deliverable.

These phases repeat in a loop for each piece of functionality you migrate. You might be in Phase 1 for the "Payments" module, Phase 2 for "User Profiles," and Phase 3 for "Notifications" — all simultaneously.

The key discipline is: never skip Phase 1. Without the proxy, you have no control point, no ability to shift traffic gradually, and no way to roll back safely. Teams that skip directly to Phase 2 end up with a hard cutover — which is just a Big Bang rewrite with extra steps.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free