Migrating a workload from a VM to the cloud involves more than just moving the VM image file to a public cloud...
storage instance. IT administrators must take planning seriously to ensure a successful and cost-effective migration.
Some of the steps involved in the workload migration process include determining suitability, ensuring compatibility, estimating costs, following cloud vendor recommendations and keeping thorough documentation. Admins should also think about what they'll do with freed up infrastructure and personnel after the migration.
Create a workload migration plan
A VM-to-cloud workload migration plan should include three major steps: determining suitability, doing the appropriate groundwork and estimating costs.
The first step is to decide which VMs can move to the cloud and which can't. Every workload has different dependencies, resource requirements and performance, and admins must evaluate each workload individually based on those factors before attempting a cloud migration.
VMs that have a lot of dependencies and high resource demands might be too difficult and costly to move to the cloud. VMs that only have a few dependencies and aren't mission-critical -- such as those that house test/dev workloads -- are good candidates for cloud migration.
Determining cloud costs isn't as easy as looking up the compute instance for the VM; there are additional costs admins must consider, such as image storage and elastic scaling. Even if a workload makes sense for a cloud migration when it comes to the technical aspects, it might not make sense from a pricing perspective. Admins should also think about the cost of migrating workloads back on premises should they need to do so.
Avoid potential compatibility issues
There are several compatibility problems that admins might encounter with VM-to-cloud workload migration, including issues with instance support, OSes, partitions and image formats. Major cloud vendors, such as AWS and the Google Cloud Platform (GCP) support a wide range of instance types, but there are always exceptions. The same goes for OSes, so checking computability is a crucial first step of the workload migration process.
When it comes to partitions, there are sometimes additional requirements that admins must meet depending on their cloud vendor of choice. For example, admins who use GCP for Linux partitions and file systems should use a Master Boot Record partition installed with the Grand Unified Bootloader. Ensuring image format capability might require admins to convert the image format or to export the VM with a compatible format.
Even if admins meet all the requirements, they should test cloud compatibility before a full workload migration.
Prepare the VM for cloud migration
Ensuring compatibility isn't the only thing admins must do to prepare for a workload migration to the cloud. Following the cloud vendor's recommendations is key to a successful migration.
When preparing to migrate a Windows Server VM to a Google Compute Engine instance, admins should enable the Remote Desktop Protocol (RDP) on the VM so they can connect to it after the migration.
In terms of troubleshooting, admins can run the bootcfg /ems command if the instance won't boot post-migration. The SOS option -- bootcfg /addsw /so -- shows drivers while they load, which makes it much easier to identify issues admins encounter. Finally, admins should check administrator accounts associated with the VM and update them if need be.
Migrating an on-premises VM to AWS requires even more preparation. In addition to enabling and allowing access to RDP for Windows VMs or Secure Shell for Linux VMs, AWS recommends that admins configure and secure user account passwords and disable automatic login for Windows VMs. Admins should uninstall any tools that might disrupt the AWS resources and disconnect local drives from the VM. AWS also recommends that admins use dynamic IP addresses instead of static.
Migrate the VM to the public cloud
Once admins confirm that their instances and OSes are compatible, meet image format requirements, and prepare the VM, they can deploy the tools needed for the workload migration, such as the Elastic Compute Cloud command-line interface for AWS.
The next steps are to move the VM image file to a public cloud storage instance, log into the console to start the instance and connect it to the necessary components. To avoid ongoing image storage costs, admins should go back and delete an imported image once they test it.
The specific workload migration steps vary depending on the cloud vendor. Some vendors, such as AWS and Microsoft, offer tools that automate, schedule and monitor bulk VM migrations to ease the process.
Whether admins choose to migrate VMs manually or select a tool to automate the process, they should have thorough documentation to keep track of where workloads live and their associated costs.
Additional workload migration considerations
Just because an admin has successfully completed a VM to cloud workload migration doesn't mean the work is done. It's important to figure out what to do with the infrastructure and staff that are freed up as a result of the migration. Any cost savings could be canceled out if hardware and admins sit idle.
One option for old hardware is to use it for new and existing application testing. Admins can also use freed up servers for long-awaited upgrades and disaster recovery. Deploying sandbox environments for new employee training is another option.
When it comes to existing staff, shifting roles and responsibilities might require admins to learn new skills. Providing training in cloud-related technologies, such as automation, containers and network microsegmentation, can ease the transition.