No Big Bang
The outlined approaches suggest that the existing legacy application is supplemented in a stepwise manner by microservices or that individual parts of the legacy application are replaced by microservices. This type of approach has the advantage that the risk is minimized. Replacing the entire legacy application in one single step entails high risk due to the size of the legacy application. In the end, all functionalities have to be represented in the microservices. In this process numerous mistakes can creep in. In addition, the deployment of microservices is complex as they all have to be brought into production in a concerted manner in order to replace the legacy application in one step. A stepwise replacement nearly imposes itself in the case of microservices since they can be deployed independently and supplement the legacy application. Therefore, the legacy application can be replaced by microservices in a stepwise manner.
Legacy = Infrastructure
Part of a legacy application can also simply be continued to be used as infrastructure for the microservices. For example, the database of the legacy application can also be used for the microservices. It is important that the schemas of the microservices are separate from each other and also from the legacy application. After all, the microservices should not be closely coupled.
The use of the database of the legacy application does not have to be mandatory for the microservices. Microservices can definitely also use other solutions. However, the existing database is established with regard to operation or backup. Using this database can also present an advantage for the microservices. The same is true for other infrastructure components. A CMS, for instance, can likewise serve as common infrastructure, to which functionalities are added from the different microservices and into which the microservices can also deliver content.