Strangler Fig Pattern
Last Updated: May 26, 2026
Modernization usually happens while the old system is still serving users.
A full rewrite asks the organization to reproduce years of behavior, data rules, permissions, edge cases, and integrations before production feedback arrives. That concentrates risk into one large cutover.
The Strangler Fig Pattern takes a different path. It migrates a system incrementally by placing a routing layer in front of the legacy application and moving one capability at a time to a new implementation.
The goal is to keep the client entry point stable while the legacy system shrinks until it has no remaining responsibility.
The Problem With Full Rewrites
A full rewrite can work for a small system with clear behavior and few integrations. It becomes risky when the old system is large, business-critical, and poorly documented.
The usual failure mode is uncertainty: hidden rules, changing requirements, and late production feedback.
Large rewrites run into predictable problems:
| Problem | What Happens |
|---|---|
| Hidden behavior | The legacy system contains business rules that exist only in code, data, or operator habits |
| Moving requirements | The old system keeps changing while the replacement is being built |
| Long feedback cycle | The new system learns from production late in the project |
| All-at-once cutover | Risk is concentrated into one release window |
| Data mismatch | The new system implements the wrong source of truth or misses historical edge cases |
| Organizational drift | Teams optimize for the rewrite instead of shipping value during the migration |
The Strangler Fig pattern reduces this risk by turning one large replacement into many smaller replacements.