The migration path
Monolith to Microservices: A Course on the Migration Path That Works
The big-bang rewrite is how monolith migrations die. The path that works is incremental:monolith, then modular monolith, then extract modules one at a time when you have a concrete reason. My Modular Monolith Architecture course teaches that path end to end, on a real system, including the extraction itself.
Why the big-bang rewrite fails
The plan always sounds reasonable: freeze the monolith, rebuild it as microservices, switch over when it's done. Then reality arrives. The monolith cannot actually be frozen, because the business keeps shipping. So the rewrite chases a moving target for months while delivering nothing.
Worse, a rewrite forces you to make your hardest architectural decision (where the service boundaries go) at the moment you know the least, before any of those boundaries have been tested by real code. Get one boundary wrong in a monolith and you refactor. Get it wrong across a network and you get chatty services, distributed transactions, and adistributed monolith: all the coupling of the old system plus network failures and eventual consistency on top.
This is how migrations burn entire quarters. The problem is not microservices. The problem is jumping to them in one step.
The incremental path: modularize first, extract later
The reliable migration has two phases. First, turn the monolith into amodular monolith: split it into modules along bounded contexts, give each module its own domain model and data, and force all communication through narrow public contracts. You get this done while the system keeps shipping, because it is refactoring, not rewriting.
Second, extract. But only when a module gives you a reason: it needs to scale independently, a team wants to own its deployments, or it has different availability requirements. Because the boundary already exists and is already enforced, extraction becomes a mechanical step instead of a leap of faith. And modules that never earn extraction simply stay where they are, at zero distributed-systems cost.
I cover the tradeoff in detail in Modular Monolith vs. Microservices and the destination in Getting Started With Microservices in .NET.
What extraction actually involves
Extraction is where most courses stop and wave their hands. It is also where the real work is, which is why chapter 10 of Modular Monolith Architecture is a complete extraction playbook, performed on camera:
- ✓A YARP API gateway in front of the system, so clients keep calling one endpoint while services move behind it.
- ✓RabbitMQ for distributed messaging, replacing in-process events between the extracted service and the rest of the system.
- ✓Distributed tracing with OpenTelemetry, so a request can be followed across the gateway, the monolith, and the new service.
None of it works without the groundwork from earlier chapters. Module communication patterns (chapter 4) determine what can be cut apart. Reliable messaging with the Outbox and Inbox patterns and idempotent consumers (chapter 7) means the events surviving the move to a broker were already built for at-least-once delivery. That is the point of the course: extraction is easy when everything before it was done right.
Learn the full path on one real system
Modular Monolith Architecture covers the entire journey on Evently, an event ticketing platform we build from scratch: module boundaries with DDD and Event Storming, module communication, Keycloak authentication, architecture enforcement, reliable messaging, event-driven architecture, testing, and finally the microservice extraction. 10 chapters, 12+ hours of video, full source code, lifetime access, updated to .NET 10. 2,800+ engineers have taken it.
Frequently asked questions
Do I need microservices at all?
Maybe not, and that is a perfectly good outcome. Most systems are better served by a well-structured modular monolith: one deployable, in-process performance, no distributed transactions. Extract a service when a module has a concrete reason to live on its own, like independent scaling or a separate team owning its release cycle. "Everyone else is doing it" is not a reason.
When should I extract a module into a microservice?
When you can name the benefit. Common triggers: one module needs to scale independently of the rest, a separate team wants to deploy it on its own cadence, or it has different availability or technology requirements. If the module already has clean boundaries and communicates through events, extraction is a mechanical exercise instead of a rewrite.
Does the course cover the actual extraction, or just the theory?
The actual extraction. In chapter 10 we take a module from the Evently system and turn it into a standalone microservice: introducing a YARP API gateway, moving module communication onto RabbitMQ, and wiring up distributed tracing with OpenTelemetry so you can follow a request across service boundaries.
Can I apply this to my existing monolith?
Yes. The patterns (module boundaries, communication contracts, Outbox and Inbox, architecture testing) apply directly to brownfield systems. The Community plan also includes "Modularize Your Monolith", a bonus course that walks through modularizing an existing monolith application step by step.
What technologies does the migration use?
The system is built on .NET 10 with PostgreSQL, Redis, and Docker. The extraction itself uses YARP as the API gateway, RabbitMQ for distributed messaging between services, and OpenTelemetry for distributed tracing. Keycloak handles authentication across the system.
What experience do I need before taking the course?
At least 1 year of ASP.NET Core experience, preferably with Entity Framework Core. You do not need any prior microservices experience. Familiarity with Clean Architecture and Docker helps, since external services run in containers.