On this page · 3 sections
Rewriting a 10-year-old monolith from scratch is a recipe for disaster. It takes too long, and you lose business features during the rewrite. The "Strangler Fig" pattern is the only safe way to migrate critical systems — and it's the backbone of our Multi-Cloud Consulting & Migration practice.
The 7-Step Strategy
- Identify Boundaries: Use Domain-Driven Design (DDD) to identify bounded contexts. The "User Profile" or "Notification" modules are usually good candidates to start.
- Setup the Cloud Foundation: Build your Landing Zone in AWS/Azure with proper networking and security — ideally with SOC 2-ready controls baked in from day one, not retrofitted later. See our SOC 2 roadmap for what that involves.
- Create the Anti-Corruption Layer: Build an API Gateway that routes traffic. This allows you to switch traffic between the old monolith and the new microservice transparently.
- Build the First Microservice: Extract the simplest module. Build it as a containerized service — see our Kubernetes best practices guide for how we architect the target platform.
- Shadow Traffic: Route real production traffic to the new service in "shadow mode" (fire and forget) to test performance without impacting users.
- Cutover: Once confident, switch the API Gateway to route live traffic to the new service.
- Decommission: Remove the old code from the monolith. Repeat.
Is it slow? Yes. Is it safe? Absolutely. We preserved 99.9% uptime for a regional retailer during a peak-season migration using this exact method — read the full story in our Black Friday zero-downtime case study.
Don't Forget Cost Governance From Day One
A common mistake during decomposition: nobody tags the new microservices correctly, and cost visibility gets worse before it gets better. We build tagging enforcement into the Landing Zone setup itself — see our cost allocation guide — so the new architecture is accountable from the first deployed service, not retrofitted after the migration is "done."
Frequently asked questions
How long does a strangler fig migration typically take?
It depends entirely on monolith size and organizational bandwidth, but most enterprise-scale migrations we run take 6-18 months to fully decompose the highest-priority modules, with the monolith continuing to shrink incrementally after that as lower-priority modules get extracted over time.
Do we need to fully decompose the monolith to see benefits?
No. Each extracted microservice delivers value independently — faster deploys for that module, independent scaling, reduced blast radius for changes. You don't need to finish the entire migration to start seeing ROI on the modules you've already extracted.
What is the biggest risk in a strangler fig migration?
Data consistency between the monolith and the new microservice during the transition period, especially for modules that share a database. This is why the Anti-Corruption Layer and careful boundary selection (starting with modules that have the fewest cross-cutting data dependencies) matter so much.
