Monolith to Microservices: When (and How) to Make the Move

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.

References

• Strangler fig pattern
• Modular monolith
• Microservices anti-patterns