Migration path

Consider that the migration process will allow you to create a microservice-based, cloud-ready application and not a microservice cloud-native application.

Some restrictions derive from the nature of old Java EE specifications that are not microservice-oriented; the main one is certainly the database.

Remember that each microservice must own the data, so it must be associated with a single database instance. It's hard to split a single database instance, designed for a monolith application, into multiple instances associated with new bounded contexts that are implemented by microservices.

Concepts such as foreign keys, data integrity, and database transactions, intended to guarantee validity even in the event of errors using the atomicity, consistency, isolation, durability (ACID) paradigm, are difficult to maintain through multiple database instances that are managed by distributed and heterogeneous applications.

To refactor a monolith into microservices, you could evaluate and implement the following steps:

1. Divide the frontend layer from the backend layer: The separation should not only be from the code point of view (e.g., creating two Maven projects) but also from the distribution unit point of view (e.g., creating two WAR files, one for the frontend and the other for the backend). These two macro areas of the project have usually different release life cycles and need different skills. Having two teams that develop these areas will give you the opportunity to best implement these actions.
2. Split the backend layer into multiple microservices: You should analyze your complex domain and divide it into multiple simpler domains that must be fully consistent. Remember that to be a real microservice, you should also create a dedicated database for each of the new microservices. You could decide to postpone this process to a second phase. In this way, you could benefit from all of the positive aspects of an MSA in terms of ease of development, isolation, resiliency of code, and ease of deployment. But without the full ownership of the data and continuing to use a shared data store, your multiple distribution units continue to form a monolith.
3. Change the way to expose your data: Replace obsolete communication protocols, such as Enterprise Java Bean (EJB) remote, or complex methods such as SOAP web services, with a light communication model such as HTTP RESTful.
4. Change the data transfer protocol: Remove strong coupling modes, such as Java objects, for example, using Java serialization, or using heavy and complex structures, such as XML payload, in favor of loose coupling, and an easy and light structure such as JSON objects.
5. Remove heavy orchestrator actors: If your monolith runs in an SOA, replace ESB objects with the use of Enterprise Integration Pattern (EIP) to orchestrate the workflow process inside a coarse-grained service.

These are the basic and fundamental steps that you should implement to migrate from a monolith structure to an MSA. Consider that it's not mandatory to perform the steps we have described, and the respective points described in each step, all at one go.

You could proceed to disassemble the monolith gradually in order to evaluate the consequences of the updates to your application, team workflow process, and company structure. As suggested in the Agile methodology, splitting the work into little sprints could help you evaluate the real impact of your job and react faster to potential failures.