There is no denying that the public cloud is the future, and that it has the potential to unlock tremendous value for organizations that adopt cloud-first strategies. With the public cloud you get technology infrastructure that is constantly updated, continuously evolving, highly scalable, and extremely secure. Despite all of these advantages, getting value from cloud migrations can be far from guaranteed.

Over the past 15 years of migrating hundreds of products and applications to the public cloud, as well as through our conversations with thousands of companies around the world, we’ve seen a consistent pattern of cloud migration challenges that organizations can proactively address with the right cloud migration approach.  This article outlines 4 critical success factors that in our experience consistently drive value from cloud migrations.‍

1. Understand Your Cloud Migration Goals and Align Your Teams to Them

Generally speaking, one of the primary reasons initiatives fail at companies of all sizes is a lack of clear goals with objective, quantifiable measures that are well communicated and widely understood.  The goals and measures, and therefore the plan of attack, for a cloud migration whose primary objective is to save money are dramatically different than a cloud migration whose goal is to improve scalability or reduce product development cycle times.  Regardless of the primary goals, the goals across a set of key dimensions should be well understood.  For example, the primary goal may be to reduce cost, but at the same time the cloud migration can’t impact SLAs or development cycle times.  All of these factors should be understood and prioritized, so that teams can make decisions accordingly.

To do this, we use a cloud migration prioritization model across 5 key dimensions (pictured below).  For each dimension, we ask a multi-disciplinary team of stakeholders across the relevant teams (technology, product, operations, customer support, etc.) to rate the importance of each on a scale of 1-5, with corresponding measurable goals for each (20% reduction in operating costs, 99.9% uptime, etc.).  This not only gives us the relative importance of each, but it also sets the boundaries for the solution in terms of what the cloud migration needs to deliver.  For example, if it is an internal application with a higher tolerance for downtime (for example, 98% uptime) that would drive a dramatically different infrastructure design compared to something that had a low tolerance for downtime (for example, 99.9999% uptime).  Too often, there is an assumption that the cloud solution “needs to look exactly like the hosted solution”, when in reality, they just need to meet the same objectives.  In the cloud, you can often meet the same objectives with much simpler, more cost-effective solutions.

‍

‍

2. Understand Your Current Costs and Accurately Model Cloud Migration Expected Costs

A common theme for companies that migrate to the public cloud is that they find that the costs once they get there are significantly higher than expected, often times orders of magnitude higher.  While there is certainly complexity in cloud pricing and discounting, the costs of a lift and shift can be well understood, as you are simply replicating the computer, network, and storage you have today in the cloud.

‍It isn’t enough to simply model the like for like infrastructure costs.  Often there are costs that you have in the datacenter that don’t migrate over, such as hardware support costs, maintenance plans, etc., and new costs that pop up in the cloud (such as managed cloud services and data transfer).  It is critical to have a like-for-like comparison, and to truly understand that basic comparison.  This gives you a baseline to understand the impacts of any specific changes over a basic lift and shift (such as replacing a licensed database product for a native cloud DB).

3. Align the Cloud Migration Strategy to Your Goals

We hear many people say that there is always “one right way” to migrate, and there are certainly strong opinions.  The most common camp suggests that you should always do a basic lift and shift to get applications out of the datacenter as quickly as possible, and then optimize once you get there.   Depending on the nature of the application, and your organization’s goals, this is certainly one valid approach.  For example, if you have a datacenter that has hardware that is rapidly approaching end of life, you may determine that the primary goal is to retire the datacenter quickly, and therefore a rapid lift and shift with no variations is probably the best approach.

However, if you have an application where the goal is to address maintainability, cost, or performance, simply moving to the cloud may not solve your problem, and you may add unnecessary risk and complexity to the  migration (and delay business value) by not addressing these issues in the cloud migration.

‍We suggest a portfolio approach, where you have a complete understanding of the costs of the application, as well as a view across the key dimensions of value, to determine on an application by application basis what the right approach is.  This allows you to tailor the cloud migration approach to the unique needs and context of each application, while developing a cloud migration plan that aligns to the defined goals and objectives.

4. Be Strategic and Goal-oriented in Sequencing the Move to Cloud-Native/Cloud-Managed Services

If your strategy is to merely use the public cloud as rented virtual infrastructure, you will inevitably be disappointed, both in terms of the cost to run your applications in the cloud (it will likely be more expensive), and in your ability to drive new features and product innovation.  The true power of the cloud can only be realized through the adoption of cloud-native capabilities and cloud-native services, as that is where the real value and power of the public cloud resides.

However, this does not mean that you should jump into the full suite of these services as part of your cloud migration.  It may make sense, for example, to move to a managed database service to take advantage of the natural scale and redundancy these services provide, but delay other adoption until the application is stable, or when there is a major change planned to the underlying codebase that makes the switch easier.  Adopting many of these services will require underlying architecture changes, and that may not be warranted until more structural changes are required.

Conclusion

Realizing value in the cloud is not guaranteed.  However, with some proactive thinking and a clear understanding of the goals of each migration, organizations can more reliably realize value in their cloud migrations, and make strategic, focused course corrections when they are off track.

Hoping that a basic lift and shift on its own will bring transformational results to an organization will almost always lead to disappointment.  A strategy of “we’ll get to it later” almost never works (in anything), and even if it does, it could mean years of wasted opportunity and money.  By setting a clear understanding of the specific goals of each cloud migration, aligning the team on those goals, and consistently measuring decisions and progress against those goals, organizations can ensure that they truly realize the transformational value of the public cloud.

‍