At Version 1, we have seen steadily growing interest in technology workload migration to public cloud across both public and private sectors in recent times.

Customers are often facing a compelling event such as data centre renewal/contract expiry or the need to address legacy and heritage architectures – or very often a mix of both. As customers look to optimise or reduce costs, or indeed establish a basis for ongoing change and gain benefits, public cloud is increasingly considered to be the default or larger part of the answer in these scenarios. The problem for many, however, is how and where to initiate and deliver these activities and outcomes 

So, is there a migration market out there?

The public cloud migration market certainly is strong and growing currently – and leading cloud vendors are recognising this. In July 2020, Andy Jassey, (former chief executive of Amazon Web Services (AWS) and now CEO of Amazon stated), “Migrations are a top priority, next only to the security and operational performance of the AWS platform”. Both Microsoft and AWS have targeted migration programmes, specifically to encourage customers to migrate and provide a wealth of materials through their cloud adoption frameworks to support such endeavours. 

To reinforce this view, there are market anecdotes about the state of uptake of public cloud. The Flexera State of the Cloud Report 2021 specifically asks about top migration challenges organisations face, with the understanding of application dependencies being considered as the primary and biggest migration challenge. They also found that 59% of organisations surveyed plan to focus on cloud migrations. Further evidence of the potential of the migration market can be seen in stats from where they show growth from $119.13bn in 2020 to $448.34bn in 2026 (a Compound Annual Growth Rate of 28.89%). In addition, Gartner predicted continued growth of worldwide public cloud revenue back in 2020 with 6.3% forecasted growth in 2020 and its 2021 latest prediction on over $480bn of spend in 2022, a 21.7% growth. (source: Gartner Press Release.) Gartner also states in their IT Roadmap for Cloud Migration, 2020 that:

Migrating large amount of workload from on-premise data center to the public cloud requires careful planning ….. and many IT leaders don’t know where to begin.

Are the challenges real? 

The challenges are real but not insurmountable. As mentioned, the State of the Cloud Report profiles the top migration challenges and of these top 10, over half include references to “Understanding app dependencies”, “Accessing technical feasibility”, “Assessing on-prem vs cloud costs”, “Knowing implications of BYOL”, “Prioritising apps to migrate”, ”Migrating the app and data” and “Selecting the right cloud provider”. Of key importance is that most of these can be said to be in the planning and preparation of any migration – not in its execution. 

In our experience, most customers struggle to understand the scope of what they actually have to migrate. This issue is further compounded as the IT estate scales to hundreds or thousands of servers, virtual machines, and applications. This appreciation of what they have, in order to understand what to do with it – and address those top challenges in any cloud migration is therefore at the core of a successful migration. As a suitable analogy if you employ a removal company when moving to a new house, you are unlikely to get a realistic idea of cost and time unless you can tell them the size of house, number of rooms and at least an approximation of the items being moved – and identify those items of high value. In some way, any migration to public cloud can be thought of in similar terms. 

What makes a successful public cloud migration?

Version 1 is a veteran of many public cloud migrations and here we share some of our top tips on what makes any migration a success – and you will see here that this starts before a single Virtual Machine or Server has been moved. 

Discover, Discover, Discover!

Appropriate discovery of the estate to be migrated is key. As we previously highlighted, to move something, you need some appreciation of what you have to move. We recommend time is spent up-front establishing the scope, challenges, and existing technology that you will be dealing with during the migration.  

Automate as much as you can

These days, discovery can be supported by several tools from both the public cloud vendors and 3rd parties. Some will come free and some with a cost. When running a discovery at increased scale, tooling becomes much more important to be able to assess large volumes. However, it also should be noted that deploying tooling can present its own challenges in highly managed customer environments – time to approve and deploy (particularly when you don’t have that time – as many customers face impending deadlines or resistance to introduce tools to managed or sensitive workloads). In such circumstances you need to think out of the box – you need to look at how you can gather data in other ways from information already present e.g., do you have a CMDB (Configuration Management Database) – that might be a good place to start, or can the hypervisor be interrogated to extract data on hosted VM’s and so on. Also remember that not all things can be automated – tooling will not necessarily capture compelling events, plans for investment or operational issues – all of which may influence the following analysis and profiling. Be prepared to invest some time and effort plugging any gaps. 

Analyse and Profile

When you have gathered all the data, you will have an inventory of your servers and virtual machines, you may also have your list of applications and components and some view of dependencies. Now what? Well, decisions need to be made – to do that and do that at scale, you need to profile this data. This can take various forms and may be driven by your compelling event or objectives. For example, a very simple way of profiling is to apply a RAG status to your VM’s, or servers based on operating system / platform. 

Some older operating systems may not be endorsed on cloud – or indeed not supported by a given vendor. At scale you can quickly mark these red and others green. Soon to be out of support operating systems may be marked amber depending on your definition. Many other ways to profile the data exist and this is just an example – but hopefully you get the idea. However, do not under-estimate the power of facts based on actual data – there are many senior stakeholders and budget holders who will be glad to see hard facts, figures, and evidence on what they are dealing with and the challenges ahead. 

Might you need to plan ahead?

Once you’ve gathered the data, you’ve profiled it and completed analysis. Then what happens next? This is the point that you need to start planning how you might tackle the migration. This activity also includes assessing what migration pattern to use (and this may be application or workload specific), what resources will I need, how should I structure my migration project or programme – and so on. Planning should be considered an important stage to set out the relevant roadmap, based on what you have found. This provides clarity in terms of effort, cost, and risks to be managed throughout the execution phase. Pilots and Proof of Concepts may also be a relevant outcome of this step – or indeed you may find that you need a further deep-dive on key workloads, applications, or group of servers to derive additional context and information. 

But remember, all the above is the beginning, not the end 

Having said all the above, it is important to keep in mind that preparing for migration is just the beginning of the journey. Any discovery and planning stage should be time or resource boxed and should conclude quickly and provide early visibility to stakeholders. Avoid analysis paralysis – make decisions and move on. We never see discovery as a project in its own right, it is there to facilitate the onward execution, where much of the real work and detail will take place.  

Do just enough, not too little, not too much

One common trap of migration preparation is viewing it as an enterprise architecture current state capture activity. On the flip side, getting the output from a discovery tool (e.g., list of VMs) and calling it a day at that point might also not quite get you where you want to be. 

In any migration it is important that you do just enough to get where you need to be. Preparing for migration is not a root and branch review of everything – and indeed at scale can become an impossible task. However, it should also not be glossed over as an easy transactional step. One analogy I like to make relates back to the State of the Cloud Report and the no 1 migration challenge – that of understanding application dependencies. A common trap for any migration is attempting to catalogue every single integration that exists – at scale this can be a mammoth task unless you have a ‘here is one I prepared earlier’ interface catalogue. 

If you do have one then great, use it. If you do not have one, don’t try and boil the ocean either – in this example, you might look to understand broad dependencies over individual interfaces e.g., knowing application A has a dependency on application B is often enough. It is not necessary to know that consists of several dozen interfaces or data flows, volumes, frequency, and so on. 

Finally, remember what you are trying to address!

As it is easy to become overwhelmed by data and its related analysis throughout this process, it can be easy to forget what your original remit is or was. We have found that, for many customers, their strategic compelling event such as a DC exit deadline can often get mixed with (for example) real operational issues or critical systems that may be due for investment according to their own timescale. It is important therefore to keep sight of your original organisation’s priorities and don’t make assumptions about them.

Not all workloads may be lift and shift, as you may find good reasons to look at different migration paths or even look to completely replace an application with a new cloud native approach. These options are valid if there are good and solid reasons to do so. Another example may be that you want to conduct discovery to better understand the economics of cloud v on-prem or even to compare public cloud vendors against each other. Depending on what you’re trying to address, this may strongly influence the steps you take with the data collected. 

About Version 1

Version 1 proves that IT can make a real difference to our customers’ businesses. We are trusted by global brands to deliver IT services and solutions which drive customer success. Our 1300+ strong team works closely with our technology partners to provide independent advice that helps our customers navigate the rapidly changing world of IT. Our greatest strength is balance in our efforts to achieve Customer Success, Empowered People, and a Strong Organisation, underpinned by a commitment to our values. We believe this is what makes Version 1 different and more importantly, our customers agree.