DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

DevOpsGroup Blog The top 5 blockers of a Cloud Migration

The top 5 blockers of a Cloud Migration

What are the major blockers to an organisation’s cloud migration? The Flexera State of Cloud Report 2020 lists the 10 top reasons based on their research. In this blog, we’re going to look at things a little differently and give you our top 5 based on our experience over the last 8 years of running DevOpsGroup.  

A graph from Flexera 2020 State of the Cloud Report detailing cloud initiatives
Figure 1 – Cloud Migration Challenges – Source: Flexera State of Cloud Report 2020

#1 Technical Debt 

We’ve written about technical debt time, and time, and time again so it’s no surprise this tops our list. We’d argue that the #1 & #2 challenges on Flexera’s list “understanding app dependencies” and “accessing technical feasibility” are only challenges because of the technical debt that exists inside your organisation’s app portfolio.  

If you haven’t been upgrading and managing your application portfolio effectively, to the point where you no longer understand what depends on what, or that you are dependent on unsupported legacy technologies that are difficult to migrate to the cloud, then your technical debt bill has become due (just like that January credit card bill after the Christmas and New Year splurges!).  

DevOps can help you repay that technical debt and hopefully start you on a virtuous cycle of improvement that leads to a lower TCO and higher ROI from your application portfolio. This is why we recommend the “evolve” pathway to the cloud. Modernising your applications and the underlying platform is the secret to driving the real benefits from your cloud adoption.  

#2 The Skills Gap 

“Lack of resources/expertise” is frequently cited as the #1 challenge organisations face in cloud adoption. (Source: Rightscale State of the Cloud Report 2019).   

We see this skills gap in 3 major areas: 

  1. The technical leadership and programme management skills needed to establish and effectively run the “cloud enablement team” that leads your cloud adoption/cloud migration programme. AWS and Azure call this the “Cloud Center of Excellence” (CCoE). We find this term alienates the people you’re trying to help, so we prefer the term “cloud enablement team”.  
  1. The cloud skills needed to build the cloud platform and deliver the cloud migration.
  1. The cloud skills needed to manage and operate workloads in the cloud.  

There are in turn 3 ways to address this skills challenge: 

  1. Get a 3rd party to help fill your skills gap. This can provide you with the people you need for your cloud enablement & cloud migration teams. It can range from interim CTO and cloud solution architects to hands-on DevOps & Cloud engineers.  
  1. Give your people the skills they need through training, coaching and mentoring.
  1. Use a cloud managed services provider to help with the day-to-day operations whilst your teams get up to speed.  

Unsurprisingly these are exactly the gaps we’ve designed DevOpsGroup to fill. From cloud strategy to cloud migration engineeringCloud managed services with our Operate team. Training, coaching and mentoring with the DevOpsGroup Academy.

#3 Making the business case for cloud

Flexera calls this “assessing on-prem versus cloud costs”. We prefer to widen the scope to talk about the challenges of getting the business case for cloud adoption approved.  

TBH this is probably one of the major blockers for a traditional Enterprise that follows a “business case ROI” model. It is also a huge demoralising time suck for everyone involved.  

Yes, there are a number of common, yet difficult, challenges in creating the business case: 

Your assessment of your on-premise costs is probably wrong. This is because you’re not accounting for facilities costs, utility costs, maintenance costs, hardware costs, software licensing costs, staff costs, training costs, pensions costs etc. Depending on where you draw the line, you can make on-premise look cheap or expensive. Either way, it’s probably wrong.  

Your assessment of your cloud costs is probably wrong. This is because until you actually migrate you probably won’t really know what you are going to consume in the cloud. Your estimates of CPU, storage, data ingress & egress, the relative usage of IaaS versus PaaS, if you adopt DevOps automation to give you dynamic right-sizing of workloads to demand to reduce costs, how much can you containerise etc. Depending on where you draw the line, you can make the cloud look cheap or expensive. Either way, it’s probably wrong. 

Both AWS and Azure offer excellent guidance on creating the business case for the cloud. The real secret though is the central message of the 1984 movie “War Games” – “the only winning move is not to play”. In this case, to decide not to play the ROI business case game.  

Illustration of a computer screen depicting the 1984 movie “War Games”

Cloud adoption should be seen as a strategic decision by the business to obtain the competitive advantages that cloud services provide. For example, both AWS and Azure offer incredible AI & ML capabilities that would be virtually impossible for any organisation to replicate on their own. Multiply this by the huge range and diversity of cloud services now available, the decision to remain solely on-premise becomes untenable in our opinion. 

Arguing over on-premise versus cloud costs is the 21st Century I.T. equivalent of theologians arguing “How many angels can dance on the head of a pin?”. It is largely a waste of everyone’s time and misses the point of the impact of cloud on business strategy and competitive advantage.  

A far better approach, given that the strategic decision has been made that cloud adoption is in fact strategic to the company’s future business goals, is to ask “what can we afford to spend right now, and for how long?”. Translate that into a cloud enablement team and migration teams to take an incremental, application by application, workload by workload strategy to migrate & modernise your application portfolio. Like any iterative, agile approach this means you will start to deliver value to the business as soon as possible.

One of the major differences to a traditional data centre migration is that cloud migration can be done in an Agile way (recommended by both AWS and Azure). The cloud offers elastic capacity, so there is no need to do a huge waterfall capacity planning and design phase upfront. You can assess each workload, perhaps using a tool like AppScore to determine the right migration approach. You can also build out the cloud platform and code pipelines for that workload, deploy it, and then manage the application and its direct cloud costs for that application in line with its business value, as part of your application portfolio.  

#4 Waterfall analysis paralysis 

Closely related to the business case blocker discussed earlier is what we call “waterfall analysis paralysis”. This is when an organisation has decided to take a waterfall approach to their cloud migration.  

In this view nothing can be migrated until every application has been analysed, every dependency mapped, every cost estimated, every box ticked. Unsurprisingly, this is a recipe for paralysing your cloud migration from making any meaningful progress or starting to deliver any value.  

In some situations, this is actually a deliberate blocking strategy on behalf of people inside the organisation that are opposed to cloud migration. It’s easy to add one more requirement, one demand, one more analysis that needs to be performed “before we’re ready to start migrating” with the express intent of stopping the migration moving ahead.  

As mentioned earlier, both AWS and Azure recommend an Agile approach for cloud migration. But an incremental approach is also a less risky strategy. A small change – for example moving one isolated workload – is inherently less risk that any type of “big bang” approach. Small incremental steps enable you to learn and continually improve your migration approaches and your cloud operations processes too.  

#5 Cloud vendor selection & lock-in

Many organisations spend ages agonising over their cloud vendor selection (#8 in Flexera’s list). They often then spend ages worrying about “vendor lock-in”. As a result of that worry, they make some bad design choices (notably avoiding the vendor-specific PaaS services and choosing the more expensive IaaS solution).  

Yes, vendor selection can have a financial impact, particularly when you consider Flexera’s #7 “knowing implications of BYOL” (Bring-Your-Own-License). Vendors like Microsoft, with their Azure Hybrid Benefit programme, or Oracle Cloud Licensing terms, do use licensing as a lever to get you to prefer their cloud. AWS in turn fights back with incentives to get you to choose their cloud instead, like the AWS Windows MAP programme.  

The best advice here comes General George S. Patton who, whilst he predates the cloud by 50 years, knew quite a lot about effective strategy.  

“A good plan, violently executed now, is better than a perfect plan next week”

Gen, George S. Patton 

As with blockers #3 and #4 above, you need to pick the cloud vendor you feel most comfortable with between – AWS or Azure – and just get on with it.  

If you’re a large Enterprise customer you can negotiate hard to get great discounts via an EA (Microsoft) or EDP (AWS). You can probably get loads of migration funding via AMP (Azure) or MAP (AWS). If you’re a mid-market customer you might prefer to buy via a partner (like DevOpsGroup), via CSP (Azure) or SPP (AWS) where we can help you optimize your spend and optionally wrap in managed services as part of the deal.

What next?  

Hopefully being aware of these potential blockers in advance will enable you to make better choices as part of your cloud adoption and cloud migration strategy. And, of course, if you need any help just get in touch!  

Leave a Reply

Your email address will not be published. Required fields are marked *