Transitional approaches in Cloud Transformations: Cutover planning and the role of middleware

 

Two key concepts that are typically either planned late or addressed reactively in transformation projects are: 1. Cutover strategy, and 2. Planning the migration of middleware while also reusing the middleware solutions for both one-time migrations and for near-real-time integrations. Having these plans in place makes the changeover more seamless, with little or no impact on the systems’ functioning taking into consideration the time period between the end of the on-premises (or legacy) system and the beginning of the cloud (or modern) system.

Cloud Transformations require transition planning to cutover applications, databases, middleware, users, administrators, and other stakeholders to the applications that are being migrated to the cloud. A detailed plan that outlines the steps needed to migrate from the enterprise's on-premises data center (or other cloud platforms) to Microsoft cloud is essential.

Some of the choices for cutover methods are Big Bang, Parallel, Phased or Incremental. This is essentially different deployment plans because they focus on transitioning from the source data center to Azure while deployment plans outline activities necessary to deploy an application to Azure. Customers have found that phased or incremental cutover in combination with a parallel cutover method is more effective, especially in brownfield implementations.

This document describes the method of switching applications and users to the cloud platform using a mix of both the phased and the incremental approaches. It also shows how reusing of the middleware solution during the cutover stage.

 

Combining the Parallel and Incremental cutover methods

 

Parallel running is a popular approach to cloud migration because it greatly de-risks the outcome. However, it can be complex to implement, test, support and maintain both on-premises and Azure simultaneously even if it is within a short cutover period. A Phased or Incremental cutover is when the enterprise implements the system on Azure in tranches. This method can be useful to ensure that interruption and downtime are minimal and less risky.

Combining the two approaches to a Parallel-Incremental cutover before decommissioning the on-premises systems completely combines the benefits of both approaches and reduces the risks introduced by each of them. In that, the system’s functionalities will be gradually transformed from on-premise to cloud while both the systems are run in parallel. This requires a one-time migration (ETL/ELT) of the data to the cloud data store through say Azure Data Factory and a real / near-real time 2-way sync / Heart-beat service between the systems.

 

The Cloud Transition journey is not an easy one and could pose several hurdles. Breaking the decommissioning strategy & plan into increments for cutting over to the modern system can help reduce the risks.

 

Integration and sync considerations

 

A key part of the migration and integration is to design the ETL/ELT of the two-way sync in a way that a good portion of the code such as source to target mapping, can be reused from the One Time integration to the real time service. The team & resources considerations are also key here because the team that handled the integration & transformation of the applications need to be resourced in the project plan to build the sync services during the cutover phase.

Another key consideration is for a staging and/or cross-reference table for the cutover period. For instance, an Invoice_ID generated in the source table by the source application may be different from the Invoice_ID in the Azure database like Azure SQL or Cosmos DB. An XRef ID that correlates the two will be required to ensure tracking & tracing between the on-premises and Azure. The X-ref tables may be retained as long as necessary but typically for a short period after the legacy systems are completed sunset.

 

Triggers

 

When both systems co-exist, the flow of data in real / near real time requires a trigger from either of the systems to maintain the synchrony. Based on the technology that the application and/or database was built on, a push or a pull method can be used for the integration service to work. For instance, an application trigger from the source system can set off the integration service with an event message such as into an Azure Service Bus queue or Storage queue which will then need the rest of the data to get pulled from the source to the cloud system and vice versa.

Another instance is where a database trigger can start the event service. This method is the push of the data on the occurrence of a new event. In cases where a push is not feasible, a periodic pull for delta / incremental data is preferred. However, this causes additional runs for the service that could not be say a pay-per-use model or introduces delays in the sync itself.

 

Design Patterns

 

Design patterns such as the 2-phase commit, Paxos, Pub-sub can help design the 2-way sync systems for the transition period. For instance, an application trigger from a legacy system in the on-premise data center can send an event message through the Azure Event Hub while the data related to the event can be fetched through the Azure Service Bus while also marking the staging table with the relevant statuses. ‘Triggered’, ‘Fetching’, ‘Committed’, ‘Failed after 3 retries’ etc. can be some statuses in the staging table while a 2-phase commit pattern runs through say distributed transactions between the on-premises SQL Server and Azure SQL DB.

 

 

The picture below shows the combination of the parallel and incremental cutover methods.

 

 

Note that after the one-time migration, users and functionality are incrementally introduced to the destination. With thorough user acceptance testing, business readiness testing, integration testing, mock cutover plays, end user training, all users and all functionalities of the on-premises systems are released to the cloud systems and the on-premises systems can be decommissioned for go-live on the Microsoft Cloud.

 

Communication

 

Effective communication plays a crucial role in a successful transition process. Keeping everyone informed about the ongoing progress, upcoming steps, and completed tasks is essential. Consider creating a communication plan that outlines the following:

1. Stakeholders: Identify who the key stakeholders are.
2. Messaging Schedule: Define when and how stakeholders will receive or send messages.
3. Contact Points: Specify whom stakeholders can reach out to if they have any questions or encounter issues.

 

Author Bio

Pradyumna (Prad) Harish is a Principal Cloud Solution Architect in the Partner Success Organization at Microsoft. He has over 25 years of experience in Product Engineering, Partner Development, Presales, and Delivery. Responsible for revenue growth through Cloud, AI, DevOps, Integration, Service Oriented Architecture, Data & Analytics, IoT, AI, Cognitive Services, ML, Digital strategies and other innovative areas for business generation and transformation; achieving revenue targets via extensive experience in managing global functions, global accounts, products, and solution architects across over 26 countries.