The Strangler Fig Pattern: Migrating Legacy Systems Without Downtime

The Legacy Migration Dilemma

Every engineering team eventually inherits a legacy system that needs replacement. The big rewrite approach fails more often than it succeeds. The Strangler Fig pattern — gradually replacing functionality by intercepting calls and routing them to new services — has a much better track record.

How the Pattern Works

Named after the strangler fig tree that grows around its host, the pattern places a proxy in front of the legacy system. Initially, all requests pass through to the old system. As you build new services, the proxy gradually routes specific endpoints to the new implementation. Eventually, the legacy system handles zero traffic and can be decommissioned.

Proxy Implementation

Your proxy can be an API gateway, a reverse proxy like NGINX, or a custom middleware layer. The key requirements:

• Route based on URL path, header, or user segment
• Support gradual traffic shifting (1%, 10%, 50%, 100%)
• Enable instant rollback to the legacy system
• Log all routing decisions for debugging

Data Migration Strategy

Data is always the hardest part. Use dual-write during the transition: write to both old and new data stores, read from the new one, and verify consistency. Once confident, stop writing to the old store. The dual-write period should be measured in weeks, not months.

Key Takeaways

• Never do a big rewrite — strangler fig has a proven track record
• Start with the easiest, lowest-risk functionality to build momentum
• Use feature flags alongside the proxy for fine-grained control
• Dual-write for data migration, verify consistency continuously
• Set a deadline for legacy decommissioning — orphaned systems linger forever