5 things to do when migrating cloud
In technology Change = Risk however what is sometimes forgotten is there is also a level of risk attached to remaining with a provider who has delivered a service that didn’t meet your expectations. For many cloud customers it isn’t just outages that erode the trust of a customer. We win a number of accounts where the previous provider had excellent uptime statistics. The reasons for a move between private cloud providers are often attributed to:
- a reactive approach to support
- a lack of communication
- lack of visibility into the environment (monitoring)
So lets assume you have selected a good cloud provider and are ready to move from your old provider. For the sake of this article I am assuming that the environment is reasonably complex, say a two or three tier architecture. While it difficult to manage the risk of a move down to zero, with a proper migration plan its possible to get that risk down pretty low.
Some steps to consider:
1. Determine if your old cloud provider will be helpful. It is technically possible to do a complete migration without the help of your old provider, however this does make things more difficult. I have been involved in a number of projects where the customer simply did not want the incumbent advised they were moving through a fear they may wish to sabotage something before the migration is complete.
2. Build the team responsible for the migration and set up a recurring weekly meeting. In my experience migrations get more complex not less complex as the move progress so a weekly meeting is defiantly definitely not overkill. The team would normally consist of:
- The technical and commercial buyer at the customer end
- The presales engineer, sales person, account manager and solution architect at the new provider
- A representative from the old provider if possible
3. Create a list of actions to occur. Some actions can be completed concurrently others may have dependencies. This is an example but it is far from exhaustive just an example of some of the steps. Once the list is created attach roles, responsibilities and deadlines.
-Backup website app layer
- Backup the user databases on the source server
- Outline a roll back strategy
- Determine if an outage needs to occur and if so for how long
- Note any configs of current working operating systems and any server side objects installed
- Determine strategy for email – will you use an existing Exchange server or are POP/IMAP accounts with the old provider
- Restore the user databases to the destination server
- Transfer logins and passwords
- Familiarise yourself with the reporting and management interface of the new company
- Set an outage window and notify customers if required
- User acceptance testing
- Prepare for the DNS change - you may be using as many as four different groups for domain registration, domain hosting, email hosting, and web hosting, make sure you know which function is handled where
- Change DNS to point to your new web host
- Wait for the DNS change to propagate through the net (alternatively changing the DNS to the new host while pointing the A record of the domain back the previous provider may negate the need for a lengthy propagation as you can just change the A record to the new host when it is time to go live)
- Ask the old provider to remove any zone records associated with your domain name so avoid conflicting records – you may also use this opportunity to announce you have left and complete whatever cancelation form they may have
4. Complete an official handover with the new provider. We do an external handover to the customer and also do an internal handover to our service assurance team to make sure any IP in the presales engineer or BDM isn’t missed. Ask your provider if such a process exists.
5. Review the move. Understand how you will measure the success of the move. Is it uptime, incident response times or speed.
Good luck with the move and don't be shy in asking your new cloud provider for an overview of lessons they have learnt with previous migration projects.