Strangler Fig (pattern)

What is it

The Strangler Fig pattern is a way to modernize a legacy system piece by piece, instead of rewriting it entirely and switching over overnight. The new system is built around the old one, takes over its functions one at a time, and when nothing is left in the original system, it’s switched off.

For a manager: it’s the difference between replacing an airplane’s engine part by part in flight and grounding the plane for a year while you wait for a new one.

Where the Name Comes From

Martin Fowler took the metaphor from the strangler figs he saw during a vacation in the rain forests of Queensland, Australia, in 2001. These plants germinate in a nook of a tree, grow by drawing nutrients from the host until they root in the ground, and eventually become self-sustaining.

Fowler published the idea on his bliki a few years later under the name Strangler Application. He later renamed it Strangler Fig Application to highlight the botanical origin of the metaphor. The current version of the article dates from August 2024.

How It Works

The Azure Architecture Center guide describes it in four phases, with a façade (proxy) that decides where each request goes:

Phase 1                    Phase 2                    Phase 3-4
Client                     Client                     Client
   ↓                          ↓                          ↓
[Façade]                   [Façade]                   [New system]
 ↓90%   ↘10%                ↓30%   ↘70%
[Legacy] [New]             [Legacy] [New]             (legacy off,
                                                       façade removed)

Introduce the façade between clients, the legacy system, and the new one. At first almost everything goes to legacy.
Migrate incrementally: each reimplemented feature makes the façade send more traffic to the new system.
Decommission legacy once it has no remaining functions or dependencies.
Remove the façade and connect clients directly to the new system.

The façade is usually an API gateway, a reverse proxy, or an API layer. When the new and old systems need to call each other, an anti-corruption layer is recommended to translate between both models so the new design doesn’t inherit legacy quirks.

Why It Matters for Companies in Latin America

Many organizations in the region depend on systems in COBOL, VB6, Delphi, or PowerBuilder that can’t be stopped: they invoice, run payroll, or serve customers every day. Strangler Fig lets you:

Deliver value in the first months, not at the end of a multi-year project
Reduce risk: every step is small and reversible
Prioritize by return: migrate what hurts most or adds most value first
Spread the investment over time

When It Doesn’t Fit

According to the same Azure guide, the pattern may not be suitable when:

Requests to the legacy system can’t be intercepted
You can’t access the legacy source code to disable migrated features
The system is small and replacing it entirely is simple
You need to decommission the original system quickly

Common Mistakes

❌ Chasing full feature parity before going live → Replicating everything the old system does before launch leads back to “big bang”; many features are no longer used

❌ Turning the façade into a bottleneck → The façade must not become a single point of failure or degrade performance

❌ Forgetting the data → Decide from the start how both systems share or synchronize information

❌ Endless transition → Without a plan to switch off legacy, you end up maintaining two systems forever

Practical Example (illustrative)

A credit union runs a VB6 lending system and wants to move it to .NET + Angular:

An API gateway is installed as a façade in front of the current system’s functions
Loan status lookup (low risk, high usage) is reimplemented first as a .NET service
The new web portal uses that service; everything else stays in VB6
Then simulation, application, and disbursement are migrated, each with tests comparing results against the old system and automated deployments via CI/CD
When the last function leaves VB6, the system is switched off

Evaluating this approach for your system? At Nextsoft we support these projects together with specialized strategic partners: the partner carries out the migration and Nextsoft delivers new modules, integrations, frontend and QA. Explore the legacy system modernization service. Let’s talk about your case.

Microservices - A frequent target architecture when extracting functions from legacy
API - The façade and new services are exposed as APIs
Technical Debt - What this pattern lets you pay down in installments
Rehost, Replatform, Refactor - Cloud migration strategies that combine with this pattern
CI/CD - Essential for safely deploying many small increments

Additional Resources:

Martin Fowler - Strangler Fig Application - The original article behind the metaphor
Microsoft - Strangler Fig pattern - Phases, considerations, and when to use it
Microsoft - Anti-corruption Layer pattern - How to coexist with the legacy system
Cartwright, Horn & Lewis - Patterns of Legacy Displacement - Complementary patterns for replacing legacy systems

Pronunciation