Strangler-Fig Modernization Program Playbook
Replace a legacy system incrementally with the strangler-fig pattern. Route traffic through a facade, replace capabilities in waves with shadow testing, then strangle and decommission the legacy.
The strangler-fig pattern replaces a legacy system gradually: new functionality grows around the old system, taking over capabilities one at a time, until the legacy is fully strangled and removed. This playbook runs that pattern as a long-lived program where the legacy keeps serving production until each replacement proves itself.
Phase-by-Phase
Facade and Routing Layer. Place a routing facade (typically an API gateway or reverse proxy) in front of the legacy system so traffic can be redirected per capability without callers noticing. Map the legacy endpoints and capture a metrics baseline.
Anti-Corruption and First Replacement. Build an anti-corruption layer that isolates the new code from the legacy data model. Replace the first capability and shadow-test it against the legacy by sending it real traffic without serving its responses, comparing outputs until confidence is high.
Incremental Replacement Waves. Replace capabilities in priority waves, shifting traffic progressively with canaries and feature flags, and retiring legacy modules as their replacements stabilize. The expand-and-contract pattern keeps data migrations safe across the dual-running period.
Final Strangle and Decommission. Once all traffic flows to the new system, remove the routing facade and decommission the legacy. Blameless postmortems on any incidents during cutover feed the runbooks.
Team and Roles
An architect owns the routing strategy and decision records. Backend engineers build replacements and the anti-corruption layer. DevOps and SRE run the gateway, traffic shifting, and observability. Product prioritizes capabilities by business value.
Risks and Mitigations
Dual-system consistency is the central risk while old and new run together; shadow testing and the expand-and-contract pattern keep data coherent. Routing complexity can grow unwieldy, so keep the facade configuration as code and well documented. Guard against scope creep by replacing along business value. Strong observability keeps the dual system debuggable.
Success Criteria
Success is a steadily falling percentage of traffic hitting the legacy, rising feature-delivery rate on the new system, and strong deployment frequency and MTTR. The legacy should be fully decommissioned at program end.
Tooling
Use a reverse proxy or API gateway for routing, Kubernetes for the new services, Kafka for integration events, PostgreSQL for new data stores, and Datadog or an equivalent for shadow-comparison and observability.