10 Best Practices for Migrating Applications to the Public, Private or Hybrid Cloud

#1 Determine any changing OS or app licensing provisions

Depending on where you are migrating your application to, 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 that you are migrating to 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.

#2 Asses your application’s Data Gravity

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 of equal to your bandwidth, your migration will likely fail. That’s because the rate of change refers to everything coming in to 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, or migrate. You need a high enough bandwidth to “overtake” that rate of change.

#3 Understand how your application is connected to other applications

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, though.

#4 Do judge an app by its Disk Format

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.

#5 Network Services: Firewalls, Load Balancers and IPS

Whether it’s compliance or app scalability, moving to cloud means you’ll have to use whatever network services that 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. And, be sure you are able to convert the data that you already have to the cloud provider’s format.

#6 Software services updates required

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, but your software services still need to be reassessed going from private physical to private cloud, cloud-to-cloud or physical-to-virtual.

#7 Backups are an app’s best friend

Enterprises are used to a certain level or grade of backup policy. Those policies will be different in the cloud, so before migrating you will need to 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.

#8 Prevent lock–in before it’s too late

The general rule of thumb is to make sure that if you put your data somewhere that you still own the data. And, 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.

#9 Connectivity is important

Like we mentioned before, 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 SLA.

#10 Do your P2V homework

When moving specifically from a physical system to a virtual system or a physical system to the cloud, you should always follow 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 back-up software for your physical system. This should be done BEFORE the migration.