The cloud is something you can’t escape at the moment; everyone seems to be talking about it while more companies are now considering it as a viable alternative to running their own infrastructure.
However the idea of migration to the cloud and how you will manage moving all your data or applications over is a major concern for many. There is still little information available to guide you through the process of performing a ‘cloud cutover’.
As with most data migrations you can break this down into four stages and I’ll go through each one to look at what you need to consider during each stage.
Planning is the first step in any project and it’s no different with data migration into the cloud. It’s also a step that shouldn’t be taken lightly. You need to start by deciding on the cloud provider you will use. You should consider a few providers and it can help to focus on technology you’re already familiar with.
Once you’ve decided on a vendor it is worth asking them, or researching, how you can transfer data across. If you’ve gone down a more Platform or Software as a Service route then there may already be applications the provider can supply that will migrate data from common sources such as your database application or CRM. If you’re using an Infrastructure as a Service provider then you will probably need to manage this process yourself and plan how to replicate your current applications.
Realistically, with any sort of migration there are vulnerabilities in a large scale process and you probably won’t catch them all. Having said that, some of things you need to consider before your migration are:
- Security of the data you are migrating during ‘transport’. Whether you are shipping drives or using a VPN you need to look at how you will keep that data secure during migration.
- Integrity of your data during replication. If you are already operating a high volume, transactional database then you’ll already be aware of the issues around data integrity and consistency. These are still true when migrating data to the cloud, and at some point you have to move your applications over to the new data which needs to match the old data.
- One way of achieving this is to do a full replication of your dataset before the move (this could be shipping hard drives to your cloud provider to restore), then running the two datasets in a mirrored format, ideally over a private connection into the provider, and then once you have both running in parallel, switching your applications over.
- Fall back positions. This is needed in all projects, especially large scale systems migrations. There needs to be a firm cut-off point for the migration whereby if you haven’t reached a certain point (e.g. data migrated and systems repointed) then you revert to how the systems operated originally. This ensures that the services are always available, you don’t over-run your maintenance window and it gives you time to find out what went wrong (it’s much easier to diagnose a problem at 2pm in the afternoon than it is at 3am when you’re in the middle of the move.)
Once you’ve completed the migration to your new provider you need some time to test the systems. This can be a combination of user acceptance testing, stress testing and systems acceptance. Here you ask the users to confirm that everything is working as expected; test the systems to ensure they perform as the provider promised; and lastly sign-off that you are happy with the new provider.
With that done it’s time to repoint the ‘live’ applications, then shut-down the old systems and decide what to do with your old hardware.
Cloud services are beneficial to some, but not all, businesses and applications. For those where a cloud provider is suitable, the headaches that go into cloud migration usually pay off over time. You might not see the immediate benefit, but once a deployment is successful, the amount of time and money that is saved by adopting a cloud strategy should make all the hard work worthwhile.