Strangler Fig Pattern
Incrementally migrate legacy systems with minimal risk
The Problem
IT migration projects are no longer the exception, they are part of everyday business. Legacy systems that have been in operation for years eventually reach a point where custom features are expensive to implement and workarounds have become the norm. The original subject matter experts who understood the processes and features are often no longer available. What remains is a system that supports business-critical processes but has become technically outdated.
Here's the key challenge: customers and employees are actively using this system. A migration must succeed without jeopardizing ongoing operations — no major downtime, no data loss, no nasty surprises.
This is exactly where the Strangler Fig Pattern comes in.
What Is the Strangler Fig Pattern?
The pattern was first described by Martin Fowler in 2004, inspired by strangler figs he observed in an Australian rainforest. The name comes from the strangler fig (Ficus) — a plant that wraps itself around an existing tree, gradually takes over its function, and eventually replaces it entirely.
In software migration terms: instead of replacing a legacy system all at once, individual processes and features are migrated to a new system incrementally. The old system continues to run in parallel until it has been fully replaced.
The core idea can be broken down into three principles:
Incremental Migration — One process at a time is migrated, not everything at once.
Facade as Traffic Router — An intermediary layer (facade) routes requests to either the old or the new system.
Rollback-Ready at All Times — If a migrated process does not work as expected, traffic can be immediately routed back to the legacy system via the facade.
When Does the Strangler Fig Pattern Make Sense?
Not every migration calls for this pattern. For small, straightforward systems, a full replacement may be more efficient. The Strangler Fig Pattern shines with systems that are large and complex enough to justify an incremental migration.
Decision Guide: Strangler Fig vs. Full Replacement
| Criterion | Full Replacement | Strangler Fig Pattern |
|---|---|---|
| System Size | Small (few processes) | Large (many processes/modules) |
| Downtime Tolerance | High | Low |
| Dependency Complexity | Low | High |
| Data Migration | Simple, one-time feasible | Complex, incremental required |
| Rollback Requirement | Acceptable without rollback | Rollback must be possible at all times |
| Project Duration | Short (weeks) | Long (months to years) |
Rule of thumb: Once a system covers more than a handful of tightly coupled business processes, has active users, and downtime carries real business impact, the Strangler Fig Pattern is the safer choice.
Identifying and Prioritizing Processes
Before migration begins, all processes and features of the legacy system must be inventoried, categorized, and prioritized. Two dimensions are key:
Risk vs. Business Value
| High Business Value | Low Business Value | |
|---|---|---|
| High Risk | Plan carefully, migrate late — this is where most dependencies and the most at stake | Challenge critically — is the migration worth it, or can the process be retired? |
| Low Risk | Migrate first — quick business value at low risk | Migrate last, or decommission entirely if the process is no longer needed |
The ideal order: Start with processes that have low risk and high business value. This delivers visible results quickly and builds trust within the team and among stakeholders.
At the same time, the analysis provides an opportunity to identify processes that are no longer needed at all. Legacy systems accumulate features over the years that nobody uses anymore — the migration is the right moment to deliberately retire them.
The Facade: Heart of the Migration
The facade is the central control layer in the Strangler Fig Pattern. It sits between the clients and the backend systems and decides where each request is routed.
How the Facade Works
Before migration: The facade routes all traffic to the legacy system.
During migration: Processes are switched over one by one. Migrated processes are routed to the new system; non-migrated ones remain on the legacy system.
After migration: The legacy system has been fully replaced. The facade can be removed — or it can remain as an API management layer, for example to maintain backward compatibility for older clients.
Benefits of the Facade
Rollback at any time: If a migrated process does not work as expected, traffic is immediately routed back to the legacy system.
A/B testing: Old and new processes can run in parallel to compare behavior and performance.
Parallel operation: Ideally, customers notice nothing about the migration — the facade abstracts the complexity away.
Common Migration Scenarios
The Strangler Fig Pattern is not tied to any specific technology stack. It can be applied wherever a legacy system needs to be replaced incrementally. Here are the most common scenarios:
Migrating a monolith to microservices — A monolithic system is incrementally decomposed into individual microservices. Each service takes over a well-defined process. The facade controls which requests still go to the monolith and which are already served by the new service.
Replacing an integration platform — Integration platforms that have evolved over time often connect dozens of systems to one another. A full replacement is especially risky here because each integration brings its own data formats, protocols, and error handling. With the Strangler Fig Pattern, integrations are moved to the new platform one at a time. Example: migrating BizTalk integrations to Azure services — such as Logic Apps, Azure Functions, Service Bus, and API Management.
Migrating from on-premises to the cloud — On-premises infrastructure is moved to the cloud step by step. Individual workloads are migrated one after another while the facade routes traffic between on-premises and cloud. This lets you take advantage of the cloud early without switching over the entire operation at once.
Modernizing a legacy frontend — Older desktop applications or outdated web UIs are incrementally replaced with modern frontends. Individual areas or modules of the interface are rebuilt one by one while the rest of the application continues to run unchanged. The facade routes users to the old or new interface depending on the module. Prerequisite: business logic must not be tightly embedded in the UI. If it is, it needs to be extracted into dedicated services first.
Dependencies and Data: The Underestimated Challenge
The biggest challenge in the Strangler Fig Pattern is rarely the migration of the logic itself — it is data availability and data migration.
What Needs to Be Considered
Data access: During parallel operation, both the old and the new system must be able to access consistent data. Who writes where? Which system is the source of truth?
Data migration: Data must be migrated incrementally, not all at once. This requires a clear strategy for synchronization and conflict resolution.
Tracking dependencies: Migrated processes may depend on data that still resides in the legacy system, and vice versa. These dependencies must be documented and actively managed.
Carefully and incrementally tracking which processes and features have been migrated is essential for project success.
Creating Visibility: Monitoring as a Bonus
Legacy systems often suffer from a lack of visibility — little to no monitoring, few metrics, and barely any alerting. The migration is the ideal opportunity to address this gap.
Every migrated process can be equipped with monitoring, logging, and alerting from the start. This not only provides operational confidence for the new components but also improves overall transparency across the system — a benefit that extends well beyond the migration project itself.
The Biggest Risk: Doing Too Much at Once
The Strangler Fig Pattern works because it uses divide and conquer to keep complexity manageable. The biggest risk is violating this principle.
It is tempting to migrate multiple processes at the same time because the team believes it can handle the complexity. But that is exactly what leads to the problems the pattern is designed to avoid:
Dependencies get overlooked
Rollbacks become complex or impossible
Errors are harder to isolate
The discipline of migrating one process at a time is the single most important factor for success. The goal is to minimize risk — not to finish fast.
The Strangler Fig Pattern also takes the time pressure off the team. Unexpected complexity or knowledge gaps hit every migration project. The project plan can then be adjusted without jeopardizing the entire effort. Ownership is gradually handed over from the old system to the new one — controlled and traceable.
Summary
The Strangler Fig Pattern is not a tool for every migration, but it is the right one for the hard ones: large, legacy systems that have evolved over time with active users, patchy documentation, and high business criticality.
The core principles:
Migrate incrementally — one process at a time
Use a facade — route traffic, enable rollback, ensure parallel operation
Minimize risk — don't maximize speed
Treat data as its own challenge — actively plan for availability, synchronization, and migration
Create visibility — build in monitoring from the start
The end result is a fully replaced legacy system — migrated incrementally, without unnecessary risk, and with continuous business value delivered along the way.
