7 Reasons Your Cloud Migration Will Fail

It should be apparent by now the benefits of running your IT workloads in the cloud. However, cloud migrations are hard. It will challenge everything about how your company operates. Here are a few of the pitfalls you will likely experience as your company moves to the cloud.

1. No Cloud Competency

“Bring in people with cloud experience, either by hiring full time employees, using a cloud consulting firm, or finding them in your organization.”

First, the most obvious reason a cloud migration will fail. Nobody at your company knows how to use the cloud. If you have been operating in a datacenter and have very little automation, you are probably at risk for this. Working in the cloud is not the same as operating in a datacenter. In the cloud, you will want to automate the management of infrastructure to a much higher degree than you would in a datacenter. This means you need people with development or other automation experience.

My Recommendation: Bring in people with cloud experience, either by hiring full time employees, using a cloud consulting firm, or finding them in your organization. A lot of companies have developers that are capable of (and may already be) using Infrastructure as Code (IaC) tools and setting up CI/CD pipelines. Purchase training tools like acloud guru and incentivize their use. Socialize achievements by celebrating certification and other achievements publicly.

2. Big Dreams, Short Deadlines

“Create opportunities for small victories to build momentum.”

A lot of customers have regrets about now they have been operating in the datacenter. A cloud migration presents them with the opportunity to “do it right this time”. This means there will be a lot of bikeshedding over every little decision. Developers tend to over abstract and focus on reusing code rather than using it. This is especially true when working with Infrastructure as Code tools.

My Recommendation: Create opportunities for small victories to build momentum in your cloud migration. Setup a cloud migration program to track the status of multiple projects. Start with an initial application and a landing zone. The initial application should have few, if any, dependencies and be a standard lift and shift. Once these are successful you can increase the velocity by adding additional projects and thinking about refactoring and reusing code. Use code first, then worry about reuse.

Focus on doing a like-for-like migration, especially in the early phases. Presumably, you are operating fine with your current capabilities in the datacenter, so don’t overthink it when moving to the cloud.

3 - Territorial Fighting

“Establish a Cloud Center of Excellence where each team is well represented.”

A migration to the cloud is exciting for many people. It will allow them to get some great experience with the latest technologies and build up their resumes. It is also a source of anxiety as people begin to fear for their jobs. Many people think moving to the cloud means needing less people. These two circumstances lead to a lot of fighting between different teams within an organization. This makes it very difficult to make decisions.

My Recommendation: Establish a Cloud Center of Excellence where each team is well represented. Keep it as small as possible while maintaining these “seats at the table”. Reassure other team members there is plenty of work to be done in the cloud. Empower the Cloud Center of Excellence to make decisions and execute.

4 - Hidden Dependencies Between Applications

You may already have a tool tracking your applications and dependencies, but more often than not that is not the case or the information is out of date. During migration planning, your organization should do some discovery on your existing infrastructure topology. Either way, you will miss some dependencies between systems. This will cause a stoppage as you need to untangle and pull new applications into the migration phase.

My Recommendation: Use a best of breed Application Discovery tool to discover dependencies. Plan upfront to have datacenter connectivity to your cloud during the migration. This will alleviate some of the dependency issues you are likely to experience during the migration. Run agents on the machines where the application resides and audit the network connections into and out of the machine prior to migration.

5 - Wild West Adoption

“Production accounts should be locked down so nobody can make modifications without going through a development pipeline.”

When first beginning your cloud journey it is tempting to login to your chosen cloud provider and just start building things out in the console under the excuse of it just being a POC. As more people are onboarded, they continue this trend. Before you know it, you have a lot of cloud resources costing a lot of money and nobody knows what is being used and by whom. This is a bad spot to be in from a cost optimization and security perspective. In addition, it reinforces bad habits when dealing with production environments. Changes should not go directly to production.

My Recommendation: Give application engineers their own accounts to test out new changes. These should be ephemeral and cleaned out regularly. Production accounts should be locked down so nobody can make modifications without going through a development pipeline. Everything should be defined in IaC in a repository. Nobody should have write access to the production accounts. Once you get further, you should lock down lower environments for similar reasons.

6 - Large Amounts of Data

Another key component of a cloud migration is moving the data. In my experience, organizations are overly optimistic on the throughput of a data connection, especially after it is becoming saturated by other applications. A small decrease in throughput can greatly extend the time of a data transfer. It may even take it beyond some downtime windows.

My Recommendation: Data size and throughput analysis needs to occur upfront. Consider using other means to get the data moved to the cloud. Do initial snapshot with incremental updates so the final push does not have to move a complete dataset.

7 - Reinventing The Wheel

“Start with some well-known approaches and pivot if they do not meet your requirements.”

One thing I see frequently is that many companies feel like their migration is a special snowflake and they need to invent their own cloud operating model or migration strategy. This can lead to analysis paralysis as people are forced to make decisions with unclear constraints.

My Recommendation: There are many examples of how to execute a cloud migration and many companies have been through the process. AWS has published whitepapers, many of which are still valuable even if you are not using AWS. Start with some well known approaches and pivot if they do not meet your requirements.