Featured article by Bluelock
Migrating your application isn’t something that you decide to do on a whim one day. A successful migration requires a careful plan, expertly thought-through and prepared. This checklist isn’t meant to serve as your diagram for migration, but rather it’s meant to help guide your plan before it’s crafted and also to service as a final pre-launch list to make sure you have haven’t forgotten anything before takeoff.
Depending on what you’re migrating (VM, application, or just data), you may or may not need to address every single one of the following check boxes. Each best practice is annotated with which aspect of the stack you should pay special attention to in regards to the best practice.
The following ten steps should be considered as part of any migration to an infrastructure-as-a-service (IaaS) solution. Whether moving from physical to virtual, private cloud to public cloud or even public cloud to public cloud, don’t forget any of these crucial steps on your journey to success. Note, if you are migrating to PaaS or SaaS, there would be other considerations.
#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: Assess 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.
