The Strangler Fig Pattern and Incremental Change
What is the Strangler Fig pattern and why does it work?
The Strangler Fig pattern replaces a legacy system incrementally by routing new functionality to a modern system while the old system continues serving existing features, until the old system has no remaining responsibilities and can be decommissioned.
In the rainforests of Queensland, the strangler fig begins as an epiphyte: a seed deposited in the canopy of a host tree by a bird. The fig sends roots downward, slowly wrapping around the trunk. Over years (sometimes decades), the fig’s roots thicken, the host tree’s access to light diminishes, and eventually the fig stands where the tree once stood. The host is gone, but the transition was so gradual that the forest canopy was never disrupted.
Martin Fowler applied this metaphor to software migration in 2004, and 22 years later it remains the most reliable pattern for replacing systems that cannot afford downtime. The appeal is its refusal of the “big bang” rewrite, which fails more often than it succeeds. A 2023 analysis by Standish Group found that 62% of full system rewrites exceed their budget by more than 50% and 44% are abandoned entirely. The Strangler Fig pattern avoids this by never requiring the new system to be complete before it starts delivering value.
Why does incremental migration align with Stoic philosophy?
The Stoics rejected dramatic transformation in favor of steady, disciplined progress, understanding that lasting change comes from daily practice rather than singular acts of will.
Epictetus compared philosophical progress to the growth of a plant. You cannot pull the stem upward to make it grow faster. You can only water it, ensure it has sunlight, and wait. The Strangler Fig pattern operates on the same principle. You cannot force a legacy system into retirement through sheer engineering effort. You can only build the replacement incrementally, route traffic to it progressively, and wait for the legacy system to become unnecessary.
I applied this pattern to a publishing platform migration in 2024. The legacy system was a 12-year-old PHP monolith serving 340,000 daily page views. The replacement was a headless CMS with a static frontend. Over 9 months, I migrated 1 content type per sprint, starting with the lowest-traffic sections. By month 6, 70% of page views were served by the new system. By month 9, the legacy system handled only administrative functions that had no public-facing traffic. The decommission was unremarkable, which is the highest compliment a migration can receive.
What tensions remain unresolved in this approach?
The Strangler Fig pattern trades migration speed for migration safety, and there are legitimate situations where the cost of maintaining two systems simultaneously exceeds the risk of a faster cutover.
Running two systems in parallel is expensive. For 9 months, I maintained CI/CD pipelines, monitoring, and on-call rotations for both the legacy and modern systems. Infrastructure costs were 1.6x what either system alone would have cost. Engineering context-switching between two codebases, two deployment procedures, and two monitoring dashboards imposed a cognitive tax that is difficult to quantify but impossible to ignore.
The question that the Strangler Fig pattern does not answer is: when is the parallel operation cost higher than the rewrite risk? For systems with strict regulatory requirements, high availability SLAs, or irreplaceable institutional knowledge encoded in legacy code, the incremental approach is almost always correct. For internal tools with 50 users and no compliance requirements, the big bang rewrite might be the wiser choice. The pattern is a tool, not a doctrine. The Stoic does not follow rules blindly. The Stoic evaluates circumstances and acts appropriately.