How to migrate from monolith to microservices
How to migrate from monolith to microservices
Most teams should not migrate from monolith to microservices in 2026. The strangler-fig pattern works only at scale (above roughly 50 engineers with separate release-cadence pressure across teams). For everyone else, a modular monolith is the right answer, and the operational tax of microservices will burn cash you do not have.
That is the honest take. The rest of this post walks through the four legitimate triggers for migration, the modular-monolith middle path that fits 90% of teams, the strangler-fig pattern when migration is genuinely required, and the dollar cost of the operational tax so you can run the math yourself.
Why this is the wrong default in 2026
The 2018-to-2022 era treated microservices as the obvious next step after a monolith got "too big." That assumption has cracked.
The CNCF's 2025 survey found that 42% of organizations who initially adopted microservices have consolidated at least some services back into larger deployable units. The drivers were debugging complexity, operational overhead, and network latency.
The headline case is Amazon Prime Video. In 2023, the Video Quality Analysis team published a now-famous post showing a 90% cost reduction after collapsing a Step Functions and Lambda pipeline into a single monolithic process. Important nuance: this was one workload inside Prime Video, not a company-wide reversal. The rest of Prime Video still ships on microservices. The lesson is per-workload, not "microservices bad."
Neal Ford and Sam Newman, two of the loudest microservices voices of the last decade, called 2026 the renaissance of the monolith. Shopify, Stripe, Basecamp, and GitHub all run modular monoliths well past Series C. If your tech-leadership instinct is "we have grown, time to break this up," check that instinct against the people actually shipping at scale.
The four legitimate triggers for migration
You should consider extracting services from a monolith only when one of these is true:
- Regulatory or compliance boundary. PCI scope reduction (a card vault), HIPAA isolation (a PHI handler), or SOC 2 segmentation can justify a separate service because the audit surface shrinks. The cost is real but the compliance-savings math often clears it.
- Polyglot necessity. A Python ML inference service alongside a Rails app is a real reason to split. Trying to wedge PyTorch into your Ruby process is worse than the network call.
- Scale beyond a single deploy unit. When one part of the app gets hit 100x harder than the rest (search, image processing, real-time chat) and scaling the whole monolith to handle it wastes compute, that workload deserves its own deploy unit.
- Separate release-cadence pressure. When two teams are blocking each other's deploys often enough that velocity craters, splitting the deploy graph is worth the operational cost. This usually shows up around 50 engineers, not 15.
If none of these apply to you, you do not have a microservices problem. You have a code-organization problem, and the answer is a modular monolith.
The modular monolith middle path
A modular monolith is one deploy unit with strictly enforced internal boundaries. You get the dependency hygiene of microservices without the network, the orchestration tax, or the on-call sprawl.
Shopify is the case study everyone should read. Their core monolith is 2.8 million lines of Ruby, 500,000 commits, and 37 components with public entry points. They peaked at 30TB per minute during Black Friday 2025 without splitting it apart. After adopting Packwerk for static dependency analysis, cross-module regressions dropped 68% year-over-year and new-developer onboarding fell 55%.
Stripe runs a similar pattern in Ruby. Basecamp's HEY is a Rails monolith. GitHub's monolith powered the platform through hundreds of millions of users before any meaningful service extraction.
The tooling matters. Pick the boundary-enforcement tool that matches your stack:
| Stack | Tool | What it does |
|---|---|---|
| Ruby / Rails | Packwerk | Static dependency analysis, enforces "pack" boundaries at CI time |
| Java / Spring | Spring Modulith | Runtime + compile-time module checks, event-based cross-module calls |
| TypeScript / Node | Nx, Turborepo + ESLint boundaries | Workspace-scoped imports, build-graph isolation |
| Python / Django | import-linter | Forbids upward imports, enforces layered architecture |
For frontend teams running a similar split inside a Next.js codebase, the same instinct applies; you can read more in our guide on structuring a Next.js project for scale.
The modular monolith failure mode is decay. Without CI-enforced boundaries, "modules" become aspirational and someone always reaches across them at 4am during an incident. Pick a tool, wire it into CI on day one, and treat boundary violations as build failures.
The strangler-fig pattern (when migration is actually right)
If you genuinely qualify (one of the four triggers above, plus a team large enough to absorb the operational tax), the strangler-fig pattern is the right migration approach. Big-bang rewrites have a near-100% failure rate at this scale.
Here is the practical sequence:
- Pick one bounded context with the strongest separate-release-cadence pressure. Auth, billing, search, and notifications are common first extractions because they have clean boundaries and obvious owners.
- Stand up the new service behind the existing API surface. The monolith still owns the public contract. Inside, calls fan out to either the old code path or the new service.
- Route traffic incrementally with a proxy or feature flag. Start at 1%, watch error rates, ramp to 10%, then 50%, then 100%. Tools: LaunchDarkly, Unleash, or a homegrown header-based flag in your edge proxy.
- Wait for the new path to hold in production for at least 30 days under full load. Watch error rates, latency, and on-call pages. If anything wobbles, ramp back down.
- Delete the old code path. This is the step everyone skips. If you do not delete the old code, you have two systems forever and double the maintenance cost.
- Repeat for the next bounded context. Do not do more than one extraction in flight at a time per team.
A typical mid-size monolith extraction (one service, end-to-end) takes 3-6 months. Migrating five services takes 12-24 months. Plan accordingly. Segment famously rewrote part of their microservices back to a monolith mid-migration after the operational cost outpaced the benefit.
Observability is non-negotiable here. You need distributed tracing across the monolith and the new service from day one or you will spend incidents staring at disconnected logs. Our OpenTelemetry guide covers the minimum viable setup.
For the deployment story, you are likely choosing between Kubernetes and a simpler orchestrator. Read our Kubernetes vs Docker Swarm post before committing to k8s; for two services, Swarm or even bare Fargate is often the right answer.
The operational tax (in real dollars)
This is the section the consensus content skips. The honest cost of running microservices in 2026:
| Cost line | Monolith | Microservices |
|---|---|---|
| Compute (small/medium app) | $500-3k/mo | $3-8k/mo (per-service overhead) |
| Orchestration (k8s control plane) | $0 | $300-800/mo (EKS/GKE) |
| Service mesh (Istio, Linkerd) | $0 | $500-2k/mo in compute + ops time |
| Distributed tracing (Datadog APM, Honeycomb) | optional | $1-5k/mo at scale |
| On-call rotation (extra FTE-equivalent) | 0.5 eng | 1.5-3 eng |
| Platform engineer salary | not required | $200-300k/yr per FTE |
For a Series A-stage SaaS, you are looking at roughly $15k/mo to operate a modular monolith versus $40-65k/mo for a comparable microservices setup. That is $300-600k/year of runway. Most Series A rounds cannot absorb that.
Network calls also replace function calls, which means your latency budget shrinks. A 50ms function call becomes a 5ms network call plus serialization plus retry logic plus circuit breaker plus observability overhead. Multiply by depth of fan-out and you can easily turn a 100ms p95 into a 600ms p95 with no business value added.
Schema migrations get worse, not better. In a monolith, a database migration is one PR. Across services, it becomes a coordination problem with versioned APIs, deprecation windows, and at least one Slack thread per quarter where someone says "wait, who owns this column."
What to do this quarter
Match your decision to your stage:
- Pre-Series A (1-15 engineers). Stay on a monolith. Add module boundaries with the tool that matches your stack. Do not buy a Kubernetes cluster. Read our scale MVP to production post for what actually matters at this size.
- Series A or B (15-50 engineers) with one painful module. Extract that one. Keep the rest monolith. Use the strangler-fig sequence above. Plan 3-6 months for the first extraction.
- Series C+ (50+ engineers) with deploy-cadence pain across multiple teams. Plan a 12-24 month strangler-fig migration. Hire a platform-engineer FTE first; you cannot do this on the side of someone's desk.
Whichever path you pick, hire correctly for the work. Strangler-fig extraction is senior engineer work, not junior. You need someone who has done a migration before, can read a tracing waterfall, and will tell you "no" when the plan drifts.
If you want a sanity check before committing to a migration, audit your stack with Ship or Skip and get an honest grade on whether your current architecture is actually the bottleneck. Most teams who run it find the answer is no.
Every engineer on Cadence is AI-native by default (Cursor, Claude Code, Copilot used daily; vetted on a voice interview before they unlock the platform). Senior tier ($1,500/week) is the right shape for monolith decomposition and strangler-fig extraction work. The platform's median time to first commit is 27 hours, so you can have an engineer reading your codebase in under two days.
Whatever you do, do not migrate because a conference talk told you to. Run the math. The default in 2026 is "stay monolith, modularize." Migrate only when one of the four triggers genuinely applies.
Considering an extraction? Before you spin up a Kubernetes cluster, audit your current stack honestly. If a senior engineer is the right next step, Cadence books one in 2 minutes with a 48-hour free trial.
FAQ
How long does a monolith to microservices migration take?
Partial migrations of mid-size monoliths (one or two services extracted) typically run 6-18 months. Full migrations rarely finish on the original timeline. Segment famously rewrote part of their microservices stack back to a monolith mid-migration after the operational cost outpaced the benefit.
What is the strangler fig pattern?
An incremental migration approach where a new service runs alongside the monolith and a proxy or feature flag gradually routes traffic to it. The old code path is deleted only after the new one has proven stable under full production load for at least 30 days.
Should a 10-engineer startup migrate to microservices?
Almost never. Stay on a monolith and add module boundaries with a tool like Packwerk (Ruby), Spring Modulith (Java), or import-linter (Python). The operational tax of microservices outweighs any benefit at this size, and the engineering hours spent on platform work are hours not spent on product.
What is the difference between a modular monolith and microservices?
A modular monolith has enforced internal boundaries but ships as one deploy unit. Microservices have those boundaries plus separate processes, networks, and release cycles. The boundaries are similar; the operational cost is not.
Why did Amazon Prime Video move back to a monolith?
One team (Video Quality Analysis) cut 90% of their costs by collapsing a Step Functions and Lambda pipeline into a single process, because the data transfer between steps was the bottleneck and keeping it in-process eliminated S3 round-trips. The rest of Prime Video still uses microservices. The lesson is per-workload, not company-wide.