What is the strangler fig pattern for legacy migration?
Quick Answer
Instead of a risky big-bang rewrite, you put a routing facade in front of the legacy system and incrementally replace one capability at a time — new code handles the migrated routes, the legacy handles the rest — until the old system is “strangled” and can be removed.
It's the incremental alternative to rewriting a legacy system from scratch. You stand up a facade — usually a reverse proxy — in front of the old application, and then you carve off one piece at a time: reimplement the reporting module in the new stack, point the proxy's /reports routes at it, leave everything else hitting the legacy app. Over months you migrate slice by slice until nothing routes to the old system and you delete it. The name comes from the strangler fig that grows around a tree. The advantage is you're never in a broken state and each slice is independently shippable and reversible; the cost is running two systems and syncing data during the overlap.
- Named after a vine that grows around a tree and eventually replaces it.
- The facade (reverse proxy / gateway) decides per-request whether to route to old or new.
- Pair with an anti-corruption layer so the new code isn't forced to adopt the legacy model.
- Benefits: ship value continuously, always have a working system, roll back a slice easily. Cost: running both systems and keeping data in sync during the transition.