Migrate an enterprise monolith to microservices incrementally, never in a big-bang rewrite: use the strangler fig pattern to reroute one bounded context at a time, decompose the shared database per service, and restructure teams around services (Conway's Law). Expect 18–36 months and 15–25% of build cost per year for a large enterprise system.
How do you migrate an enterprise monolith to microservices?
Migrating an enterprise monolith to microservices is not primarily a coding exercise. Most of the work is organisational, and the rest is about data and operations. Think of it as the kind of enterprise software engineering programme that runs 18–36 months on a large system, not a refactor you wrap up in a quarter. Here is what you actually sign up for:
- Service extraction: you find the bounded contexts and pull them out one at a time with the strangler fig pattern
- Data decomposition: you break the shared monolithic database into service-owned databases. This is the hardest technical problem in any migration, and the one teams most often underestimate.
- Org alignment: you restructure teams around services (Conway's Law). Skip it and your code quietly drifts back to the shape of your org chart.
- Operational maturity: distributed tracing, a service mesh, independent CI/CD pipelines, on-call runbooks. Treat these as prerequisites, not afterthoughts.
- Cost: usually 15–25% of the original system's build cost for every year of migration on a large enterprise monolith
When to migrate (and when not to)
The single most important architectural question is not how to migrate, but whether to. Plenty of enterprise monoliths should stay as they are, at least for now, and often forever in part.
Strong signals that migration is justified
- Deployment coupling blocks velocity: teams wait on each other to release because everything ships as one artefact. One team's bug stalls five other teams' features.
- Scaling is all-or-nothing: a spike in one subsystem, say payment processing or the recommendation engine, forces the whole application to scale and burns infrastructure budget you did not need to spend.
- Regulatory isolation is required: GDPR data residency, PCI-DSS cardholder data isolation, or SOC 2 scope reduction all demand that certain data flows sit physically apart.
- Technology lock-in blocks capability: a critical new feature needs a runtime or language the monolith's stack cannot host, and re-platforming the whole application would be wildly out of proportion.
Strong signals migration should wait
- Your team has fewer than 30 engineers. At that size the coordination overhead of microservices tends to outweigh the deployment gains.
- You lack mature CI/CD pipelines, automated testing above 60% coverage, or centralised observability. Push ahead anyway and you build a distributed mess, not a microservices platform.
- No one owns bounded context mapping. Without a clear domain model you will cut the wrong boundaries and then spend years re-merging what you split by mistake.
- The monolith works and the business pain is modest. If your current delivery pace is acceptable, incremental legacy modernisation often returns more value per dollar than a full decomposition.
The distributed spaghetti trap
The most common failure mode in enterprise microservices migrations is the distributed monolith. You split the system into separate deployable units, yet it keeps every bit of coupling the original monolith had. On top of that, you inherit all the operational complexity of distributed systems. Worst of both worlds.
Symptoms of a distributed monolith include:
- Services share one database or schema, so changing a single table means coordinating releases across five teams
- Synchronous REST chains span 4–8 services per user request, and a timeout in service D cascades all the way back to service A
- A single shared library holds the domain model, business logic or configuration, which forces every service to release together whenever it changes
- Services deploy together on one release schedule, which defeats the whole point of independent deployment
The strangler fig pattern: incremental extraction
Martin Fowler's strangler fig pattern takes its name from the tropical vine that grows around a host tree and slowly replaces it. It is the industry-standard approach for zero-downtime migration of large production systems. The key insight is simple: you never rewrite the whole system at once. Instead you redirect specific request paths to new services, one path at a time.
Three elements make the mechanics work:
- Facade: an API gateway, reverse proxy (Nginx, Envoy) or BFF layer sits in front of both the monolith and the emerging services. It routes each request by path, headers or feature flags.
- Extract: you lift one bounded context into a standalone service with its own codebase, deployment pipeline and, eventually, its own database. The monolith's code for that context stays in place, but the facade reroutes the traffic.
- Verify and strangle: once the new service handles 100% of that context's traffic without regression, you delete the matching monolith code. The "strangling" is done for that context.
A few practical rules for the extraction sequence:
- Start with read-heavy, low-write services such as reporting, catalogue browsing or notification preferences. They carry fewer transactional dependencies, so they are safer to pull out first.
- Extract leaf contexts first — the services that do not call other internal services. Working inward toward the core keeps the blast radius of your early extractions small.
- Do not extract the payment or auth context first. These are high-criticality, high-coupling domains. Save them for later, once your team has earned confidence on simpler contexts.
- Keep the facade thin. The moment business logic creeps into the router, you have built a new monolith.
Decomposing the shared database
The strangler fig pattern gets the most airtime, but data decomposition is what actually breaks people in practice. Most enterprise monoliths lean on one relational database: hundreds of tables, foreign keys that reach across domain boundaries, and stored procedures with business logic baked right in.
The decomposition proceeds in stages:
- Identify ownership: assign a single owning service to every table and column. This is a domain modelling exercise, not a technical one. Run event storming sessions with business stakeholders to surface who really owns what.
- Abstract access: before you split databases physically, route reads and writes through the new service's API. Other services stop querying the shared table directly and call the owning service instead. That step alone exposes coupling you did not know you had.
- Dual-write transition: during the cutover window, write to the monolith's shared table and the new service's private schema at the same time. Check that the two stay consistent before you trust the new schema as canonical.
- Migrate and cut over: once dual-write is stable and reads flow through the new service, promote the private schema to canonical and drop the dual-write. The shared table goes read-only first, then disappears.
| Coupling type | Recommended approach | Risk level |
|---|---|---|
| Simple table ownership (no cross-domain FKs) | Direct extraction with dual-write window | Low |
| Cross-domain foreign keys | Replace FKs with domain events; accept eventual consistency | Medium |
| Shared joins across domain boundaries | Introduce read models (CQRS) per consuming service | Medium–High |
| Stored procedures with cross-domain logic | Extract business logic to application layer first, then decompose | High |
| Distributed transactions (saga required) | Design saga choreography with compensating events | High |
Org structure and Conway's Law
Conway's Law says organisations design systems that mirror their own communication structure. Here is what that means for a migration. Extract microservices without changing how your teams are organised, and the services slowly drift back toward the shape of your org chart. You end up rebuilding the monolith in distributed form.
Effective migration needs the inverse Conway manoeuvre: you deliberately reshape teams to match the service boundaries you want, so that team ownership, communication patterns and service ownership line up.
In practice, that means:
- Each service has one owning team, not a "platform team" that owns everything
- Teams are sized to own 1–3 services end-to-end, from development through deployment to on-call
- Communication between services becomes a formal API contract owned by the producing team, not an informal database join
- Platform teams own the infrastructure primitives (service mesh, CI templates, observability) but stay out of domain services
This is where enterprise system integration strategy earns its keep: from now on the contracts between services, not the database schema, are your long-term integration surface.
Cost and timeline benchmarks
Cost benchmarks for enterprise monolith migrations swing widely with system size and coupling. Still, the ranges below line up with both industry data and what we have seen across our own engagements:
| Monolith size | Indicative migration cost | Timeline to first independent service | Full decomposition timeline |
|---|---|---|---|
| Mid-size (5–15 engineers, 200k–500k LoC) | $200k–$500k | 3–5 months | 12–18 months |
| Large (15–50 engineers, 500k–2M LoC) | $500k–$2M | 4–8 months | 18–30 months |
| Very large (50+ engineers, 2M+ LoC) | $2M–$8M+ | 6–12 months | 24–48 months |
These figures assume you staff the migration partly with your existing team, who bring the domain knowledge, and partly with an external specialist partner who brings the architectural patterns and tooling. And "full decomposition" is rarely the real goal. Most enterprises decompose only the high-value bounded contexts and leave stable, low-change subsystems in the monolith indefinitely.
Infrastructure costs climb noticeably during the transition too. You run the monolith and the new services in parallel, and you pay for fresh tooling around service mesh, distributed tracing and secret management. Together that usually adds 30–50% to operational infrastructure spend until the migration settles.
Observability and rollback strategy
You cannot safely run a distributed system you cannot see into. Before you extract the first service, get these in place:
- Distributed tracing: OpenTelemetry with a backend (Jaeger, Tempo, Datadog APM) so you can follow a single user request across service boundaries. This one is non-negotiable.
- Centralised log aggregation: every service forwards structured JSON logs to one queryable store, whether that is Loki, Elasticsearch or CloudWatch Logs.
- Service-level SLIs/SLOs: set error rate, p95 latency and availability targets for each service before it takes production traffic. Alerts fire on SLO burn rate, not raw metrics.
- Feature flags at the facade: keep the ability to swing traffic back to the monolith instantly for any extracted context. The strangler fig pattern only holds up if you can reverse it fast.
Spell out the rollback strategy for each extraction phase. For every service you extract, write down:
- The exact facade routing rule to revert, ideally a one-line change in the API gateway config
- The dual-write status: if you have written data to both schemas, which one is canonical
- The data staleness window you can tolerate if the new service's database has drifted
- The on-call engineer who owns the rollback call, plus the time threshold that triggers an automatic rollback
Phased migration roadmap
A four-phase roadmap keeps the risk down and makes sure each phase delivers measurable value before the next one starts.
- Phase 1 — Foundation (months 1–3): Extract nothing yet. Put the prerequisites in first: centralised observability (tracing, logging, alerting), independent CI/CD pipeline templates, a container platform (Kubernetes or ECS), a domain event catalogue, and boundary mapping workshops with business and engineering stakeholders. Deliverable: a prioritised extraction backlog with a bounded context map.
- Phase 2 — First extraction (months 3–6): Pull out one low-risk, high-impact bounded context with the strangler fig pattern. Use it to prove the extraction playbook end to end: facade routing, dual-write, data migration, SLO monitoring, rollback. This phase is as much a process dry-run as a technical delivery. Deliverable: one independently deployed service in production and a documented extraction runbook.
- Phase 3 — Systematic decomposition (months 6–24+): Now apply that proven playbook to the remaining priority contexts, one team following the same pattern as the next. Data decomposition speeds up as ownership of the shared database gets clearer. The org restructuring (inverse Conway manoeuvre) runs in parallel. Deliverable: 60–80% of high-change business logic running as independent services.
- Phase 4 — Monolith residualisation: What is left is the stable, low-change stuff nobody touches much. Decide, context by context, whether extracting it is worth the cost. For most enterprises the honest answer is no: leaving 20–30% of the original system as a "residual monolith" is simply the better economics. Deliverable: a documented residual monolith policy and a decommission plan for shared database tables no longer in use.
FAQ
Should we migrate our monolith to microservices?
Not automatically. Migrate when you feel concrete organisational pain: teams blocked by deployment coupling, services that need to scale on their own, or regulatory isolation you are required to enforce. If your team is under 30 engineers, your CI/CD is immature, or the monolith works well and the pain is modest, migration will cost more than it saves. Start with an honest bounded context audit and a clear list of the specific problems you actually want to solve.
What is the strangler fig pattern?
You place a routing facade in front of your monolith and redirect specific request paths to new microservices a few at a time, while the monolith keeps handling everything else. Context by context, you strangle it, until the old system carries so little traffic that you can retire it. Because every step is incremental and reversible, it is the safest way to migrate a live production system.
What is a distributed monolith?
It is the worst-case outcome of a poorly planned migration. You have several services, but they still share one database, or synchronous call chains that span the whole system, or a shared library that forces them all to deploy together. So you carry the full operational complexity of distributed systems and get none of the deployment independence. The root cause is nearly always data decomposition that got skipped or pushed off forever.
How long does a migration take?
You can ship real value, an independently deployed and independently scalable service, in 3–6 months with the strangler fig pattern. Full decomposition of a large enterprise monolith runs 18–36 months. What drives that timeline is data coupling and organisational change, far more than the coding itself. Budget for the org change to take about as long as the technical work.
How do we avoid downtime during migration?
The routing facade is your main lever: if a new service fails, you switch traffic back to the monolith in seconds. Back that up with dual-write during database cutover phases, blue-green deployments at the service level, feature flags at the facade, and thorough distributed tracing so you catch regressions before they reach every user. Never do a big-bang database cutover on a live system. Always run dual-write with a validation window first.
Last updated 3 July 2026. Cost benchmarks reflect YuSMP Group engagement data and publicly available industry reports (Gartner, CNCF, ThoughtWorks Technology Radar). Individual migration costs vary based on monolith size, coupling, team structure and observability maturity.
