The Foundations for Successful Cloud Migration

Migrating your systems to the cloud doesn't have to be stressful.

If you're thinking of moving your organisation's IT estate to the cloud, our four-step guide contains all the information you need to lay the right foundations for a smooth and successful migration, that considers stakeholders' needs and prevents any possible headaches. 

From understanding the benefits the cloud offers your business, to the planning and preparation you need to do before you get started, to how to take the most strategic approach, here are the essentials you need to know to ensure successful cloud migration. 

Contents

Step 1: Effective Planning

Step 2: Discovery

Step 3: Defining your migration approach

Step 4: Delivering your migration plan

Effective planning ensures all key stakeholders are involved appropriately to ensure their goals and motivations for the project are understood and prioritised. We identify some of the key drivers and how these can vary across departments to help you navigate a successful planning phase. 

Technology as both push and pull reasons for migrating to the cloud

Few organisations migrate their IT to the cloud just for the sheer fun of it. They almost always have good reasons. Many are driven by limitations of current technology, for instance:

• The organisation’s existing IT estate is no longer fit for purpose:
  • Applications are running on old hardware that is no longer supported (so it’s at risk of falling over at any point)
  • Servers are running on an out-of-support OS so are at risk from malware/ ransomware attacks
  • Running out of storage capacity
  • Service interruptions because the platform isn’t resilient enough
  • Backups are failing or there’s a lack of adequate business continuity disaster recovery capability
  • The organisation’s IT infrastructure is sited in a cupboard under the stairs which isn't particularly secure. (This is a real example, not something from one of the Harry Potter books!)
• Datacentre exit – contract renewal is due and costs are excessive, creating a strong financial incentive to find an alternative
• Innovation – a product or service is being developed to provide additional capabilities and functionality that cannot easily be achieved on-premises
• Flexibility and scalability – The business is growing, and IT capacity needs to grow with it; the cloud offers the flexibility needed to expand.

The genius of the cloud is that it provides this flexibility and the ability to scale up and scale down as needed. As businesses make ever greater use of machine learning, being able to pull in additional resources at key phases, such as during training, is essential, while seasonal businesses need to be able to meet demand during peak periods. It also gives organisations access to a wide range of tools, such as AI software, that aren’t available on-premises.

Business and regulatory reasons for migration to the cloud

Sometimes migration to the cloud is driven by business and regulatory considerations. For instance:

• Financial – the organisation wants to save money
• Sustainability – as cloud platforms move towards carbon neutrality they can help in meeting CSR goals
• Compliance – regulatory compliance standards such as ISO 27001, GDPR etc are judged to be easier to achieve by storing data securely in the cloud rather than on-premises (especially where there are stipulations about data being held within particular jurisdictions)
• Global reach – the organisation is growing and wants to expand its products/ services into new markets

Clear goals inform effective planning

Above all, having a clear idea of the goals for a migration project means that these can be prioritised during the planning phase. So, if budget is the prime constraint, the project is planned with cost as a primary concern. If the key consideration is compliance, legal and security considerations can take precedence. If it’s compute power, then that can be placed top of the list.

This may be the first time your organisation has managed a migration to the cloud. However at Dootrix we help manage them week-in, week-out. We always take time to ensure that we help partners ask all the right questions and plan their migrations carefully before we start delivering their project.

Contents

Step 1: Effective Planning

Step 2: Discovery

Step 3: Defining your migration approach

Step 4: Delivering your migration plan

A thoroughly thought-out approach can help deliver a smooth transition, minimise headaches and stress, ensure business continuity and - crucially - deliver a solution that provides a robust platform to accommodate future tech developments, as well as changing or expanding business needs. 

The fundamentals of a cloud migration discovery process

Discovery provides a thorough assessment of an organisation's current digital estate. This involves identifying all the applications, systems, and data that need to be migrated and highlights the dependencies between them. 

We would normally want to know things such as what hardware does a customer have on premises? What servers does it run and what are their specs: the CPU, the memory, the storage? What applications are in use and what data do they handle? Do the servers talk to one another or are they externally focused? 

Creating an inventory of the current digital estate 

There are scanning tools available that can automate much of this task. These can help create an inventory that provides a centralised list of all an organisation's servers, and a profile of their workloads. One commonly used tool is Azure Migrate appliance, which captures workloads and provides a detailed readiness assessment ahead of migrating to Azure. Another is Lansweeper, an IT asset management tool that will, as it says on the tin, sweep your LAN to compile a list of the make and model of every item of hardware, including things like switches and routers, and every piece of software it finds on the network. 

Tools like these will provide a readout of the readiness of your servers. Some may be good to migrate as is, while others may have issues flagged; for instance some may be running old and unsupported versions of operating systems that will need an upgrade before they're ready. 

For specific applications, we will map the customer experience from start to finish, to capture information on all assets, such as the client, server, APls and data and how everything is interacting with everything else. 

Understanding the impact of specific workloads on the business

Once we have an exhaustive inventory, we will work with customers to define in greater detail the workloads that will be handled. Here are some of the questions we will typically want to ensure we have answers to:

• What is the primary purpose of the workload?
• Which of the motivations are affected by this workload?
• What is the business impact of this workload?
• Which business unit is responsible for this workload?
• What business processes will be affected by changes to the workload?
• Will there be periods during which, for business reasons, changes cannot be implemented?
• What would be the impact of downtime?

We generally allow time to spend a day or two on site with a customer making sure we have answers to the full range of essential questions. Forewarned, after all, is forearmed;  knowing as much as one reasonably can about the nuts and bolts of what one is migrating ahead of the project sharply increases the likelihood of a stress-free and relatively problem-free exercise.

Contents

Step 1: Effective Planning

Step 2: Discovery

Step 3: Defining your migration approach

Step 4: Delivering your migration plan

Picking the right option for you could well determine whether the process is trouble-free and delivers successfully on your business goals. In this third step, we take you through different models you can consider and look at how to decide which is best suited to your organisation. 

Building solid foundations for your cloud migration project

Deciding which cloud model is right for your organisation is crucial in any successful cloud migration project – but it’s not the first thing you should be thinking about. If you’re just at the start of thinking about moving your business’s tech infrastructure to the cloud, it’s worth reading my earlier articles on effective planning for successful cloud migration and the questions you need to answer during the discovery phase before you start making any central decisions. The discovery phase is essential to get a comprehensive idea of the existing workloads and IT estate, as well as the project goals and the motivating forces behind them. These will then inform your decisions about the right cloud migration approach to take.

What works will almost certainly be a reflection of the business goals that are driving the project. For example, if you’re aiming for a fast datacentre exit, you might consider rehosting; whereas if you want to drive product innovation you might look at options that involve a hybrid approach and/or mapping out a path for application modernisation.

The cloud model options

With that in mind, there are three main cloud models. You will almost certainly end up selecting one, or possibly two, of the following:

• Infrastructure as a Service (IaaS)
• Platform as a Service (PaaS)
• Software as a Service (SaaS)

Let’s go through these individually.

Cloud model 1: Infrastructure as a Service (Iaas)

With Infrastructure as a Service (Iaas) you’re essentially renting space in the cloud. Back in the day you might have rented actual servers on a server farm. Now you’re replacing the machines that you might have on-premises with capacity on other people’s machines. This is typically referred to as a ‘lift and shift’. In layman’s terms, it’s putting the trailer or house you live in on the back of a lorry and putting it down somewhere else familiar; you’re not buying a villa in Spain, learning the language and living like a local.

You’re taking your web servers, your SQL servers, your file servers – the assets we identified during the discovery process – and simply replicating them in the cloud. There aren’t any configuration changes. The only thing that changes is the networking because they're physically located in a different location on a different network. The server is identical: it's the same operating system, it's the same files inside the server, just like it was on-premises.

The tool I mentioned in an earlier post, Azure Migrate, not only does an inventory of all your assets; you can use it to migrate all those assets into the cloud pretty much with one click. Yes, there are tests you’ll want to do, failover and so forth, but the tool can even do that for you.

Pros and Cons of picking Infrastructure-as-a-Service:

Pros

• Cost effective: if you’re on a budget, it’s the cheapest option in the short term
• Fast: you need capacity or better security quickly – it’s more or less push a button and go

Cons

• Only taps into a small part of the cloud’s potential.
• Maintenance and management can be more involved

Cloud model 2: Cloud native (Platform as a Service)

Cloud native – what we used to call Platform-as-a-Service (PaaS) – involves ‘refactoring’ – the restructuring of existing code – so that, for example, systems become compatible with a new platform, without changing their external behaviours.

PaaS allows you to make use of the full range of tools available on a cloud platform. It also allows you to delegate more of the management to the cloud platform provider. So, with Azure you’d be able to use Azure App Service for your web applications and Azure SQL for your databases. Rather than manage your own virtual machines – which you’d have to deploy, configure and patch yourself – you can let Microsoft do all of that for you. This can be cost effective, given that you’re not either having to pay someone in-house or contracting out the management.

The upside is that you're reaping more of the benefits that the cloud can offer. However, there might be some development time to get your applications fully compatible with the platform and that may add to the migration time as well.

It's important to get as accurate an assessment as possible at the outset of just how much refactoring work is involved. At one end of the scale you might just need to tweak code here and there. At the other end, refactoring is a rebuild in all but name; you may end up recreating your application, more or less from scratch, for a cloud-native environment. This front-loads the project with time and expense, though in the longer term it may well prove a much better option.

Pros and Cons of picking Platform-as-a-Service:

Pros

• Access to wide range of tools
• Option of delegating system management
• Lower costs in the longer term

Cons

• More expensive and time consuming than lift and shift in the short term

Cloud model 3: Software as a Service (Saas)

Lastly there’s Software as a Service (SaaS), which will be a very familiar concept to anyone who licences and uses software in the cloud. You’re essentially getting the entire software package in exchange for a monthly direct debit.

Here your involvement is essentially limited to configuring the software product to your organisation’s needs. Microsoft 365 offers many of the software tools businesses typically use. You might already use MS Exchange Server on-premises; in this case, I’d absolutely recommend looking at Exchange Online. If your file server is pretty modest, for instance it only stores a couple of terabytes of data, you would probably be better off using MS SharePoint for departmental files and OneDrive for personal ones. MS Teams is also a great option to replace an old-fashioned phone system.

Plenty of businesses offering their own application may opt for SaaS office systems and so end up using a combination of SaaS with IaaS or PaaS.

Pros and cons of Software-as-a-Service

Pros

• Quick and easy
• Upgrades, management etc all handled by Microsoft

Cons

• Annual licenses can sometimes be more expensive than a one-off product purchase (though these are becoming rarer).

Migration approach options: in brief

Rehost - Also known as ‘lift and shift’, rehosting replicates the servers as is, with minimal configuration changes, and runs them as virtual machines in the cloud (IaaS).

Refactor – using PaaS options can cut operational costs associated with many applications. However, to be compatible with Azure PaaS services, some application development time may be needed.

Rebuild – creating a new code base for a cloud-native solution. This can maximise the capability and functionality of the application, but development is often high cost in terms of  time and effort.

Replace – use SaaS applications like Exchange for mailboxes, SharePoint for file storage and Microsoft Teams as a phone system.

Once the business goals have been identified and the approach to migration has been chosen, priorities should be defined (which applications are business-critical for instance), and that will then shape the migration plan. I’ll cover that in my final blog in this series.

Contents

Step 1: Effective Planning

Step 2: Discovery

Step 3: Defining your migration approach

Step 4: Delivering your 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:

1. What is being migrated and when?
2. What’s the impact of migrating individual workloads?
3. What risks are there and what testing will be done?
4. What are the timelines involved?
5. 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.