There are countless reference works available online (including many that I have written myself) that are designed to guide you through the process of migrating virtual machines to public clouds such as AWS or Microsoft Azure. What isn’t nearly as common, however, are resources designed to guide you through all of the post-migration tasks that need to be completed. That being the case, I wanted to take the opportunity to talk about some of the things that you may need to do after migrating virtual machines to the cloud.
Before I begin
Before I get started, I wanted to quickly mention that this article is by no means comprehensive in its scope. Every virtual machine is different and therefore has its own unique needs. My goal, therefore, is to discuss some of the more commonly required post-migration tasks.
Test RDP
The very first thing that I recommend doing after you have migrated a virtual machine to the cloud is to make sure that you are able to RDP into the virtual machine (or use SSH if the VM is running Linux).
Granted, management tools exist that allow virtual machines to be managed without resorting to the use of RDP. For instance, you might be able to use a web console to manage the VM’s application, or you might be able to use the Windows Admin Center to manage the virtual machine’s configuration. Even so, it’s important to be able to connect directly to the virtual machine’s console in the event that you need to perform a repair or maintenance task that can’t be done through more conventional management tools.
Security software
Most of the virtual machine migration tools that I have worked with require you to disable the virtual machine’s antivirus software, as well as other security software such as intrusion prevention systems. Obviously, you don’t want to leave these sorts of things disabled, so make sure that you make it a point to turn them back on once the migration process is complete.
While you’re at it, make sure that the security software is still able to function with the virtual machine running in the cloud. My own personal experience has been that security software running within a cloud-based virtual machine generally does continue to do what it’s supposed to do, but there are sometimes problems with external connectivity. A while back, for instance, I migrated a virtual machine to the cloud and re-enabled its antivirus software. Although the antivirus software continued to scan the virtual machine for malware just as it always had in the past, it was unable to send reporting data back to the centralized management console used to monitor all of the virtual machines. These are the types of things that you need to be on the lookout for.
Check the time zone
One of the easier tasks to forget about is to adjust the virtual machine’s time zone as necessary. Migrating a virtual machine to the cloud can sometimes cause the virtual machine to reside in a different time zone than it did before. For example, I live in the Eastern time zone, but I have a few cloud-based virtual machines that are running in West Coast (U.S.) datacenters.
In most cases, forgetting to tell the virtual machine’s operating system that the VM is now located in a different time zone doesn’t do any harm. At the same time, though, having an operating system that is configured to use a time zone that doesn’t match where the VM is actually located can cause confusion with regard to monitoring and audit logging.
Test DNS name resolution
Another thing that I recommend doing following the migration of a virtual machine to the public cloud, is making sure that DNS name resolution still works as it should.
When you move a virtual machine to the cloud, that virtual machine is going to be connected to a different subnet than it was before. At the very least, this means that the virtual machine’s IP address is going to change. If the virtual machine is configured to use DHCP, then there is a good chance that the DHCP server will also cause the VM to use a different DNS server for name resolution queries. This isn’t a problem if the VM only ever needs to do Internet DNS queries. It is a problem, however, if the VM needs to be able to resolve names on your own network.
Typically, when I migrate a virtual machine to the cloud, I like to perform a series of ping tests. First, I will try to ping a well-known website. If that ping succeeds, then it means that the virtual machine is able to communicate with the Internet and that DNS name resolution is working for Internet-based domain names.
The next thing that I like to do is to ping an IP address on my own network. That way, I can make sure that the cloud-based virtual machine has a valid communication path to the resources on my network. Assuming that this ping succeeds, I redo the ping test but this time I use the resource’s fully qualified domain name instead of its IP address. This confirms that DNS name resolution is working for my private network.
Many tasks remain after you migrate virtual machines to the cloud
There are countless other tasks that may need to be performed following a cloud migration of a virtual machine. A few such tasks might include modifying backup jobs to point to the virtual machine’s new location and removing references to the virtual machine from the on-premises virtual machine inventory. In some cases, you might also find that you need to install a new management agent onto the virtual machine to make it work in the cloud environment, or you may need to remove certain components from the virtual machine (such as the VMware tools).
In any case, it is critically important to thoroughly test a virtual machine after migrating into the cloud before you perform a cut over to allow the virtual machine to begin handling production workloads.
Featured image: Designed by rawpixel.com / Freepik
