Strangler Migration Planning

Overview

Named by Martin Fowler after strangler figs that grow around a host tree, this approach grows the new system around the old one until the old can be removed. Planning matters as much as the technique: sequence, ownership of data, and an end date.

Good slices are vertical and bounded: a capability with a clear interface, limited shared data, and measurable behavior. Avoid slicing by technical layer, since that leaves both systems involved in every request and multiplies coordination.

How it works

A facade routes each capability to old or new implementations.

client -> routing facade
   /orders/*   -> NEW service   (100%)
   /invoices/* -> split 20% NEW / 80% LEGACY (shadow compare)
   /reports/*  -> LEGACY
Burn-down: 12 routes remain; legacy decommission target: 2027-03-31

Validate behavior before cutting over. Shadow traffic sends copies of requests to the new service and compares responses without affecting users. Then shift a small percentage, watch error rates and latency, and increase. Keep rollback to the legacy route available until the slice has run cleanly for an agreed period.

Pitfalls

• No decommission date or owner, so the legacy never dies
• Migrating code but leaving data in the old database, creating hidden coupling
• Starting with the hardest slice instead of a small, valuable first win
• Allowing new features in legacy, which grows the target

Key takeaways

• Sequence slices by value, risk, and coupling
• Route through a facade and shift traffic gradually
• Move data ownership explicitly
• Track burn-down and set a retirement date