Absolutely—Spring Modulith is an excellent choice for consolidating your microservices into a modular monolith, and I’ve seen it work really well for teams in exactly your situation. Let’s break down why it fits, plus some practical tips to make the migration smooth:

Why Spring Modulith shines here #

• Preserves your hard-earned service boundaries
  When you built your microservices, you spent time defining clear business domain boundaries. Spring Modulith lets you map each microservice directly to a discrete module, enforcing strict boundaries between them. You can’t accidentally let one module’s internal classes leak into another—just like with microservices, communication happens only through public APIs or events. This keeps your codebase from devolving into a messy "big ball of mud" monolith.

• Seamless event-driven logic transition
  Most microservices rely on event-driven communication (like async updates between order and payment services). Spring Modulith’s internal application event system aligns perfectly with this pattern. You can replace your external message brokers with lightweight in-memory events first, or even bridge them temporarily during migration. The event handling code you wrote for microservices will feel familiar, so you don’t have to rewrite core business logic from scratch.

• Familiar tooling and minimal learning curve
  If your team already uses Spring Boot (which is almost a given for Spring-based microservices), you’ll be right at home with Spring Modulith. It’s built on top of Spring Boot, so you can reuse all your existing knowledge of Spring annotations, dependency injection, and configuration. No need to learn a completely new framework.

• Built-in observability for module interactions
  One of the pain points of moving from microservices to a monolith is losing visibility into service interactions. Spring Modulith solves this with its module visualization tools—you can generate dependency graphs, event flow diagrams, and even track cross-module calls. This is super helpful for teams coming from a microservices background, as it mirrors the service dependency tracking you’re used to.

Practical tips for your migration #

• Start small, group by business domain
  Don’t try to merge all microservices in one go. First, group microservices that belong to the same business domain (e.g., order management, payment processing) into a single module. This reduces complexity and lets you validate the approach before scaling up.

• Adapt external communication to internal patterns
  Replace Feign clients or REST template calls between microservices with direct module-to-module interface dependencies. For async flows, swap your MQ consumer/producer code with Spring Modulith’s @ApplicationEvent and @EventListener annotations—this keeps the async behavior but removes the overhead of external brokers.

• Leverage module isolation testing
  Spring Modulith lets you test individual modules in isolation, just like you tested individual microservices. Use @ModuleTest to write tests that only load the module you’re working on, ensuring that your modules remain independent and functional even as you merge them.

Final thought #

Spring Modulith is often framed as a tool to split monoliths into microservices, but its real strength is modular governance—and that works both ways. It’s designed to help you build (or rebuild) applications with clear, maintainable boundaries, which is exactly what you need when moving from scattered microservices to a unified but modular monolith. Give it a shot—your team will appreciate the simpler deployment model without losing the clean boundaries you worked hard to establish.