The big-bang rewrite is the most consistently bad idea in software engineering. Companies that try to replace a working monolith with a brand-new microservices version, in parallel, almost always fail — they either ship the new system years late, or never finish, or finish and discover it does 60% of what the old one did.
The strangler-fig pattern is the alternative that actually works. Named after the vine that grows over a host tree, then eventually replaces it. Same idea: start with the monolith, extract one route at a time, and let the monolith shrink to nothing.
Step 1: The monolith
Where you start. All routes go to the monolith. One process, one database, one deploy. You’re not changing this yet — just acknowledging it.
Step 2: Put a reverse proxy in front
Add a proxy (nginx, Envoy, Cloudflare Workers, AWS ALB — whatever you’re comfortable with). Every request now goes through the proxy, which forwards 100% of traffic to the monolith. From the user’s perspective, nothing changed. From your perspective, you now have a control point.
This step alone is worth doing for a week of stability before the next move. Watch the metrics. Make sure the proxy isn’t adding latency. Don’t proceed until step 2 is rock-solid.
Step 3: Extract one route
Pick a route that’s self-contained — doesn’t touch 7 different domain entities, doesn’t require deep database joins with everything. Common first picks: billing webhooks, file upload, email sending, search.
Build a new service that implements that route. Deploy it. Configure the proxy: “requests to /api/billing/*go to the new service; everything else still to the monolith.”
Critical: the new service can call back into the monolith for data it doesn’t own yet. That’s fine. Decoupling is gradual.
Step 4: Repeat
Extract the next route. And the next. The monolith shrinks; the constellation of services grows. After 18-36 months, the monolith is small enough that you can either delete it or fold it into one final service.
At no point is there a “big migration day.” The system is always running. The team is always shipping new features alongside the migration. The business never has a six-month outage of feature development.
Pitfalls to avoid
- Extracting domain boundaries that aren’t real.A route isn’t a service boundary. Map your bounded contexts first. Don’t extract a route until you understand the data ownership.
- Shared databases across the boundary.The new service should eventually own its own database. Sharing the monolith’s database is fine for a transition period but becomes the new monolith if you let it persist.
- Distributed transactions. Resist them. Use eventual consistency + sagas. If you find yourself wanting 2-phase commit across services, the extraction boundary is wrong.
- Letting the proxy logic get complicated.Route-based forwarding is fine. Header-based feature flags are fine. Once the proxy is doing business logic, you’ve recreated a monolith in the proxy.
When to NOT extract
Not every monolith needs to be broken up. Strangler-fig is the right pattern when:
- The team has grown past the point of one shared codebase being productive
- There are genuine scaling differences across surfaces
- You’re trying to introduce technology heterogeneity (e.g. ML in Python alongside a Rails monolith)
If none of these apply, leave the monolith alone. The world’s most successful monoliths (Stack Overflow, Basecamp) ran on single deployments for over a decade by choice.
How we approach this
Most of our Cloud & DevOps engagements involving legacy migration follow this exact playbook. We start with the proxy. We extract one route. We measure. We extract the next. Six to twelve months in, the legacy monolith is a thin shell. Two years in, it’s gone. The business never noticed a migration.
Takeaways
- The big-bang rewrite is the most consistently bad idea in software. Don’t.
- Strangler-fig: proxy in front, extract one route at a time, shrink the monolith.
- Get the proxy stable before extracting anything.
- Don’t extract route by route — extract by bounded context.
- Some monoliths shouldn’t be extracted. Honest decision.
