We find about 76% of organizations use two or more steps for cloud migration to eventually get to the most cost-effective, performance enhanced, secure, and efficient workload environment from a cloud platform.

by Tony Johnson

Cloud Sherpa Consulting

Working with many organization over the years, we have seen patterns emerge while supporting enterprises’ along with their cloud migration strategies.

A fairly common pattern is that architecting workloads for specific cloud platforms during migration is mostly an afterthought.

To be clear, I’m not talking about choosing a family and size for the workload and calculating the amount of egress networking for that workload. I’m talking about whether the workload should be deployed using IaaS, or should it be PaaS, serverless, or containers to start off as part of the initial deployment as well as the future technology stack.

We find about 76% of organizations use two or more steps for cloud migration to eventually get to the most cost-effective, performance enhanced, secure, and efficient workload environment from a cloud platform.

This multi-step migration process can be costly.

So why does it continue today?

Photo by imgix on Unsplash


The current model for cloud migration is typically as follows:

  • Analysis of current application inventory with dependencies
  • Review of the technology stack and determine and prioritize the application migration based on economic modelling
  • Create a tiered and prioritized wave plan
  • Design future workload environment based on current data center environment
  • Execute migration of workloads with standard dev cycles
  • Deploy workloads on chosen cloud platform

So what is wrong with the current model?

The challenge is that It looks more like a data center consolidation migration model, and not necessarily a cloud migration model.

The current model inevitably leads to a multi-step migration, because the business priorities dictate that the dev teams deploy the workloads as soon as possible to meet business priorities.   Other reasons for this multistep approach is they don’t know what they don’t know and go through several architectures testing the waters to get to the optimum architecture for that workload.


The part that is missing in most models today is the shift from cloud platform architecture being performed mostly post migration to moving earlier in the migration plan.

The reality is that when you have chosen a cloud platform to develop on you are committed, and it is the type of commitment where when you break up it’s ugly and expensive. Organizations need to shift to cloud platform architecture as part of the migration instead of modelling the server, you need to model the application and technology stack.

This is what I call step 1 of the typical multi-step migration.

The next step happens when the workload has been deployed for 6-12 months, then it may be optimized and have a more accurate sizing applied.

Then 12 months later the dev team will re-code the application to PaaS from IaaS, or even to serverless, or containers based on the maturity of the workload. At this point, the architecture has caught up with the workload maturity.


Organizations that have the time, need to spend the time to plan. We estimate that organizations pay up to 40% more during the first year of workload deployment by going thru the multi-step migration instead of incorporating a cloud-specific platform develop early in the migration plan.

But we also realize that it may not always be possible for some organizations based on skills, resources, time and budget.  This multi-step migration is one of the reasons for what AWS calls “The Big Stall”, where over 95% of AWS users experience some level of the big stall.

While 10% move quickly past the big stall, another 70% experience a delay in their cloud strategy of 12 months or more, and the last 20% give up entirely because they can’t make the cloud work for them.

It is important to create long-term best practices, value governance, and operational excellence. But it is critical to have a forward-thinking cloud migration plan in place that looks at developing for a specific cloud platform as part of the migration strategy.

Cabling Graphic: Photo by Franck V. on Unsplash

Cloud Sherpa Consulting

Tony Johnson (TJ), is a global thought leader for cloud governance, operations and optimization.

At Cloud Sherpa Consulting, he leads the team on new and custom offerings for clients around cloud governance and optimization.  TJ has been in the Information Technology community for over 25 years and has worked with many organizations from start-ups to major global system integrators like Accenture and IBM.

For the past 7 years, he has been a subject matter expert in cloud governance, operations and optimization.  Having worked with hundreds of clients over the years, he brings a level of experience and value to every conversation.  He speaks globally at cloud and technology events and advises CTO’s and CFO’s on the economic value of cloud computing.

TJ lives in Southern California and is currently writing a book on Cloud Value Governance.