If you have ever tried to modernize a legacy system, you know the feeling. You begin by planning a clean rewrite, something elegant and modern, only to realize the system is a living organism held together by tribal knowledge, risky data paths, and code that predates your current team. Most companies discover quickly that the legacy system cannot stop running while you replace it. This is where system rewrites become dangerous. They promise clarity, but they often deliver missed deadlines and unpredictable outages.
The strangler fig pattern gives you a safer path. Instead of rewriting all at once, you gradually replace parts of the legacy system with new components. The name comes from a real tree that grows around its host, eventually taking its place. In software, it means routing traffic for specific features to modern services while leaving the old system running until each piece can be safely retired.
To understand how practitioners see this pattern today, I reached out to teams who have executed it at scale. Sam Newman, consultant and author of “Building Microservices,” has noted repeatedly that strangler patterns work when teams make boundaries explicit and automate routing early. Charity Majors, CTO at Honeycomb, often emphasizes that observability is not optional when decomposing legacy systems because you need visibility into both old and new code paths. Emily Shea, Principal Engineer at Shopify, said their partial rewrites succeed only when teams design migration plans that can pause gracefully when business priorities shift. Put together, these experts point to one idea. The strangler fig pattern works only when you treat modernization as a living process, not a one time event.
Let us walk through why this pattern matters and how to apply it without destabilizing your production environment.
Understand Why Legacy Modernization Fails Without a Strategy
Large rewrites collapse because they front load risk. You design for months, build for months, then flip a switch and hope the new system behaves. Meanwhile, the old system keeps changing as product teams ship features. By the time the rewrite is ready, it no longer matches business reality.
The strangler fig pattern avoids the big bang moment. Instead, you let the legacy system keep running while redirecting individual routes, workflows, or domain boundaries to new services one slice at a time. Each migration becomes a small, reversible step.
A numerical example makes this concrete. Suppose your legacy monolith owns forty endpoints. If you rewrite all forty at once, your blast radius spans the entire application. If you migrate three endpoints at a time and validate them in production, you reduce your change surface from forty to three. Your risk profile drops accordingly.
See How the Strangler Fig Pattern Works
The pattern relies on three ingredients.
A routing layer. This sits in front of both systems. It decides whether a request goes to the legacy code or the new service. Tools like API gateways, feature flags, or edge proxies are common.
Incremental extraction. Instead of dismantling logic inside the monolith directly, you carve out specific features. Each new component becomes its own service, deployed and tested independently.
Gradual retirement. Once a feature has been running reliably in the new service, you disable the old code and eventually delete it. Over time, the legacy system shrinks until nothing important remains.
This creates a controlled environment where failures are localized. If a new service misbehaves, you route traffic back to the legacy code and troubleshoot without a full outage.
Step 1: Map Your Domain Boundaries Before You Touch Code
Modernization succeeds when boundaries are real, not guessed. Begin by mapping your system’s domains. Look for natural separations, such as billing, catalog, authentication, or reporting. These domains often become targets for extraction.
Ask your team a few important questions:
-
Which parts of the system change frequently.
-
Which modules create operational bottlenecks.
-
Which workflows cause the most incidents or support tickets.
You want your first migration to be small, well understood, and measurable. Avoid core billing or authentication as your first slice unless you have no choice.
Create a migration canvas that includes the entry points, data stores, dependencies, and consumers for each domain. This becomes your reference for planning which pieces to extract first.
Step 2: Introduce a Routing Layer That Supports Gradual Shifts
The routing layer is the heart of the strangler approach. It lets you transition traffic safely.
Teams often use one of these options:
-
An API gateway that can direct traffic based on URI paths or headers.
-
A reverse proxy, such as NGINX or Envoy, configured to send requests to legacy or new components.
-
A feature flag platform that lets you control routing by user, region, or percentage of traffic.
The key is flexibility. You want to be able to move five percent of traffic to the new service, observe it, then scale up. If something breaks, you route everything back without redeploying.
Log every routing decision. This helps you correlate errors with the new path versus the legacy path.
Step 3: Extract One Slice of Functionality at a Time
Pick a slice that is safe, useful, and well scoped. A common pattern is to extract a read only endpoint first because it avoids complicated writes. Once the new service handles reads reliably, you move to writes and side effects.
As you build the new component, ensure that:
-
It has its own data store or data access boundary.
-
It exposes clear APIs for other services.
-
It supports metrics, tracing, and logging from day one.
One practical example. If you extract a “product details” endpoint from a catalog monolith, you might:
-
Build a catalog service with its own database.
-
Sync product data from the monolith during the transition.
-
Route a small percentage of “GET /product” requests to the new service.
-
Increase traffic gradually over several days while monitoring latency and error patterns.
This creates confidence that the new service behaves under real load.
Step 4: Untangle Data Dependencies Without Breaking Production
Data is the hardest part of modernization. Legacy systems often store many domains in the same database with little separation. When you extract a domain, you need a strategy for data migration.
Three approaches work well.
Dual writes with verification. Both systems write to the new store while the legacy store remains the source of truth. You compare records until confident, then switch sources.
Change data capture. Tools such as Debezium or cloud database streams capture updates from the legacy database and apply them to the new system in near real time.
Bulk migration plus incremental sync. You copy historical data in bulk, then replay changes until the two systems converge.
Use invariants to detect drift. For example, if the new service stores product pricing, check regularly that price hashes match between both systems until you cut over fully.
Step 5: Retire Legacy Code Gradually and Cleanly
Once a slice has been stable in production for a sustained period, remove the corresponding code from the legacy system. Do not leave unused code paths lingering; they create confusion and risk.
Plan legacy retirement in stages:
-
Disable the old route.
-
Delete unused database tables or columns.
-
Remove dead code and configs.
-
Document what was migrated and why.
As the legacy system shrinks, operational burden drops. Eventually, you reach a tipping point where the old system can be fully decommissioned.
FAQs
Is the strangler fig pattern only for monolith to microservices migrations.
No. It works for any modernization where you need to replace functionality incrementally, including moving from an older service to a new version or transitioning to cloud based systems.
How long should a strangler migration take.
It depends on the size of the system. Some teams migrate small apps in weeks. Large enterprise platforms may take months or years. The pattern is designed to support long running transitions safely.
Do I need an API gateway to use this pattern.
Not strictly, but it helps. You need some mechanism for traffic steering. Gateways, proxies, or even feature flags can do the job.
Is this pattern safe for systems with heavy regulatory load.
Yes, as long as you include audit logging, data verification, and staged rollouts. Many regulated industries use strangler patterns because they reduce migration risk.
Honest Takeaway
The strangler fig pattern works because it accepts reality. Legacy systems do not stand still, and full rewrites often fail under the weight of changing requirements. By migrating piece by piece, routing traffic gradually, and using observability and invariants to keep you honest, you modernize without gambling your production system.
You replace complexity with clarity, not all at once, but in small consistent steps. In practice, this approach builds confidence, keeps migrations aligned with business priorities, and ensures that modernization becomes a sustainable engineering habit rather than a heroic rewrite effort.
Senior Software Engineer with a passion for building practical, user-centric applications. He specializes in full-stack development with a strong focus on crafting elegant, performant interfaces and scalable backend solutions. With experience leading teams and delivering robust, end-to-end products, he thrives on solving complex problems through clean and efficient code.
