# A Systematic Mapping Study on the Modernization of Legacy Systems to Microservice Architecture
## 4 Results
### Main Activities
Although (semi)automated techniques can be employed to assist with the decomposition into microservices, the primary recommendation is to initially prioritize features with minimal impact or risk for the transition from the legacy system to the modern system. In essence, this process entails the identification of prospective microservices that offer the greatest value and exhibit minimal external dependencies. While there is no singular methodology for microservice decomposition, Domain-Driven Design (DDD) is a prevalent approach utilized to facilitate the transformation of legacy systems into MSA. * Development. This activity is the second most recurrent in our mapping, with 26 studies (i.e., S1, S6, S7, S12 to S18, S20, S21, S24, S26 to S29, S31, S32, S34 to S38, S41, and S43). Once the scope of the legacy system has been fully understood and a preliminary solution has been outlined, development teams can proceed with the development of microservices. In terms of development, two principal approaches to migrating a legacy system to a microservice-based architecture can be highlighted. The first of these is to rewrite the legacy system from scratch, while the second is to extract the microservices (i.e., functionalities) from the legacy source code. The evidence from our mapping suggests that the second option is the most recommended approach for legacy systems with high-value legacy code. In parallel, it is also crucial to highlight that the previous iteration of the legacy system must be terminated as the development of microservices progresses to prevent the emergence of maintenance issues stemming from the coexistence of functionalities in two distinct locations. Moreover, these findings also indicate that microservice development should be guided by the principle of one microservice per team to ensure that each microservice addresses a single, specific problem. Therefore, after this activity, the microservice-based system must be fully functional and ready for release. * Integration. This activity was identified in 13 studies (i.e., S1, S13, S17, S18, S20, S21, S26 to S28, S31, S35, S41, and S43) of our mapping. In the integration activity, microservices must be combined and synchronized to form a functional and cohesive application. Throughout this activity, microservices establish connections via APIs or alternative communication mechanisms, ensuring the exchange of data and information essential to the overall functioning of the system. In addition, this activity may also involve the integration of the modernized system (i.e., microservices) with other external systems or components. The integration of microservices enables the verification of interactions between microservices and the acquisition of communication parameters with external systems. At this stage, any incompatibilities or inconsistencies can be identified and corrected, ensuring that the integrated application is stable and reliable. Finally, evidence from our investigation suggests that integration can also entail the establishment of continuous deployment pipelines and process automation to facilitate the distribution of microservices across disparate environments, such as development, testing, and production. Upon completion of this activity, the modernized software is expected to be ready for deployment and available for use by end users. * Monitoring. This activity is the least common in our mapping, as evidenced by four studies (i.e., S7, S15, S20, and S21). In the context of MSA, monitoring is a first-class task due to the distributed and complex nature of these systems. Our findings suggest that given the interactions among multiple microservices and their deployment in disparate environments, it is imperative to possess comprehensive visibility of the status of each component and its interactions with other microservices.