Strangler Fig Pattern for Legacy Migration
The Strangler Fig pattern, named after the tropical plant that gradually envelops its host tree, is a strategy for incrementally replacing a legacy system with a new one. Rather than undertaking a high-risk big-bang rewrite, the Strangler Fig pattern allows teams to replace functionality piece by piece, routing traffic to the new system while the legacy system remains operational. This approach dramatically reduces risk and allows continuous delivery of value.
Core Mechanism
The pattern works by intercepting calls to the legacy system and routing them to either the legacy implementation or the new implementation. A routing layer—typically an API gateway, reverse proxy, or application-level router—determines which version handles each request. Over time, more features are routed to the new system until the legacy system is entirely unused.
The routing decision can be based on URL paths, HTTP headers, feature flags, user segments, or any other request attribute. This flexibility allows teams to test new implementations with internal users before expanding to broader audiences.
Feature Toggle Integration
Strangler Fig implementations often use feature toggles to control migration. A feature toggle can route a specific function—say, user authentication—to either the legacy or new system. As the new implementation matures, the toggle is flipped for increasingly large user segments until the legacy path is fully decommissioned.
This approach enables canary releasing of new implementations. A team can start with 1% of traffic going to the new system, monitor for errors and performance regressions, and gradually increase the percentage. If issues arise, the toggle is simply flipped back, instantly restoring the legacy behavior.
Routing Strategies
Several routing strategies support the Strangler Fig pattern. The simplest is URL-based routing, where specific endpoints are redirected to the new system. More sophisticated approaches use a reverse proxy like Nginx, HAProxy, or Envoy that inspects request attributes and routes accordingly. Application-level routers can make routing decisions based on business logic, user attributes, or experimental conditions.
For database-level strangulation, the new system may start by owning new data while the legacy system serves existing data. As features migrate, the new system takes over more data responsibilities, eventually becoming the system of record for all data. Dual-write patterns can keep both systems synchronized during the transition.
Challenges and Mitigations
The Strangler Fig pattern introduces operational complexity. The routing layer must be maintained, and teams must coordinate migration activities to avoid conflicts. Data synchronization between legacy and new systems is often the hardest part, especially when the legacy system has accumulated years of implicit business rules.
Incremental strangulation also requires disciplined interface design. Each piece of extracted functionality must have a well-defined boundary, which often reveals hidden coupling in the legacy system. This discovery process is valuable but can slow migration timelines.
When to Use
The Strangler Fig pattern is ideal for replacing monolithic applications that cannot be rewritten quickly, systems with high business risk where downtime is unacceptable, and scenarios where the legacy system lacks automated tests. It is less suited to small, well-understood systems where a rewrite is faster and cheaper.
Ultimately, the Strangler Fig pattern is the safest path to modernizing critical legacy systems, prioritizing risk reduction over speed. It has been successfully used by organizations including Amazon, Microsoft, and countless enterprises to migrate from monoliths to microservices.