(For more resources on this subject, see here.)
While planning is of course the first step, this is something that any IT shop should not take lightly since this is the step where you decide what vendor to go with. All cloud vendors have snazzy marketing material that tell you how seamless and highly functional a migration will be, but that simply cannot always be guaranteed. How many times have you been sold on a technology in the past that did not live up to expectations? It happens more often than you think, and it is part of the overall sales process by these companies.
Instead of relying on their word, you could consider a few options. One would be to work with a company you have experience with. If you’re familiar with working with Microsoft, go with their Azure platform. If you’re already using Salesforce to some degree, continue to talk with them about a more full-scale migration. If you’re planning on working with a non-traditional vendor such as Amazon or Google, ask for references or do a bit of investigating on your own. You might learn a thing or two.
Keeping data secure is of course very important, and it’s wise to make an assessment of your security prior to any sort of large-scale migration. Performing audits and stress tests are a great way to make sure that your organization and/or system is ready for a large scale change.
The unfortunate reality to any sort of migration is that there are inevitable vulnerabilities to any large scale process such as this. With that being said, the more you know about your strengths and weaknesses prior to a cutover, the better off you will be. Any sort of large project is sure to experience bumps in the road, and you might as well prepare yourself for uncomfortable findings prior to commencement.
At this point, you’ve already made some critical decisions, but hopefully you’ve reached a testing stage where you will be able to take a look at more than one provider for assessment of what they can do for your organization. Having the redundancy to fall back on a "plan B" in case one provider doesn’t work out is ideal. You may not have that option depending on your particular deployment, but again it’s a more productive scenario.
After the testing point, you’ve reach deployment. If the planning, security and testing phases have proven to be successful (at least optimistically so) you’ll probably realize that cloud deployments require more re-engineering and code changes than any vendor is willing to tell you. Moving an environment outside of your own hosted space takes a lot more in-house development than most people realize.
In the long run, however, cloud services are beneficial to both the vendor and the customer. What headaches that go into cloud migration usually pay off over time. Perhaps 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 clearly makes all the hard work required worth. Perseverance is key, and in time it’s easy to see the overall benefits.
- Hands-on Tutorial for Getting Started with Amazon SimpleDB
- Ground to SQL Azure migration using MS SQL Server Integration Services
- Microsoft LightSwitch Application using SQL Azure Database