Moving data between clouds is a new yet real concern I have heard from many customers. Even though they are just getting started with putting applications and data in the cloud, they want to make sure that if business needs change or a vendor has issues, they can move their data to another cloud provider with minimal effort. Now this only really becomes feasiable if those applications are running in VM or in guest and you are not consuming cloud provided services. Some cloud servers are generic enough but if you are moving databases you may find some level of incompatibility between cloud vendor offerins. So that is the first major prerequisite to doing a move with the least amount of headaches. There are 2 major approaches to moving data between clouds, using a backup & recovery solution or using a migration solution.
Backup & Recovery (B&R) Apporach
Using your B&R software tends to be the easiset appraoch as you are already using it to protect the machines in the cloud. There is one cavaut to this approach that may cause issues which is removing the cloud vendor vm services if you want to do a full machine recovery. The cloud providers inject their own drivers to optimize deployment, updates and other services they offer. When you backup the entire instance you can get that additional data which can cause a restore to fail when you are recovering to a different cloud provider. In most cases doing file based protection will allow you to exclude the proprietary cloud components and get the necessary system files.
The Migration approach
Utilizing a migration solution (software or hardware based) is another approach to take into consideration when you are moving between platforms. Migration solutions (at least the good ones) will have the ability to migrate and convert data so that you can move your applications and data between clouds in small chunks or all at once. They take into consideration bandwidth, security and infrastructure changes so you can start the migration of data while the systems are active and then during say a maintenance window complete the migration and cut over to the new instance in the new cloud environment
Idealy you want to choose the best path based on your configuration and applicaiton SLAs so that you complete the process in a timely manner and avoid any unexpected and costly downtime (what we call in IT "resume generating events").
Thanks, Ralph that's a great answer to open the discussion.
I would like to step back and think about what happens when you go to build an application.
I like to say it like this: every application needs a way of persistent information, and ultimately that is delivered through a database. So, every application needs a database.
If you step back again and say, every application needs some sort of identity management. You need a way of controlling who can log on to the application, to what things he or she has access.
Next, well every application requires some form of notification or messaging. I think you get where I am going with this.
So, if you start thinking about it and think an application needs all of these building blocks to function. Each of those decisions carries a long tail of operational commitment.
Now let's go back to the database. You're going to pick Oracle or SQL, or you're going to pick some of these new modern databases like Cassandra, CouchBase, or MongoDB. That single decision has now committed you to a lifetime of support of a database plus all the other pieces of things. So, if you decide at some day to migrate your application then you also must move all these dependencies and in the right order too.
This is the hard stuff.