Strangler Fig Pattern
The Strangler Fig pattern is a software migration strategy, named after the strangler fig plant that gradually envelops and replaces a host tree, in which a legacy system is incrementally replaced by routing individual pieces of…
Definition
The Strangler Fig pattern is a software migration strategy, named after the strangler fig plant that gradually envelops and replaces a host tree, in which a legacy system is incrementally replaced by routing individual pieces of functionality to a new system over time, until the old system can eventually be decommissioned.
Overview
Coined by Martin Fowler in 2004, the term draws its name from the strangler fig, a plant that germinates in the canopy of a host tree and grows downward, gradually enveloping the host in its roots and vines until the original tree dies and rots away, leaving only the fig, now able to stand on its own where the host once stood. Applied to software, the Strangler Fig pattern describes replacing a legacy system incrementally rather than through a risky 'big bang' full rewrite, by building new functionality alongside the old system and gradually redirecting traffic or calls for each piece of functionality from the old system to the new one. A typical implementation introduces a facade or routing layer in front of the legacy system, through which all incoming requests pass. Initially, this facade routes everything to the legacy system unchanged. As new, replacement functionality is built for a specific feature or module, the facade is updated to route requests for that feature to the new implementation instead, while everything else continues to flow to the legacy system. This process repeats feature by feature until the facade routes all traffic to the new system, at which point the legacy system's remaining code paths for that functionality can be safely removed, and eventually the legacy system is fully decommissioned. This incremental approach substantially reduces the risk associated with large rewrites, which historically have a poor track record — big-bang rewrites frequently run over budget, over schedule, or fail outright, in part because the legacy system continues to evolve (with bug fixes and new requirements) while the rewrite is being built, causing the target to keep moving. By migrating incrementally, teams can validate each migrated piece in production, roll back individual pieces if problems arise, and continuously ship value throughout the migration rather than betting everything on a single cutover event. The pattern is especially common in monolith-to-microservices migrations, where the facade/routing layer often takes the form of an API gateway or reverse proxy, and is frequently discussed alongside the Anti-Corruption Layer pattern, which addresses how the new and legacy systems communicate safely with each other during the transition period.
Key Concepts
- Incrementally replaces a legacy system rather than rewriting it all at once
- Named after the strangler fig plant, which gradually envelops and replaces its host tree
- Coined and popularized by Martin Fowler in 2004
- Uses a facade or routing layer to direct requests to old or new implementations
- Reduces risk compared to high-stakes 'big bang' rewrites
- Allows incremental validation, rollback, and continuous delivery during migration
- Common in monolith-to-microservices migration strategies
- Often paired with an Anti-Corruption Layer to manage old/new system interaction