I've helped five companies migrate from monoliths to microservices over the past four years. One of those migrations was a clear success. Two are still in progress but heading in the right direction. One delivered mixed results. And one should never have been started. Here's what I learned about when to decompose, how to do it and when to leave well enough alone.
The Migration That Shouldn't Have Happened
The team had 12 engineers. Their monolith served 50,000 users. They were shipping new features every two weeks. The system was well-organized with clean module boundaries, good test coverage and a CI pipeline that ran in 12 minutes. The CTO had read that microservices were the future and decided to migrate. Eighteen months later, they had 30 services, 4 different programming languages, 3 message queues and 2 Kubernetes clusters. They were shipping features every two months. Two of their best engineers quit.
The painful truth is that most teams should not migrate to microservices. The benefits, independent deployability, team autonomy, technology flexibility, only matter at a scale where the costs of coordination outweigh the costs of infrastructure complexity. For most teams under 30 engineers, a well-structured monolith with clear module boundaries will serve you better than a distributed system.
When Migration Actually Makes Sense
After these experiences, I ask teams three questions before recommending a migration: Is the monolith genuinely slowing you down? Specifically, are you unable to deploy changes because unrelated parts of the system need to be tested together? Are you having trouble scaling the team because too many people need to understand the same codebase? Do you have concrete, measurable problems, not hypothetical future problems, that microservices would solve?
If the answer to all three is yes, a migration might make sense. If not, you probably need a better monolith, not microservices.
The Strangler Fig Pattern Works
For every migration we've done successfully, we used the strangler fig pattern: identify a bounded context within the monolith, extract it as a separate service with its own database, route traffic gradually to the new service, and only remove the old code once the new service has proven itself in production.
The key insight is that you should extract services one at a time, and each extraction should take weeks, not months. If extracting a service takes more than a month, the boundary you've chosen is probably wrong. The natural boundaries in your domain don't require months of refactoring to extract.
Don't Touch the Database Yet
One mistake we made early was trying to decompose the database at the same time as the code. This doubles the risk and complexity. We now recommend a phased approach: first extract the code into a separate service that shares the monolith's database. Once the service is stable and the team is comfortable with the deployment and monitoring, migrate the data to a dedicated database.
Shared databases between services are not ideal, but they're much better than a failed migration. You can fix database coupling later. You can't fix a team that's lost confidence in the system.
The Infrastructure Tax
Microservices require significant infrastructure investment. You need service discovery, API gateways, distributed tracing, centralized logging, container orchestration, CI/CD pipelines for each service and monitoring for each component. If your team doesn't have the operational maturity to run these tools reliably, start with a simpler approach and invest in infrastructure capability before taking on the complexity of distributed systems.
The honest assessment: for most teams, the costs of microservices outweigh the benefits. Start with a monolith. Keep it well-organized. Extract services only when you have a concrete, measurable problem that microservices would solve. And always ask whether the problem you're trying to solve is a technology problem or an organizational one.