The Secrets of Success to Cloud Migration at any Scale

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 Mordointelligence.com 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.

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.