Monolith to microservices
Monolith to microservices: split what pays, leave the rest whole.
Microservices are a cost you take on to get something specific. We help you check that you need it, then cut over one piece at a time.
The short answer
Moving from a monolith to microservices means splitting one deployable application into independently deployed services, each owning its data. The safe route is the strangler approach: route one capability at a time to a new service while the monolith keeps running. Ace8 also tells you when a modular monolith is the better answer.
Decision
Should you split the monolith at all?
A monolith is not a defect. A well-structured one is simple to test, deploy and debug, and it has no network between its parts. Splitting trades that simplicity for independent deployment and scaling. The trade is worth it only when you feel a specific pain.
| Signal | Points to splitting | Points to staying |
|---|---|---|
| Release cadence | One team's change waits on another's | Releases are rare and not blocked by others |
| Scaling | One module needs 20 times the capacity of the rest | Load is even |
| Team structure | Several teams edit one codebase and collide | One team owns it |
| Technology | A part needs a different runtime or data store | One stack fits all |
| Failure isolation | A fault in one area takes down everything | Faults are rare and contained |
| Operations skill | You run containers, tracing and on-call well | You do not yet |
Alternative
What is a modular monolith, and when is it enough?
A modular monolith keeps one deployable but enforces boundaries inside it: separate packages or modules, no direct access to another module's tables, and calls only through defined interfaces. It gives you most of the clarity of microservices, and it leaves the door open. If a module later needs to leave, the boundary is already drawn.
For many Java applications moving off an old app server, a clean Spring Boot modular monolith on Java 21 is the right first target.
Method
How does the strangler approach work?
Put a routing layer in front of the monolith. Build one capability as a new service, route its traffic there, and remove the old code once the new path is proven. Repeat. The monolith shrinks and is never rewritten in one go. This is the third of our eight principles: strangle, don't big-bang.
- 1
Find the seams
Map dependencies and data access to see which capabilities have clear boundaries. Tools help here, and engineers decide.
- 2
Characterize behavior
Write tests around the capability before extracting it, so the new service can be compared with the old.
- 3
Add the routing layer
An API gateway or a proxy decides whether a call goes to the monolith or the new service.
- 4
Extract one capability
Build it with its own data, and run both paths side by side for comparison.
- 5
Cut over and delete
Shift traffic in stages, keep a way back, and remove the old code when it is clean.
The hard part
Why is the database the hardest part of a split?
A service that shares tables with the monolith is not independent. Each service should own its data, which means copying or moving tables, and replacing joins with API calls or events. Transactions that once spanned modules become sagas, where each step has a compensating action. Expect most of the schedule to go here, not into the code.
- Start by finding which tables each capability reads and writes.
- Use an outbox or change data capture to keep old and new in sync during the transition.
- Accept eventual consistency where the business can, and keep strong consistency inside a service.
- Read database modernization if the data store itself is also a legacy problem.
Communication
How should the services talk to each other?
Use synchronous calls for requests that need an answer now and events for things that happened. A message broker lets services stay loosely coupled. See event-driven architecture. AceMQ runs RabbitMQ and Kafka in production for clients, which makes the broker choice one we can support after go-live.
Related work
What have we done in this area?
The AceMQ engineering team delivered a phased IBM MQ to RabbitMQ migration for American National, with legacy code refactoring and Kafka replaced by Debezium and RabbitMQ for change data capture. That is a phased architecture change on live insurance systems. It is not a monolith split, and we do not claim it as one. Read the American National case study.
Before you start
What must be in place before you run many services?
A fixed-price modernization assessment scores each application with this method and tells you which to split, which to leave whole and in what order.
- Containerization and a repeatable build.
- Tracing, central logging and metrics, because debugging crosses processes.
- An on-call process. More services means more things that can break at night.
- A support partner for the new stack. See supported after migration.
After go-live
Keep it running after cutover.
It is splitting one deployable application into independently deployed services that each own their data, usually in stages to keep the system running.
Only if you have a specific pain, such as blocked releases, uneven scaling or colliding teams. Otherwise a modular monolith is simpler and often enough.
A routing layer sends traffic for one capability at a time to a new service, while the monolith handles the rest. The old code is removed once the new path is proven.
Data. Services need their own data, joins become API calls or events, and cross-module transactions become sagas.
It depends on module count, coupling and test coverage. We give a phased estimate after an assessment instead of a general number.
Yes. Our assessment scores each application for split or stay, and the engineering team can design and carry out the phased extraction.
Know the cost before anything moves.
A fixed-price assessment gives you the inventory, the risk score and a phased plan. Scope and cost are fixed before the migration starts.
Book a Fixed-Price AssessmentGet in touch
Talk to a modernization engineer
Tell us what you run today. An engineer, not a sales script, replies within one business day.