Part Three: Best Practices for Migrating from a Physical Datacenter to the Cloud

January 31, 2013 by Diana Nolting

 

We covered data gravity in part one of migration strategy best practices, and we covered connectivity of apps in part two of migration strategy best practices.  The final part of this series gets down to the nitty gritty… choosing the correct migration strategy.  In today’s blog post we’ll cover three types of migration strategies and we’ll touch on replication as well.  

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, we may not be able to afford a lot of downtime,” Bluelock Solutions Architect Jake Robinson explains.  “Typically, we’ll have to invoke some sort of replication. “

“Replication is an entirely separate subject,” Robinson states, “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.” Robinson explains.
“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 will be able to replicate the entire stack because you have plenty of bandwidth to move stuff around,” Robinson explains. 

“It’s important to note the portability of VMware,” he adds.  “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,” Robinson explains.  “VMware has a VMware converter that does P2V, and it’s very easy to go from a physical to a private cloud using P2V.  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 DR scenario,” he explains.  “Setting up something to do basically replication from the physical from one machine to another.  Replicate the entire stack from point a to point b, then click the failover button.”  

There are a lot of options for migrating your application, and likely your team still has some specific questions.  We invite you to leave your questions in a comment of this post and we’ll work to tackle those in future blogs.  Or, reach out to Bluelock on twitter @Bluelock, or Jake Robinson on twitter @JakeRobinson.

 

Images courtesy of http://www.sxc.hu/.