Skip to Content

Taking a phased approach to modernization

Rishi Kulkarni

Modernizing legacy applications can be complex, especially when multiple applications are involved. The most challenging aspect of modernization is the movement of users and consumers of legacy application services to the new modernized stack. This includes bringing in new systems during the interim phase, synchronizing data, providing business coverage with fully serviceable overlapping functionality and, at times, developing temporary systems and processes for bridging legacy applications to the new system.

Due to the scope and size of a typical modernization initiative, organizations often must take a phased approach to introduce the updated platform. In a multi-phase strategy, organizations synchronize the new platform with the legacy applications until it’s possible to switch over to the new platform and microservices. While enterprises are still in the process of modernizing, legacy and updated services will coexist as organizations transition gradually.

This type of phased approach should use a strangler pattern, which migrates a legacy application incrementally by replacing existing functionalities with new platform and services in a step-by-step manner. This strategy will require an initial load phase to ensure that all operational and configuration data required for the new microservices to fully operate in production are available in the new platform. It also requires an overall state synchronization between the new and old systems to maintain data integrity and data-model dependencies between individual functions.

Initial load

In the initial load phase, a company migrates all available reference data, user information, and required history and transactional data from legacy applications to the new platform. Mapping is important in this phase. This includes mapping entities from the legacy application to the modernized equivalents on the new platform, transforming data from legacy applications to address the domain model of the new platform, and filling in the blanks or extrapolating where there are gaps given that the domain model of the new platform will be a superset of the legacy applications.

State synchronization with legacy systems

A big-bang approach, where you completely replace a complex system with cloud-native applications, can be a huge risk. The strangler pattern reduces the chance of a complete failure. However, running two separate versions of an application means that an organization needs to know where each feature is located. Every time a feature or service is migrated, users need to be updated with the new location. Strangler patterns facilitate this by creating a routing façade. There are two options for doing this: modifying monolithic functionality or using event choreography patterns.

Phased introduction of modernized services

State synchronization option one: Modifying monolithic functionality. The first option for the roll-out involves routing current transactions on the legacy application to the newly developed microservices. All business logic and southbound communication are switched off in the legacy application as the transaction management responsibility shifts to the new services. This will require selectively switching off the functionality in the old applications while continuing to write database transactions to maintain data consistency for the operations of other functionalities that have not yet been transitioned to the new application. This approach simplifies the overall integration between the legacy system and new microservices platform as it does not require any external process to maintain data synchronization.

State synchronization option two: Utilizing event-choreography patterns. While the first option provides simplified integration of new microservices with the legacy applications, it may also require significant complex modifications to the existing application. To circumvent this complexity, organizations can use event-choreography patterns. In this approach, data is synchronized between the old and new applications as a non-intrusive, event-based architecture, which ensures that data consistency and integrity are maintained during the rollout. Ultimately, functionality in the old application is switched off once all services are transferred to the new system. This option will require the definition of events, publishers, and subscribers as well as a mechanism to exchange events between the old and new applications via a messaging bus.

Both of these options have pros and cons. Determining the right approach requires having a deeper understanding of existing monolithic capabilities. In general, organizations should select the option that is simplest and leads to the least amount of technical debt.

For more information, please check out The app-modernization manual: The definitive guide to building intelligent apps from Capgemini, or reach out.