When you sign up with a supplier, it's easy to forget that you may actually want to move away one day.
This could be for many reasons: maybe because you fell out with it maybe, another supplier has become more attractive for pricing reasons or it can offer you something that the incumbent can't. How, then, do you move your cloud services from one supplier to another?
The first thing you need to do is understand exactly what you're moving. Sounds a little odd, I know, but even in a relatively short relationship it's easy to end up using various features and forgetting that you've done so – primarily stuff that's ancillary but essential such as using the provider's DNS to host your domains. I've done a number of supplier moves over the years, and have found out the hard way that the things that bite you when they get turned off are the simple but essential items like DNS, email forwarding, web page forwarding and the like – because you're already fully aware of the big items that need to move.
Do it in time
As with every project, do things in a timely fashion. If you give notice on a service, there's every chance that it'll irrevocably stop working on the termination date you provided, and you can't necessarily undo a termination (I once considered reinstating a pair of WAN circuits because of a project delay and the vendor told me: “Well, it's fine by us but it'll cost you a five-figure sum for our upstream supplier to stop the termination”). Hence you need to ensure that you have everything planned sensibly and with some contingency in the plan for delays in getting the new service up and running.
Bear in mind also that some things do take time. If you need to change the DNS servers on your domains you'll need to allow 72 hours for it to happen at the registrar's end, for instance; and if you're looking at having direct network connectivity into your new cloud provider you'll need to accommodate potential delivery delays (I ordered a point-to-point circuit between two US cities in June 2011, and it was finally delivered in January 2012 despite promises from the local telco that it would be much sooner than that).
In many cases you won't need the vendor to do anything for you, but actually sometimes you will. Say you have several terabytes of data on your existing provider's cloud and you need to transport that data to the new provider: it may be more sensible to export it to a portable disk and transport it physically instead of copying it over the Internet.
If that's the case, though, you need to be clear on what the old provider is going to give you in the way of support. The vast majority of experiences I've had in this field have been excellent – the outgoing provider has been helpful and proactive despite having every justification for conforming grudgingly and doing everything as slowly as the SLA would allow them to. This doesn't mean that your provider will be similarly inclined, though, so be clear on what they're obliged to do and talk to them up front to see if (for example) their support can be improved by paying a modest fee for a short-term escalation in support response.
Deal with design changes
There will definitely be differences between the old provider's setup and the new – even if they do extend only to the IP addresses of the Internet-facing services. You must, however, consider all the potential differences and before even coming close to a migration you must test all of your applications on the new vendor's infrastructure to ensure that there are no architectural issues to bite you on migration night.
Consider also the architecture in the old and new providers' setups. Although there are no standards for cloud services, the fact remains that there's only a handful of technologies they can be using; so if your current provider is VMware-based (other hypervisors are available!) you'll want to look to pick a similarly equipped new provider if you want to make your export/import process as seamless as possible.
Run in parallel
It's also a very sensible idea to run your applications in parallel and migrate gradually if you can; big-bang migrations generally imply downtime, and if you can migrate over time that's a far preferable approach. If you do have to go for the big bang, though, make sure you have the old and the new running in parallel because you may well have to make a "no go" decision at the time of migration and roll back to the old service.
The bottom line with changing providers is simple: think about it, test it before you leap, time the cut-off of the old service such that you can roll back if you need to, and above all time it sensibly and assume it'll over-run – because it probably will.
