Cloud Migration and Transformation: Wave Planning
Written by Rebecca Huber, Clea Zolotow, Hasibe Göçülü
Introduction
IBM has developed an industry leading migration methodology and a supporting toolset to address the challenges during migration to a cloud: IBM Garage Method for Cloud. It is proven, aligned with industry best practices, and scalable to any size engagement. This article provides practical insight from many architects explaining their multiyear experience working with customers during their cloud journey, highlights the special challenges with larger customers, and shows how we design, deliver and validate migrations to Cloud.
In this part of the series, we introduce wave planning concepts and discovery technologies. Wave planning is the idea of bundling associated applications for transition and/or transformation into the cloud, balancing resources, synergies, risks for the migration and business. To avoid confusion on some of the terms used, we have provided an appendix showing some commonly misused terms.
Wave Planning
A wave is an identified group of servers, virtual machines, containers or applications to be migrated in the same time period. In the figure below, physical servers, virtual images, databases and applications are denoted with a different shape and the connectivity between the servers and application dependencies are indicated by lines. A rather common situation is that there are servers shared by multiple applications; in this case, thorough planning in breaking down the overall migration program into waves and balancing the overall effort across separate waves is required.
Planning and Wave Scheduling
Along with determining the migration planning, scheduling is a critical topic. The migration design defines the post-migration state of applications, their managed services and the migration methods to reach the target state. One way ensure migrations are successful is to discover the source environment automatically and use the results to create high-quality migration planning and design.
Wave Scheduling Discovery Process
This process utilizes a tool to discover the server affinities and application dependencies. Additional information is collected from application owners using an interview process. This usually consists of interviews to complement the automated discovery data with information such as the business criticality and context, allowed maintenance windows and ongoing or planned development projects that may impact migration planning. Utilizing this information, the high-level plan for the major waves of the migrations can be constructed.
The discovery database consolidates information about the server affinity, business constraints and application dependency data gathered from IBM’s automated data collection tools and interviews. The discovery information is used by an analytics engine to determine the association of the applications and servers to waves based upon affinities to other servers, applications and other planning constraints.
Once waves have been defined, the database can be interrogated to see inter-dependencies between waves. This becomes a critical point to validate during the application assessment (during the detailed Solution Design phase) to determine mitigations and validate the high-level planning. This may cause changes to the grouping of servers and applications in each wave and may adjust the scheduling of waves in relation to one another (either to occur at the same time or in sequence).
A graphic such as the one above is produced in the planning phase for the business applications. The key unit for migration is a business application The most important aspect in such a graphic is the dependencies between business applications. The dependencies materialize as network communications are partially discovered in the Discovery phase; the connectivity points are those seen that are active during network query points in the discovery interval.
If a connectivity component (grouping of connections) contains too many servers, it must be broken into several move groups. This situation requires extensive planning with the business application owners, e.g., which dependencies are the least critical to cut, how the communication during the (if possible short) interval between the moves is done, application configuration and testing requirements. The planning effort becomes even more critical for a business application that is so large that it cannot be moved within a single move event.
Note that different, separated environments of a business application can be treated as distinct business applications in move group planning. It is recommended to migrate the development/test environment first, assuming it is indeed representative, as any problems that might arise from the new cloud management or during migrations are discovered early on and the lessons learned can be applied to the migration of more critical application environments. Thus, the risk of migration failure and the need to roll back is significantly reduced and issues in the production environment can be minimized.
Migration Waves with Stakeholders
The next step would be publishing the migration waves into an event calendar and jointly reviewing and obtaining commitments from not only the technical owners but also the business owners. It’s important to remember that these migrations touch critical business applications. The migration may have financial implications if it impacts the business due to outages. This approach can ensure satisfied clients and achieved milestones at required time; whether it is DC exit or cost reduction.
Another complication is communication with external applications, or applications that must, for some legal or technical reasons, stay behind in the old data center. Besides the fact that the network distance between the internal and external applications changes often the external interfaces or application must be reconfigured. This requires careful planning to ensure that the owners of the external applications are aware of the cloud migration program to involve them in configuration and testing activities.
Migration Waves with Target Environment Dependencies
Of course, we not only consider the dependencies between the servers, but also the dependencies of the overall migration program on related initiatives. This includes the readiness for the target environment (e.g. a new datacenter or a cloud), the services, datacenter kit, and the network connectivity is achieved in time for the planned migrations.
Migration Waves and Move Groups
Within each wave, a detailed plan composed of move groups is created jointly with the subject matter experts for the application and migration team. A move group is a set of applications that are migrated together. Often data migrations occur in the background, as storage gets replicated to the new landing zone but database upgrades or re-platforming may require database migration techniques such as backup/restore. The final synchronization and move is typically done during a low utilization period such as a weekend for critical applications.
Often a move group consists of one or more related business applications to ensure consistency of the business applications and make use of synergies in configuration and testing during migration. Additionally, this grouping reduces the risk of issues related to latency and minimizes the need for separate downtime and testing for each business application. The move groups are distributed as uniformly as possible over time to ensure there are sufficient resources, both human and technical, to perform the migration process with minimized risk.
Migration Waves Alternatives
Sometimes creating migration waves might not be the correct solution for your migration program. You may decide to do a “Bing Bang” approach — where almost all the source environment is migrated during one migration event. The justification for this decision may vary: very tight timelines to exit a DC and not enough time to migration in multiple waves, a very tightly coupled application set that is almost impossible to decompose into smaller chunks, or a very complicated network setup. Whatever the driver for this decision is, it is important to make this decision jointly with your stakeholders to highlight the risks and implications. For a “Big Bang” migration, it is imperative to document the detailed requirements and the implications and thoroughly plan mitigations including backup plans for foreseeable risks.
Appendix One: Migration Patterns: Terminology
Since the following terms are used interchangeably, here’s a definition on how they are used in this series:
Data Centre Migration (DCM) and Data Centre Relocation (DCR): Usually the same thing and represent the physical or logical relocation of IT services from one hosting location to another. This relocation could consist of a pure electronic, virtual relocation, or it could consist of everything being loaded into a truck or helicopter and brought to the new location, or anything in between. “Relocation” is associated with datacenter moves without many changes to the software, operating system and management, while “Migration” is used for enhanced transformations, such as to a managed cloud.
Data Centre Consolidation (DCC): Datacenter Consolidates consist of the Data Center Migration (DCM) or Relocation (DCR) from multiple hosting locations into fewer hosting locations, in other words a physical consolidation. As corporations grow through acquisition, this usually brings together very disparate, geographically separated workloads.
Data Centre Transformation (DCT): The process of bringing maximum standardization via technical and operational transformation, combined with maximum cost efficiency to the Data Centre through a formal program of review and technology change. These transformations last for years.
Data Migration (DM): The migration of data from one application, database or service to another, , This task can be simplified using many data replication technologies available to support such data movement such as SAN migration or image migration via Zerto. Data Migration is likely to be a component of a DCM, DCR or DCC program (Dagley, 2011).
References
US Patent Application for BIG BANG APPROACH IN DATACENTER MIGRATIONS Patent Application (Application #20190334988 issued October 31, 2019) — Justia Patents Search. (n.d.). Retrieved from https://patents.justia.com/patent/20190334988
US Patent Application for COGNITIVE CLOUD MIGRATION OPTIMIZER Patent Application (Application #20200004582 issued January 2, 2020) — Justia Patents Search. (n.d.). Retrieved from https://patents.justia.com/patent/20200004582
US Patent Application for USING COMPLEXITY PROBABILITY TO PLAN A PHYSICAL DATA CENTER RELOCATION Patent Application (Application #20160092801 issued March 31, 2016) — Justia Patents Search. (n.d.). Retrieved from https://patents.justia.com/patent/20160092801
US Patent for Configuring transmission resources during storage area network migration Patent (Patent # 10,567,304 issued February 18, 2020) — Justia Patents Search. (n.d.). Retrieved from https://patents.justia.com/patent/10567304
US Patent for Discovery for pattern utilization for application transformation and migration into the cloud pattern Patent (Patent # 10,656,918 issued May 19, 2020) — Justia Patents Search. (n.d.). Retrieved from https://patents.justia.com/patent/10656918
US Patent for Updating storage migration rates Patent (Patent # 10,599,367 issued March 24, 2020) — Justia Patents Search. (n.d.). Retrieved from https://patents.justia.com/patent/10599367
Zolotow, C., Graf, F., Pfitzmann, B., Huber, R., Schlatter, M., Schrøder-Hansen, C., & Hunt, A. (2016). Transition and transformation into a cloud environment.
