The Strangler Fig Pattern: Growing Better Software Without Breaking Everything
In software development, rebuilding a system from the ground up sounds exciting. Many teams dream of deleting old code, starting fresh, and building something cleaner and more modern.
But reality is usually more complicated.
Large systems support real customers, business operations, and important services. Replacing everything at once can be risky, expensive, and slow. This is where the Strangler Fig pattern becomes useful.
Despite its unusual name, the Strangler Fig pattern is one of the safest ways to modernise software without causing major disruption.
What Is the Strangler Fig Pattern?
The Strangler Fig pattern is a software migration strategy where an old system is replaced slowly, piece by piece, instead of all at once.
The name comes from the Strangler Fig tree found in tropical forests.
A strangler fig starts life by growing around another tree. At first, it depends on the host tree for support. Over time, it grows stronger, expands its roots and branches, and slowly replaces the original structure around it.
Software teams can follow a similar process.
Instead of shutting down a legacy system and rewriting everything, developers build new features or services around the existing system. Little by little, responsibilities move from the old system to the new one until the old code is no longer needed.
In simple terms: the old system is replaced gradually instead of suddenly.
Why Big Rewrites Often Fail
Many companies try to rebuild systems through a large rewrite project.
The idea sounds simple: stop improving the old system, create a modern replacement, and switch everything when it is ready.
However, these projects often run into problems.
The Project Becomes Too Large
A complete rewrite usually takes longer than expected.
As developers rebuild features, business needs continue changing. New requests arrive, priorities shift, and teams struggle to keep the old and new systems aligned.
Sometimes the rewrite is never fully finished.
Hidden Knowledge Gets Lost
Legacy systems may look messy, but they often contain years of business logic.
There are usually strange rules, edge cases, and small fixes that nobody remembers clearly.
When teams rewrite everything from scratch, they sometimes accidentally remove behaviour that customers quietly depend on.
Risk Becomes Too High
Replacing an entire system in one moment creates pressure.
If something fails after launch, the business may experience outages, lost revenue, or unhappy users.
A “big bang” migration can become dangerous very quickly.
How the Strangler Fig Pattern Works
The Strangler Fig approach reduces risk by breaking migration into smaller steps. Instead of replacing everything immediately, teams gradually move features into a new system.
flowchart LR
A([Legacy System\nStill Running]) --> B[Build New Feature\nin Modern Architecture]
B --> C[Deploy Alongside\nLegacy]
C --> D[Redirect Traffic\nGradually]
D --> E{Stable?}
E -- No --> F[Roll Back\n& Investigate]
F --> B
E -- Yes --> G[Delete Old Code]
G --> H{More to\nMigrate?}
H -- Yes --> B
H -- No --> I([Migration\nComplete])
style A fill:#78350f,color:#fcd34d
style I fill:#14532d,color:#86efac
style F fill:#7f1d1d,color:#fca5a51. Keep the Existing System Running
The legacy system continues working while development happens.
Customers keep using the product, and the business stays stable.
This reduces pressure because teams are not forced into an immediate deadline.
2. Build New Features Separately
Instead of adding every new feature to the old system, developers create them in a modern architecture.
For example, a company might slowly move from a large monolithic application into smaller services.
At first, only one feature may be migrated. Then another. Then another.
3. Redirect Traffic Slowly
Once a new feature becomes stable, requests are redirected from the old system to the new one.
This can happen gradually - perhaps only a small percentage of users move first. If problems appear, teams can quickly roll back changes.
flowchart TD
U([Users / Clients]) --> P[Routing Layer\nFacade ยท API Gateway]
P -->|Legacy traffic| L[Legacy Monolith]
P -->|Migrated traffic| N[New Service]
L -.->|Shrinks over time| L
N -.->|Grows over time| N
style L fill:#7f1d1d,color:#fca5a5
style N fill:#14532d,color:#86efac
style P fill:#1e3a5f,color:#93c5fd4. Remove Old Parts
When the new implementation becomes reliable, the old code is deleted.
This process repeats until the legacy system becomes smaller and smaller. Eventually, there is little left to maintain.
Benefits of the Strangler Fig Pattern
The Strangler Fig approach works well because it lowers risk while still allowing progress.
| Benefit | Why It Matters |
|---|---|
| Lower risk | Small changes are easier to test and fix than massive migrations |
| Faster business value | Teams deliver improvements step by step rather than waiting years |
| Easier learning | Mistakes during migration can be corrected before more systems move |
| Better team confidence | Visible progress with smaller milestones feels more achievable |
Challenges of the Strangler Fig Pattern
The Strangler Fig pattern is useful, but it is not magic.
Temporary Complexity
For a period of time, teams must maintain both old and new systems.
This increases operational complexity. Monitoring, debugging, and communication become more important.
Migration Can Take Time
Because the process happens gradually, patience is required.
Leaders sometimes become frustrated because they expect instant transformation.
Clear Boundaries Matter
The migration works best when teams clearly separate responsibilities.
If system boundaries are unclear, dependencies can become confusing and slow progress.
When Should You Use It?
The Strangler Fig pattern is especially useful when:
- A system is too large to rewrite safely
- Customers depend heavily on uptime
- Teams want gradual modernisation
- Legacy code contains important but unclear business logic
- Risk must stay low during change
It may be less useful for very small systems where rebuilding everything is quick and inexpensive.
The Bigger Lesson
The Strangler Fig pattern teaches an important idea: software does not always need dramatic change.
Sometimes improvement works better through steady growth.
Instead of destroying the old system and hoping the replacement succeeds, teams slowly build something stronger around what already exists.
In many cases, software evolution works more like gardening than demolition.
You grow, replace, and improve over time - and eventually, without creating chaos, the old system naturally fades away.