How to Create a Data Center or Cloud Migration Move Group Plan

Group application and system-based dependencies

Leveraging your application dependency mapping, identify all the servers, databases instances, other dependent systems and communication components for an application. Once you have identified all the dependent systems, review your mapping to determine what additional applications live on those servers and systems. Continue this effort iteratively until you have analyzed all your applications in scope. Through this comprehensive review you will have identified groups of applications and systems that should be clustered together.

If these clusters can be migrated during a move window, no further analysis may be required. If the clusters are too large, additional analysis must be completed to determine what dependencies are critical for application performance. In general, asynchronous system communications (e.g., email, FTP) are not as impacted by latency as synchronous communication (e.g., database). In organizations where consolidation and cost optimization are key, it's common to find database servers that host databases for dozens, if not hundreds, of applications. If a small number of applications leverage the database server, it will most likely be able to migrate as a single cluster. If there are many application databases on a server, they may need to be split, requiring grouping, and migrating by database or schema instead of server. In today's highly virtualized environment, this is a common occurrence and supported by most DBA's and cloud database migration tools.

Incorporate business requirements and business-critical activities

Once the technical grouping of applications and servers for migration is complete, consider your business requirements. How frequently will you migrate applications and what days and times can applications and environments be migrated? Typically, production applications must be migrated after business hours such as a weekend, and non-production is migrated during business hours, but this varies based on organizational policies. How much time do application teams need between migrating lower environments and production? Depending on the testing and documentation required, this could be anywhere from a few days to a month or more. Are some applications a higher priority for migration? Is there a business benefit to migrate an application earlier or later in the program, such as a critical application upgrade? You should also partner with the business application owner(s) to take into consideration dates or times to be avoided for specific application migrations due to business-critical activities such as end of quarter financial reporting or due to resource availability.

Manage workloads

One of the reasons migrations are scheduled iteratively in waves or move groups is because most organizations can only handle a finite number of changes at a given time. This is generally based on the number of technical resources, application team resources, vendors, and network bandwidth. How many application migrations can an application subject-matter-expert (SME) or owner handle during a migration window? This will likely vary by application, the application’s complexity, and the changes required during the migration. In addition, it's important to understand how many technical resources are available to migrate systems during a given period. Depending on the number of Windows engineers, Unix, or database engineers, you may need to limit the type of systems and databases that are migrated during each migration window. How much data must be replicated for each application, and how quickly can the data be replicated based on network capacity? Much of this can be pre-staged, however with back-to-back move groups, threshold limits may need to be considered based on available bandwidth.

Sequence applications and systems

Once you have grouped your applications and systems, identified your business requirements, and determined the quantity of migrations that can be completed in each migration window, you can create a migration schedule. It is beneficial to migrate simpler applications first before more complex ones with a significant number of dependencies. It is also imperative to migrate lower environments prior to production to fully test the migration process. If lower environments do not exist, work with the application owner to see if production environments can be cloned to run through the process prior to migrating production. While this introduces extra effort, it greatly reduces the possibility of unknown issues during a production migration. Using these principles, sequence applications and systems into move groups or waves for migration.

CTM’s Migration Wave Planning Tool

The manual process of scheduling applications and systems for migration is time-consuming and complex. Most organizations spend weeks, if not months, creating a Move Group Plan. CTM Technology Group has created a Migration Wave Planning tool to automate this process. CTM’s solution not only guarantees proper sequencing, but incorporates unlimited business requirements and move group window thresholds while reducing human errors and the project timeline!

Contact us for more information and a demonstration of our Migration Wave Planning Tool.

Request a demo