Monolith to Microservices: When (and How) to Make the Move
Most monolith-to-microservices migrations fail. Here's the version that doesn't.
Don't do a big-bang migration. Don't migrate for the wrong reasons. Don't migrate without instrumentation. Here's the playbook that actually ships.
Most monolith-to-microservices migrations I've seen fail. They fail in the same ways. Here's the playbook for the version that succeeds.
When NOT to migrate
- The team is small (<20 engineers)
- You're not at scale that justifies the operational overhead
- You don't have a platform team to operate the new infra
- You're migrating because "best practice" says to, not because of a real pain
- Your monolith is just badly organized - fix that first
Real reasons to migrate
- One domain has fundamentally different scaling needs (e.g., your media transcoding service should not deploy with your auth service)
- One domain needs a different language/runtime
- Different teams own different domains and you need independent release cadences
- Your monolith deploy is so big that single-feature releases are blocked by other features
The migration that works
Phase 1: stabilize the monolith.
- Add observability (OTel, structured logs)
- Add deploy automation (CD pipeline, blue/green or canary)
- Refactor into modules with clean boundaries inside the monolith
- This phase is 2-3 months. Don't skip it.
Phase 2: pick ONE service to extract.
- Pick the bounded context with the cleanest interface
- Pick the one that has the strongest case for being separate
- Extract behind a feature flag. Run both in parallel.
- Migrate traffic gradually. Watch metrics. Have a rollback plan.
Phase 3: stabilize the extracted service.
- 2-3 months of operating it before extracting the next
- Build the patterns the rest of the team will use (auth, observability, deploys, error handling)
Phase 4: extract the next service.
- Repeat phase 2-3
- Each subsequent extraction is faster because the patterns exist
A real migration takes 12-18 months. There's no faster path.
What goes wrong
- "Strangler fig" without committing. Teams start the strangler pattern, get distracted, end up with a monolith AND services for the same domain. Worst of both worlds.
- No rollback plan. Migration fails, can't roll back, scrambles to fix forward at 2am.
- Distributed monolith. Services that only work together, deployed independently. You've added complexity without gaining flexibility.
- No service ownership. Five services, two engineers, nobody owns anything. On-call collapses.
The harder truth
Most teams that "successfully" migrated to microservices look back and say they could have shipped the same business outcomes with a well-organized monolith for half the cost.
Microservices are a real architecture for real problems. Make sure you have the problem.