Migrating Critical Applications to Virtual Servers: 10 Best Practices

By Chris Preimesberger

Depending on where you are migrating your application, you may need to reassess the licensing requirements for both your operating system and your application. This will apply when you are migrating the entire stack, the OS and/or the app. Make sure the location to which you are migrating supports running what you have. Bigger cloud providers may require different or special licensing according to their model. Take a look at your end-user license agreement to confirm any special scenarios or circumstances.

Data gravity will apply regardless of whether you are migrating the whole stack or just part of it. To assess the data gravity of your application, calculate the rate of change. As a general rule, if your rate of change is greater than, or equal to, your bandwidth, the migration likely will fail. That’s because the rate of change refers to everything coming into the app; it’s gaining gravity as the rate comes in. The bandwidth is like the escape velocity it requires to get off the ground to migrate. You need a high enough bandwidth to overtake that rate of change.

Few apps are an island. Before you choose the application to migrate, check the coupling and connectivity of your application to other applications. Migrating “App A” may require migrating closely coupled “App B” and “App C” as well if they won’t be able to handle the increased latency from being pulled apart. There’s no magic formula for assessing this checkbox; just knowing your architecture, how everything connects and how closely those apps need to be coupled to run efficiently is key to a successful migration.

When migrating entire VMs, your disk format may need to be converted as you move from one cloud (or system) to another. AWS uses AMI, which is different from VMware VMDK, which is different from Microsoft VHD. Be sure you have converter tools and know how to do the conversion if you’re migrating entire virtual disks.

Whether it’s compliance or app scalability, moving to the cloud means you’ll have to use whatever network services your cloud provider has available. If you’re required to have an intrusion prevention system (IPS), make sure that your security vendor or your cloud provider has something for you to use. Be sure you are able to convert the data that you already have to the cloud provider’s format.

This includes OS/app patching and antivirus. However you’re doing these currently will likely need to be revisited for how you will check these off in the future. The tools and procedures you currently use and have documented will need to be updated. That’s true not only if you’re migrating to a new cloud, as your software services still need to be reassessed going from private physical to private cloud, cloud to cloud or physical to virtual.

Enterprises are used to a certain level or grade of backup policy. Those policies will be different in the cloud, so before migrating be sure to update your procedures and be ready for change. Your provider may have recommended best practices and/or unique options available based on the location to which you are migrating.

The general rule of thumb is to make sure that if you put your data somewhere that you still own the data. That place should be somewhere that you are able to exit at any time with your data. More than just the data, this should also apply to things like configurations, performance statistics and other metadata that could be useful if and when you leave the provider. Always have an exit strategy because you never know when you will need it.

As stated previously, few apps are an island. It’s rare for enterprises not to have some sort of private connectivity to their cloud provider. Different cloud providers may have different connectivity options and restrictions available. Make sure that your new provider has the level of connectivity that you require. If the connectivity is particularly important, make sure it’s part of the service-level agreement.

When moving specifically from a physical system to a virtual system or a physical system to the cloud, always follow physical-to-virtual (P2V) best practices. This means reading up on any software tuning that needs to be done and removing any legacy software that pertains to the physical world. Don’t forget things like battery backup software for your physical system. This should be done before the migration.