A successful cloud migration project could take a few weeks or many months. Working out achievable timelines and priorities to minimise risk and downtime and ensure effective adoption requires an informed, realistic and strategic plan.
In the final of our series on successful cloud migration, Alex Drake, an Azure architect in our Cloud Migration Services Team, explains how to build a robust migration plan.
The essential foundations for building a robust migration plan
There are lots of things said about planning and preparation. ‘Failing to plan means planning to fail’ – we all know that one. ‘Plans are worthless, but planning is everything,’ was one of US President, Dwight Eisenhower’s favourites. And there’s the famous quote, wrongly ascribed to Abraham Lincoln, but whose backwoods charm is infused with plenty of common sense : “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”.
The tldr version of all these is that you need a plan. But you also need to be prepared for your plan to change as the reality you’re working with changes.
Although a plan may sound like the starting point, if you’re looking to migrate your IT platform to the cloud successfully, your Migration Plan is actually the final stage in your preparation. Before you start thinking about Gant charts and timelines, you first need to have undertaken your preliminary planning, a Discovery process to map your existing IT estate, and have chosen which cloud model you are going to adopt. When you’ve gone through these processes, you’re ready to pull together your migration plan.
Key questions to ask to develop your cloud migration plan
The key questions one should normally ask to develop a robust migration plan are as follows:
- What is being migrated and when?
- What’s the impact of migrating individual workloads?
- What risks are there and what testing will be done?
- What are the timelines involved?
- What training and reskilling will be required?
It’s worth going through each of these in turn. Each of them should help you identify the information you need to establish priority orders, timelines, and additional support required to make the cloud migration a success.
Question 1: What is being migrated and when?
Projects vary considerably from organisation to organisation, depending on their size and what that business actually has on premises and so forth. In previous posts we’ve looked at using tools like Azure Migrate to arrive at an inventory of a client’s IT estate. That largely takes care of the overarching ‘What?’ however, the ‘What?’ and the ‘When?’ need careful appraisal.
Normally (and this is assuming that we’re dealing with a rehost) one would choose to start with a test group of servers. Ideally that should be a group of servers that is of sufficiently low priority that, if there’s an issue, it won’t be hugely disruptive.
Typically one would organise servers into batches and then start with the lowest priority batch; for instance any dev/test servers. The aim is, of course, that by the time the migration of business-critical systems starts, any issues will have been substantially ironed out so that the risk of downtime and the length of any downtime is minimised. In scoping out the timeline much depends on how many servers there are and their workload. If there are hundreds and hundreds, it should be possible to arrange them into sprint runs (batches).
Take the case of a recent client that has two data centres; one in the UK, one in the EU. They have a number of servers; some of them were dev/test, some of them were live. We came up with a migration plan for the client. Before we launched the migration, we set up all the networking components, because, when you lift and shift servers, you need to be able to access them and to know how other users are going to access them. If it's a web server, it's straightforward; users will be able to access them via a web browser. If it's an application that's accessed via a desktop client, users will need some sort of connectivity to it, whether that be a VPN or a remote desktop. All these issues need to be thought through.
When you have addressed these questions the next thing to ask is; ‘What servers are we going to start with?’ Experience suggests starting low level with dev servers and test servers, replicating them in the cloud. They are then tested to make sure users can access them using a VPN, a browser, remote desktop services or a.n.other method.
Having laid the groundwork, live servers can then be migrated. In this instance, we started with those in the EU as they were considered a lower priority. We worked in batches based on the workload and the priority of the workload. A server hosting the client’s main website, for example, would be categorised as very high priority; the cost of allowing that server to fall over would be very high because the client would lose money every second that its e-commerce website was down.
A key element of a successful migration is being clear about the priority that should be assigned to each of a client’s workloads and then organising the VMs into batches based on that assessment.
Question 2: Impact of migrating individual workloads
With any given workload the impact can be assessed in terms of ‘Will that application perform as well as it did on-premises?’ That is the goal. There’s also the question of ‘How do users access that?’, which relates to the networking components. You might also consider impact in terms of resolving key challenges, such as: capacity, resilience, backups, recovery and security.
Question 3: What risks are there, what testing will be done?
Risk assessment is clearly vital. There’s very little sense in walking into a migration minefield without sweeping for mines, so as part of the migration plan it’s important to identify any risks involved in migrating to the cloud and therefore what testing will need to be done.
The big risks are that, having replicated the service to the cloud, it doesn’t start up; or you start replicating and you flood the network with bandwidth; or perhaps it switches on but it doesn't perform very well. Having performed a risk assessment you should next plan how to mitigate those risks. At Dootrix, we produce a test plan document that details risks and the related mitigation measures.
When preparing a testing regime we will be asking questions such as:
‘How are we actually going to test?’
‘What are the success criteria?’
‘Who's going to perform the tests – from which teams do they come and what are they going to test?’
‘How are they going to do that test?’
An example test might be one that checks that you can access an application, that it's performing its usual functions and that it's retrieving data from a database.
Question 4: What are the timelines involved?
This is wholly dependent on the context of the migration. If it’s a few servers it could be finished in a month. If it’s a complex operation with a large number of servers that involves refactoring, it could take multiple months.
Question 5: What training and reskilling will be required?
Quite often when changes are made to operations it’s essential to ensure your people can find their way around and use the updated system.
If a company has chosen software-as-a-service (SaaS) options – for instance replacing existing applications with Teams, SharePoint and OneDrive – then retraining may be required. It’s good practice to check with the users to see if they have concerns or knowledge gaps and to work with them and their team leaders to devise an appropriate training plan.
Switching to Platform-as-a-Service (PaaS) may mean that IT administrators need additional skills and training depending on their familiarity with the cloud. This will also be set out in the migration plan.
Finally…
This really is just an introduction to the preparations that Dootrix makes with clients looking to undertake cloud migration projects. It’s important to remember that, for all the commonalities that projects share, a great deal depends on context. That’s why building a good rapport and effective lines of communications between all involved is absolutely essential. If you’re about to start your own migration journey, good luck – hopefully this series has been of some use.
Want to lay the foundations for a successful cloud migration? Get in touch
Read all of our successful cloud migration series articles:
2 – Discovery
