Static versus dynamic cloud migration

It’s 9:00 AM on a Wednesday. You’re in the boardroom giving a status update on the latest migration project that will remove most of the vulnerabilities found during the recent pandemic. This is the third migration project, all less than 100 workloads and 10 data sets. All have taken place in parallel, and all leverage different cloud migration teams.

Company leadership notes that the metrics were very different between the projects. Project One shows nearly 80 percent efficiency in terms of code refactoring, testing, deployment, security implementation, etc. The others were closer to 30 and 40 percent. Why the differences? 

Most efficiency issues arise from dynamic versus static migration approaches and tools. Most people who currently do cloud migrations gravitate toward the specific processes, approaches, and migration tool suites that worked for past projects. This static approach to cloud migration forces a specific set of processes and tools onto a wide variety of migration projects and problem domains. The misuse of specific processes and tools as generic solutions often leads to failure. 

Core to this issue is our drive to find a specific suite of tools and technology bundles that the industry considers best-of-breed, and our desire to leverage best practices. We in IT love to follow the crowd: “I read about these tools and this approach that worked for Joe and Jane and Bob at companies kind of like mine, so they’ll work for me, too.” We make the erroneous assumption that we remove risk by not making our own choices, even if the choices are situational. 

As an expert in this field, I would love to list a standard set of migration tools that will address everyone’s needs—code scanners, configuration management, continuous integration and development, testing tools, and more. But the real answer is that your selections of tools and approaches must be based on the requirements of the applications and databases you are migrating to public clouds–or any other platform, for that matter. 

The project criteria and review processes for migration projects typically include, but are not limited to:

• “As is” platform assessment
• Application assessment
• Data assessment
• Configuration management plan
• Security migration tools
• Governance migration tools
• Refactoring and redeployment
• CI/CD
• Testing and deployment
• Cloudops/IT operations
• …and more.

The tool categories listed above will have different solutions based on the “as is” and “to be” platforms, development approaches, and databases used, as well as the identified storage, security, and governance requirements. Although a one-size-fits-all approach might work, it will rarely provide the promised efficiencies and could actually derail the entire project if the approaches and tools are too far off. 

My message here is that you need an extra step in the process. Select the tools and approaches based on what you want to move, where it needs to go, and the attributes it needs to have upon arrival. Almost always, this will drive the selection of a different set of tools for each migration project.

The bottom-line message is that the same tools and processes can rarely be reused with optimal results from one migration project to the next.

Now it’s time to hear about the exceptions. To take advantage of these exceptions, there needs to be centralized command and control of all migrations, such as a center of excellence where problem patterns and solutions during each migration project can be documented. With centralized command and control (CCC), your own best practices will emerge, and they will have a much higher likelihood of working in future migration projects. 

This is the point in the overall enterprise migration where some tools and processes can begin to be reused. CCC needs to become part of the process when teams initially identify migration targets and begin migration plans. It should be CCC’s duty to compare and contrast planned migration projects with past projects. If CCC can recommend approaches, tools, and processes that worked for previous migrations with similar attributes, you will never need to reinvent the wheel. 

It’s a hard lesson to learn. The silver lining here is that even if one size rarely fits all, a few sizes can often fit most. As always, the key to success is to do your homework at the beginning instead of the end of a project, document everything, and make that documentation easily accessible to help plan future projects.