Strangler Fig Pattern

The strangler fig is the alternative to the rewrite-from-scratch, which fails for a predictable reason: the legacy system keeps changing while the replacement is built toward a spec frozen in the past. Instead, a facade — a reverse proxy or API gateway — fronts the old system, and functionality moves behind it one route at a time. Every migrated slice ships to production immediately, so progress is real, reversible and visible.

Modernising systems that cannot be paused for a rewrite: a monolith moving to services, a legacy framework being retired, an acquisition being absorbed. It fits wherever the system has seams — URL routes, bounded domains, user segments — that can be redirected independently. The endpoint matters less than the property that at every point in the migration, there is one production system that fully works.

The middle is the expensive part: two systems to operate, monitor and debug, and data that both sides need — shared, synced or duplicated, each option with consistency problems. Migrations also stall when the easy slices are done and the hard core remains; without an owner and an end date, "transitional" architecture quietly becomes permanent.

Put the routing facade in place first (Nginx, an API gateway, a CDN worker) with everything still flowing to the legacy system — zero behaviour change. Then, per slice: build it in the new system, dual-run and compare outputs if the stakes justify it, flip the route (a canary helps), and delete the old path — the deletion is what makes it a migration rather than an accumulation. Track progress by traffic share on the new system.