What is the Strangler Fig Pattern?
The Strangler Fig Pattern (also called the Strangler Pattern) is an architectural migration strategy, not a technology or a framework. It describes how an organization can replace an old, monolithic system with a new architecture — function by function, domain by domain — while keeping the service continuously available.
The core idea is simple. Instead of rewriting the whole system from scratch and cutting over on a single day, a new implementation is built around the old application and gradually takes over responsibilities. The old and new systems run in parallel, hidden behind a shared external interface. From the end user's perspective nothing changes — they do not know that some requests are already handled by the new architecture while the rest still rely on legacy code. The process continues until all functionality has been migrated and the monolith can be safely switched off and deleted.
It is worth being clear about what the Strangler Fig is not. It is not a tool you install, nor a library. It is a design pattern — a set of principles and an order of operations that you implement using existing infrastructure components such as a reverse proxy, an API gateway, or a message broker.
Who is behind it?
The concept was introduced to software engineering by Martin Fowler in 2004. The inspiration came from a trip to the rainforests of Queensland, Australia, in 2001, where Fowler encountered strangler fig trees.
These plants have an unusual life cycle. A seed germinates high in the canopy of a host tree, and the young fig sends roots downward until they reach the soil, while growing branches upward toward the light. Over time it envelops the host completely. The original tree dies and decays, leaving behind a self-supporting, hollow fig shaped like its former host.
Fowler saw in this process an apt metaphor for modernizing legacy systems — rather than brutally cutting down the old tree, you can gradually wrap it in a new one until it becomes redundant. He originally used the name Strangler Application, but over time the word "strangler" took on a life of its own and acquired aggressive connotations. Fowler therefore officially updated the terminology to Strangler Fig Application, emphasizing the link to nature and the slow, evolutionary character of the process. Today the pattern is promoted in the official cloud guidance of both Microsoft Azure and Amazon Web Services.
How does it work?
The implementation cycle is most often described by three verbs used in the AWS documentation: Transform, Coexist, Eliminate.
Transform
Architects analyze the monolith and carve out a fragment with clear boundaries — for example the checkout process in an e-commerce store. Domain-Driven Design techniques are frequently used to identify these boundaries. The extracted component is rebuilt as a modern implementation, usually in a microservice architecture, preserving an interface consistent with client expectations.
Coexist
Both systems run side by side. A facade — a proxy or network gateway — is established to receive all incoming requests. Initially the facade merely forwards traffic to the monolith (a pass-through). Then logic is configured to route a fraction of traffic to the new implementation, while the old code stays on standby in case of problems. This layer delivers the pattern's most important benefit — if the new microservice fails, reverting to the previous version happens almost instantly (instant rollback).
Eliminate
Once the new function has proven stable in production, the old logic is cut off from requests and, crucially, physically deleted from the monolith's repository. Skipping this deletion is one of the most dangerous mistakes in the whole process.
The loop repeats iteratively for successive domains — user management, catalog, payments — until the monolith is fully replaced and can be shut down.
What are its key components?
The interception layer
The technical heart of the pattern decides where each request goes. It is known as the facade or routing layer. It is most often implemented as a reverse proxy?reverse proxy: an intermediary server that receives external requests and forwards them to the appropriate backend service (such as NGINX or HAProxy) or an API gateway (Amazon API Gateway, Azure API Management). Proxy servers offer very fast routing based on URL or headers, while managed cloud gateways add declarative routing, rate limiting, and centralized authentication.
This layer can split traffic in several ways:
- Segmentation by URI path — requests to
/api/v2/ordersgo to the new cluster, everything else falls back to legacy. - Feature flags and canary deployments — initially 5–10% of users are directed to the new architecture, and the team watches for errors before a full switch.
- Event interception — message brokers such as Apache Kafka or AWS EventBridge let the old and new systems communicate asynchronously over an event bus.
The data layer
The second and far harder component is the data layer. A monolith usually rests on a single large relational database, while microservices call for a database-per-service model. Data migration is done incrementally — from a dual-write to both databases, through a historical backfill, to the new database taking over as the system of record. More advanced deployments use Change Data Capture?Change Data Capture: a technique that captures every change in a source database and streams it onward in near-real time with tools such as Debezium and streaming through Kafka.
What can it be used for?
The main use of the pattern is migrating a monolith to microservices and moving on-premises?on-premises: IT infrastructure physically installed and managed at the organisation's own site, as opposed to cloud-hosted services systems to the cloud. The major cloud providers actively promote it. AWS treats Strangler Fig as a path toward serverless and container architectures — functions are exported to AWS Lambda or ECS?ECS: Amazon Elastic Container Service — AWS managed platform for running Docker containers without managing your own server cluster/EKS?EKS: Amazon Elastic Kubernetes Service — AWS managed service that runs Kubernetes clusters without requiring you to install or maintain the control plane clusters, with an Amazon API Gateway and a load balancer placed at the edge of the monolith. Microsoft Azure emphasizes the gradual extraction of an integrated database using Azure SQL or Cosmos DB, together with Azure API Management and Azure Kubernetes Service.
Dedicated tooling also exists. AWS Migration Hub Refactor Spaces is an environment designed almost exclusively to orchestrate the Strangler Fig pattern. Platforms such as vFunction automate the analysis of tangled code (especially in Java Enterprise) and detect optimal subdomain boundaries, reducing the risk of anti-patterns.
How does it differ from other approaches?
The natural point of reference is the big-bang rewrite — rewriting the entire system from scratch and switching to it on a single day. The difference comes down to how risk is distributed. Big-bang concentrates all risk on the cut-over day and delivers no value until the project is complete. Strangler Fig splits the migration into small, reversible steps and lets you reap early ROI?early ROI: return on investment realised before the full project is complete — each migrated fragment delivers production value while migration is still ongoing from the very first migrated fragments.
The pattern is rarely used alone, however. The Anti-Corruption Layer protects the clean domain model of the new microservice from the archaic data model of the monolith, translating between them. Branch by Abstraction solves a case that Strangler Fig does not cover — Strangler Fig works at the edge of the system, intercepting network requests, while Branch by Abstraction operates deep inside the code, where logic cannot be intercepted by a proxy. Teams often combine both. A further complement is the Parallel Run, in which both systems process the same request and the new system's output is validated against the old one before the switch.
Key limitations and challenges
The pattern is not free. Maintaining two systems behind a network proxy requires mature DevOps, CI/CD, and monitoring practices, and the transitional period generates double operating costs — new cloud infrastructure runs alongside old machines.
The hardest aspect remains data synchronization. As engineering practice aptly puts it, designing the routing is the easy part, while moving the data is where the migration collides with reality. Dual-write introduces eventual consistency and the risk of state drift between databases.
Deployments can also fall into specific anti-patterns:
- Skipping the Eliminate phase — leaving old code in place, or even adding new features to both code bases, which produces permanent dual maintenance instead of a migration.
- Migrating individual endpoints rather than whole business capabilities — if the new microservice still writes directly to legacy tables, the old system still "owns" the data and dictates the architecture.
- Overloading the facade with logic — the facade turns into a bottleneck and a single point of failure.
The pattern can also be uneconomical for small applications, where the overhead of gateways and synchronization exceeds the cost of a plain rewrite.
The Strangler Fig in the AI era
The pattern predates the current wave of generative artificial intelligence, yet it is precisely that wave that gives it a new dimension. AI affects the Strangler Fig on two fronts — it accelerates the migration itself, and it becomes yet another system that has to be wrapped this way.
AI as an accelerator of the Transform phase
The most labor-intensive stage of the pattern is usually Transform — manually rewriting the extracted fragment of the monolith. This is where agentic coding assistants come in. Amazon Q Developer can autonomously upgrade Java applications from version 8 to 17 or 21, and port .NET applications from Windows to Linux, reading and editing files on its own, generating code diffs, and running shell commands. Analysis tools such as vFunction use AI to detect domain boundaries in tangled Java Enterprise code — a decision that previously took an architect weeks. The result is that the phase which historically throttled migration speed shrinks from months to days.
A facade for AI traffic
The second shift concerns what flows through the interception layer. Increasingly the facade routes traffic not to microservices but to language models. A distinct category has even emerged — the AI gateway. Kong AI Gateway?Kong AI Gateway: an API gateway designed specifically for language model traffic — manages routing to multiple LLM providers, semantic response caching, token quotas, and cost monitoring lets you govern traffic to multiple model providers (multi-LLM) from a single point, switch between them on the fly to preserve availability, cache responses semantically (semantic caching?semantic caching: a response caching technique based on semantic similarity between queries — if a new question is close enough to a previous one, the stored response is returned without calling the model), and enforce token-usage quotas. This is exactly the same facade role as in the classic Strangler Fig, except that the system being strangled can be one model provider replaced by another without the client application ever knowing.
When the model itself is the strangler
The most interesting case is when the new implementation taking over from the monolith is not an ordinary microservice but a machine-learning model replacing rule-based logic — for example a rules-based fraud engine giving way to a predictive model. The Strangler Fig facade is a natural home for the Parallel Run pattern, known in an AI context as shadow mode — the model scores production requests alongside the old system, but its decisions initially have no effect. A new challenge appears, though. The old logic was deterministic?deterministic: a system or algorithm that always produces the same output for the same input — with no element of randomness, while a model is often probabilistic?probabilistic: a system or algorithm whose output may vary between calls even with identical input, because its operation incorporates an element of randomness or uncertainty, so the criterion "the new output matches the old" must be replaced with statistical thresholds and continuous quality evaluation, including techniques such as LLM-as-judge, where one model grades another's answers.
Why does it matter?
The pattern's significance is best seen through the cost of its absence. The big-bang approach can be catastrophic. In April 2018, TSB Bank attempted to migrate 5.2 million accounts to a new platform in one go, cutting 1.9 million people off from access and incurring losses of around £330 million plus a regulatory fine of nearly £48.65 million. In 2012, a bug in a single deployment script at Knight Capital reactivated dead legacy code and cost the firm $440 million in 45 minutes. Independent analyses indicate that big-bang modernization projects fail or fall short of expectations in 68–79% of cases.
In this context, the Strangler Fig stops being an academic curiosity and becomes a risk-management mechanism. For systems whose downtime directly hits financial liquidity and reputation — banking, exchanges, large-scale commerce — the ability to instantly roll back a faulty change at the facade level is a value hard to overstate. The pattern also lets teams keep developing the product in parallel with modernization, rather than freezing development for the duration of a rewrite. That is why, two decades after it was formulated, it remains one of the fundamental tools for modernizing enterprise-class systems.
The Strangler Fig is no magic recipe — it demands discipline, especially in consistently removing old code and transferring data ownership rather than just APIs. But in a world where a full rewrite is a high-stakes bet with a low chance of success, it offers something rare: a modernization path you can stop, reverse, and resume at any point.