The Strangler Fig Application is Martin Fowler's pattern for replacing a legacy system incrementally instead of through a big-bang rewrite. A routing facade intercepts requests and sends each one to either the old system or its new replacement, while functionality and data move across piece by piece. Named after the vine that envelops its host tree, the new system grows around the old one until the legacy host can be decommissioned.

Strangler Fig

Details
Full Name

Strangler Fig Application

Also known as

Strangler Fig pattern, Strangler Application (original 2004 title, later renamed by Fowler)

Core Concepts:

Routing facade

A proxy intercepts requests bound for the legacy system and routes each one to either the old system or its new replacement; clients keep the same interface and stay unaware that a migration is in progress

Incremental replacement

Functionality is migrated piece by piece rather than in a single big-bang rewrite; the new system grows around the old one until the legacy host can be decommissioned

Botanical metaphor

Named after the strangler fig vine that germinates in a host tree, sends roots to the ground, and gradually envelops the host until it stands self-supporting in its place — the new system "strangles" the legacy

Event interception

Intercepting the events or calls that flow into the legacy system so new behaviour can be layered in and routed away from the old code

Asset capture

Progressively taking ownership of the data and capabilities ("assets") that the legacy system holds, moving each into the new system as it is replaced

Transitional architecture

The facade and any anti-corruption layers are scaffolding meant to be torn down once migration completes; both systems coexist and may share data stores during the transition

Avoids big-bang rewrite

Reduces risk by keeping the legacy system live and rolling back-able throughout, instead of betting on a single cutover

Key Proponent

Martin Fowler (StranglerFigApplication, 2004)

When to Use:

  • Modernizing a large, complex, or legacy monolith where a full rewrite would be too risky

  • Decomposing a monolith into microservices by extracting one capability or domain at a time

  • When the original system can keep running for an extended period during migration

  • When requests to the back-end can be intercepted and the legacy source can be modified to redirect calls

Criticism:

  • Microsoft, Azure Architecture Center — Strangler Fig pattern (2026) — warns that the facade must keep pace with the migration and must not become a single point of failure or performance bottleneck, and that both systems sharing data stores requires careful concurrent access; recommends an Anti-corruption Layer for cross-system calls

  • Amazon Web Services, Decomposing monoliths into microservices — Strangler fig pattern — notes the legacy and modernized systems "live together for a period of time," which imposes dual-maintenance cost; the pattern is unsuitable when requests cannot be intercepted, the legacy source is inaccessible, or the system must be fully decommissioned quickly

Current Status:

  • Widely adopted in cloud-modernization guidance beyond Fowler’s original essay: documented as a first-class pattern by both the Microsoft Azure Architecture Center and AWS Prescriptive Guidance, typically framed as monolith-to-microservices decomposition

  • Naming drift: Fowler originally titled it "Strangler Application" and later renamed it "Strangler Fig Application" to restore the botanical metaphor (Original Strangler Fig Application); training-data priors may still surface the older "Strangler" / "Strangler Application" label