Best Practices for Migrating to the Cloud

Featured Article by Jake Robinson, Solutions Architect at Bluelock

As an Infrastructure-as-a-Service provider, Bluelock sees a lot of migration of applications.  Migration is occurring from physical servers to cloud, from private cloud to public cloud and back to private cloud from public cloud.

Migration can be tricky and a poor migration strategy can be responsible for costly time delays, data loss and other roadblocks on your way to successfully modernizing your infrastructure.  And, while each scenario is different, I’d like to identify two key best practices that will help your team create a solid, successful plan for migrating your application.

• BEST PRACTICE: Understand the gravity of your data and the connection of your apps 

When moving tier one applications from a physical datacenter to a private or public cloud, we have to take data gravity into account, because it will impact the migration. The most difficult part of the migration is the data, however. There’s no easy way to shrink down the data, so you need to evaluate the weight of the data in the app you’re considering migrating. Especially if you’re a high transaction company, or if it’s a high transaction application, there would be a lot of data to replicate.  The data of the app constitutes 99% of the data gravity of the application.

Another aspect you should evaluate as part of your pre-migration plan is to determine how connected your VM or vApp is to other apps. If you have a lot of applications tightly coupled to the application you want to migrate, the cloud might not be an option for that application, or at least only that application. Does your application have data that other applications need to access quickly? If so, a move all or nothing philosophy is your best option.

If you have an application that is tightly coupled to two or three others, you may be able to move them all to the cloud together.  Because they are still tightly coupled, you won’t experience the latency that would occur if your cloud-hosted application needed to access a physical server to get the data it needs to run.

The final part of this series gets down to the nitty gritty… choosing the correct migration strategy.

• BEST PRACTICE: Pick your migration strategy.

Your best-fit migration strategy will be a function of the features of the application. Option one is data migration of just the data. This is typically the correct choice for tier 1 and 2 applications.

Let’s say you are able to migrate your VM or vApp.  But, it’s constantly changing and if it’s a tier one application, you may not be able to afford a lot of downtime. Typically, you’ll have to invoke some sort of replication. Replication is an entirely separate subject, but when I think of replication, I think of the size of the data, the rate of change and the bandwidth between our source and target.

Without going into too many details of replication, let’s assume you use some sort of SQL or MySQL program for database replication. What you’ve done is set up your new cloud to have this OS provision.  You’ve got a MySQL provision and the two SQLs are talking to each other and replicating the data.

Option two for migrating your application is machine replication.  This is best for tier 1 and tier 2 applications that can afford some downtime.  It involves stack migration.  There is less configuring in this scenario, but there is more data migrating. Option two is best if you’re moving to an internal private cloud.  You’ll be able to replicate the entire stack, because you have plenty of bandwidth to move stuff around. It’s important to note the portability of VMware, because VMware allows you to package the entire VM/vApp, the entire stack, into an OVF. The OVF can then be transported anywhere if you’re already on a virtualized physical server.

Option three involves cold P2V migration. You typically see this for tier 2 and 3 apps that are not already virtualized. The concept involves taking a physical app and virtualizing it. VMware has a VMware converter that does P2V, and it’s very easy to go from a physical to a private cloud using it.  It is, however, an entirely different set of best practices. In option three, there is no replication.  Those apps can also be shipped off to a public cloud provider to run in the public cloud after being virtualized.

A final path some companies take is to treat it as a Disaster Recovery (DR) scenario.  Setting up something to do replication from the physical from one machine to another.  Replicate the entire stack from point A to point B, and then click the failover button.

Each application, and migration strategy, is unique, so there is no detailed instruction manual that would work for everyone.  The best strategy for some applications may be to stay put, especially if you find that in steps one and two of pre-migration evaluation is closely connected or especially weighty.  To truly enjoy the benefits of cloud, you want the right application running that you can leverage to the fullest extent.

Jake Robinson is a Solutions Architect at Bluelock. He is a VCP and former CISSP and a VMware vExpert. Jake’s specialties are in infrastructure automation, virtualization, cloud computing, and security.