When an architectural change this big is agreed upon, it is natural to perform migration of the whole monolith at once. Freeze all current development, develop a plan, split tasks and start. But beware!

If the decision to migrate is made, it is likely we already have a large codebase and an excessively large team that has lost coordination and velocity. The business will not accept months without new features, either.

The right way is to go incremental. Create a small team of experienced engineers, isolate a narrow component for migration, and set no hard deadlines. You will uncover unexpected issues early — but with limited scope, the cost of mistakes stays low and progress is still clearly visible.

How to execute the migration?

1. Define API of the component to be extracted.
2. Ensure its thorough automated test coverage with a 100% pass rate.
3. Isolate the component by removing dependencies on the monolith.
4. Extract into a microservice and ensure all tests passing.
5. Put the microservice behind a facade (e. g., an API gateway).
6. Route part of production traffic to it.
7. Monitor the service under the real load and fix issues.
8. Remove the extracted component from the monolith.
   This approach is commonly known as the Strangler Fig Pattern.

Microservices migrations fail most often not because of technology — but because the change must be both technical and organizational.