Every CTO eventually faces "The Beast". It’s a 10-year-old PHP/Java monolith. It powers the entire business. Nobody knows exactly how it works, but everyone is afraid to touch it. Deployments take 40 minutes and usually break something.
The instinct is to say: "Let's rewrite it from scratch!"
Do not do this. "The Big Bang Rewrite" is the single biggest cause of failed IT projects. You will spend 2 years building the "new system" while the "old system" keeps evolving. You will never catch up.
Enter the Strangler Fig
Named by Martin Fowler, the Strangler Fig Pattern is a metaphor derived from a type of fig tree that grows around a host tree, eventually replacing it entirely.
In software, this means we build new functionality around the edges of the monolith, gradually intercepting calls until the old system can be safely turned off.
The 3-Step Migration Strategy
Step 1: Insert the Proxy (The Seam)
Before you write a single line of new code, you put a HTTP Proxy (Nginx, HAProxy, or Cloudflare) in front of your monolith.
- Initially, it routes 100% of traffic to the Monolith.
- The user sees no difference.
- This is your "control valve".
Step 2: Extract a Vertical Slice
Pick one isolated domain. Let's say, "Product Reviews". It’s low risk. Instead of building it in the monolith, you build a shiny new microservice (Node.js/Go) just for reviews.
Step 3: Route and Divert
Now, you configure your Proxy:
GET /products/*-> Goes to Monolith.GET /cart-> Goes to Monolith.GET /reviews/*-> Goes to New Microservice.
You have just migrated 5% of your app without stopping the business. If the new service bugs out, you switch the route back to the monolith in 1 second.
Why it works
The business sees progress from day one - new code ships while the old system keeps running. If the reviews service has a bug, you switch the proxy back in seconds and the monolith handles it again. No outage, no war room, no all-hands email.
There is also a less obvious benefit: developers stop dreading Mondays. Nobody likes working in a 10-year-old codebase. But when they can also build greenfield code that ships to production, the legacy work becomes bearable - because it is visibly temporary.
The End Game
Over 12-24 months, you repeat this process. Eventually, the monolith is doing nothing but authentication or maybe one obscure legacy calculation.
The "Beast" hasn't been killed in a dramatic battle. It has been starved of traffic, slowly and safely, until it simply withered away.
Facing a legacy system that nobody wants to touch? We have migrated monoliths using the Strangler Fig pattern without downtime. Talk to us.
Frequently Asked Questions
What is the Strangler Fig pattern in software development?
The Strangler Fig pattern is a migration strategy where new functionality is built around the edges of a legacy system, gradually intercepting traffic until the old system can be shut down safely. Named by Martin Fowler after a fig tree that grows around a host tree and eventually replaces it, the pattern avoids the all-or-nothing risk of a big-bang rewrite. A proxy routes requests either to the legacy system or to new services, and the split shifts incrementally over months.
Why do big-bang rewrites fail?
Big-bang rewrites fail because the legacy system keeps evolving while the rewrite is in progress. Typically: months 1-3 produce clean new code; month 6 requires a new feature to be added to the old system because the rewrite is not ready; month 12 finds the rewrite "90% done" but chasing a moving target. The business cannot pause for the engineering team to catch up, so the rewrite is either abandoned or launched with major gaps. The Strangler Fig pattern avoids this by shipping to production incrementally from day one.
How long does a Strangler Fig migration take?
A typical monolith migration using the Strangler Fig pattern takes 12-24 months, depending on the size of the codebase and team capacity. Individual domain extractions - one isolated feature migrated to a new service - can ship within weeks. The timeline is spread across many small, reversible steps rather than a single high-risk cutover, which means each increment can be rolled back in seconds by reconfiguring the proxy.
What is a proxy in the Strangler Fig pattern?
The proxy is an HTTP routing layer - Nginx, HAProxy, Caddy, or Cloudflare - placed in front of the legacy system before any migration begins. Initially it routes 100% of traffic to the monolith. As new services are built, the proxy is reconfigured to route specific paths to them. If a new service has a bug, the proxy switches that path back to the monolith in seconds. The proxy is the "control valve" that makes the migration reversible at any stage.
Which parts of a system should be migrated first using the Strangler Fig pattern?
Start with isolated, low-risk domains - features with well-defined boundaries and limited connections to the rest of the system. Product reviews, user notifications, or a reporting module are common first candidates. Avoid starting with authentication, payment processing, or the order core - these have the most dependencies and the highest cost of failure. Once the migration infrastructure is proven on a low-risk service, the team has the confidence and tooling to tackle higher-stakes domains.