Strangler Fig Pattern: Migrate Legacy Systems Incrementally (2026)

Q: What is the Strangler Fig pattern and where does the name come from?

The Strangler Fig pattern is an incremental system migration strategy where new services are built alongside a legacy system, traffic is gradually routed from old to new feature by feature, and the legacy system is decommissioned as each feature is replaced. The name comes from the strangler fig vine, which grows around an existing tree, gradually encompassing it until the original tree dies and only the fig remains. Applied to software: the new microservices are the fig, growing around the legacy monolith, and the monolith is the tree — shrinking with each migration cycle until it can be decommissioned entirely.

Q: What is the facade in the Strangler Fig pattern and how do you implement it?

The facade is a routing layer that sits in front of both the legacy system and the new services, directing each request to the appropriate destination. It is the only component that knows the current migration state — which features are migrated and which remain in legacy. Common implementations include an API gateway (Kong, AWS API Gateway), a reverse proxy (Nginx, Envoy), or an Istio virtual service in a service mesh. In the simplest case, path-based routing in Nginx routes migrated URL paths to new services and everything else to the legacy monolith. Feature flag systems can be added to the facade for canary routing or user-segment-based cut-overs without requiring a deployment change.

Q: How do you handle the database during a Strangler Fig migration?

The legacy monolith typically has a single large shared database, and extracting services requires taking ownership of the relevant data. Three approaches are used in practice. Shared database access (temporary): the new service reads and writes the legacy database tables directly during coexistence — simple to implement but creates tight coupling and should be temporary only. API-mediated access: the new service calls the legacy system's API for data it has not yet taken ownership of — cleaner boundaries, extra network hop. Change Data Capture synchronisation: a CDC tool (Debezium) streams row-level changes from the legacy database to the new service's database during coexistence, keeping both in sync. Once all writes for the migrated feature route to the new service, the CDC sync stops and the legacy tables are archived.

Q: What is the difference between the Strangler Fig pattern and a big-bang rewrite?

A big-bang rewrite freezes the legacy system, builds a complete replacement from scratch, and cuts over when done. It concentrates all risk into a single cut-over event, requires maintaining two systems in parallel during the entire rebuild (applying every feature change and bugfix to both), and fails frequently because the replacement rarely behaves exactly like the original under real production traffic. The Strangler Fig migrates one feature at a time. Each step is independently verifiable and independently reversible. Real production traffic validates each migration before the next begins. Risk is distributed across many small steps rather than concentrated into one large event. The legacy system remains authoritative for everything not yet migrated, so there is no "spec gap" during the migration.

Q: How do you validate that a new service behaves correctly before decommissioning the legacy implementation?

Three techniques are commonly combined. Shadow mode: during the Transform phase, mirror production requests to the new service without using its responses; compare outputs and fix discrepancies before routing real traffic. Canary routing: in the Coexist phase, route a small percentage of production traffic (1–5%) to the new service before full cut-over; monitor error rates, latency, and business metrics. Parallel run: serve production responses from the new service while also running the request through the legacy implementation in the background; compare results and log discrepancies. Define explicit rollback criteria (error rate threshold, latency threshold, business metric anomaly) before the Coexist phase begins, so rollback is an automated or immediately-executable response to a defined condition rather than a decision made under outage pressure.

Q: What order should features be migrated in?

Start with features that have the lowest risk and the clearest boundaries: read-heavy services with no financial implications, features with self-contained data that do not share tables with dozens of other features, and services that are already relatively isolated in the legacy codebase. This builds team confidence in the process and proves the facade infrastructure before tackling complex features. After the first successful extraction, migrate the features that are causing the most pain in the legacy system — the services most frequently deployed, most prone to cascading failures, or most blocking scaling. Save the most deeply-coupled, data-entangled features for last, once the team has established migration patterns and the legacy system has shrunk significantly.

Q: What happens to shared code (libraries, utilities) in the legacy monolith?

Shared utility code — logging, authentication, validation helpers — should be extracted into shared libraries or internal packages that both the legacy system and new services depend on. Do not copy-paste: divergent implementations of shared code create maintenance burden and subtle behavioural differences. Authentication and authorisation middleware should be extracted early, because every service needs it and inconsistent auth behaviour across legacy and new services creates security gaps. Domain logic (pricing calculations, business rules) should be owned by the service that owns the corresponding data — copying business logic to the new service and keeping it synchronised with the legacy version is a migration smell that indicates the data ownership boundary has not been resolved correctly.

Q: How does the Strangler Fig pattern relate to the microservices journey more broadly?

The Strangler Fig pattern is the standard answer to the question "how do we get from a legacy monolith to microservices without a risky rewrite?" It is not a microservices pattern in the sense that it describes how microservices should operate — it describes how to arrive at microservices from a monolithic starting point. Most real-world microservices architectures were not greenfield: they were legacy monoliths that were incrementally decomposed using the Strangler Fig approach. The pattern pairs with the API Gateway pattern (which provides the facade infrastructure), the Outbox pattern (which enables reliable event publishing from extracted services), and the Sidecar pattern (which handles cross-cutting concerns in the extracted services without requiring shared libraries).