Strangler-Fig Rollout Checklist

When to Use This Checklist

Use this checklist to run a strangler-fig migration, a strategy for replacing a legacy system gradually rather than rewriting it all at once. Named after the vine that grows around a tree until it can stand alone, the pattern wraps the legacy system in a routing facade and replaces functionality slice by slice. It suits high-risk legacy systems where a big-bang rewrite is unacceptable.

How to Use This Checklist

Map the legacy surface and choose a low-risk first slice. Stand up the routing facade so all traffic flows through one place you can re-route. Use an anti-corruption layer to keep legacy data models from leaking into the new code. Build the first slice to behavioral parity, optionally shadow it, then route a fraction of traffic and watch the metrics. Synchronize data between old and new stores and set automatic rollback thresholds.

Iterate slice by slice, decommissioning legacy components only after each is stable.

What Good Looks Like

A healthy strangler-fig rollout routes all traffic through a facade, replaces one verified slice at a time, and keeps data synchronized across both systems. Each slice ships behind metrics with automatic rollback, observability spans both paths, and stakeholders can see migration progress. Legacy components retire only after their replacement is proven.

Common Pitfalls

The biggest mistake is skipping the facade and re-routing in scattered places, which makes rollback impossible. Letting legacy data models bleed into new services without an anti-corruption layer recreates the legacy mess. Migrating too large a slice at once defeats the incremental safety. Retiring legacy components before the new slice is proven removes the fallback.

Related Resources

See the strangler-fig pattern and anti-corruption layer, the continuous modernization playbook for sustaining the effort, and feature flags and canary release practices for controlled traffic shifts.