Cloud
|
5 mins
|
March 23, 2022

Four critical success factors for cloud migration

by

Virtasant Research Team

What are the key factors that will give you value from your cloud migration?

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.

Dimension Description Example Impact on Cloud Migration Approach
Operating Cost The costs incurred to maintain and operate the application, including application support, devops, etc. Moving to managed services will generally reduce the cost to operate, as the cloud provider takes care of much of the heavy lifting.
Infrastructure Cost The costs incurred to build, maintain and operate the supporting infrastructure, including hardware, software, network, and infrastructure support. To reduce infrastructure costs in the cloud, moving to a cloud-native database can reduce support and licensing costs.
Uptime & Reliability The key metrics related to system availability & stability that must be met to meet regulatory commitments, customer expectations, safety requirements, etc. If you have an application that does not need to have an extremely high level of uptime (99.9+%), you can leverage the natural redundancy of public cloud platforms to avoid the costs of duplicate infrastructure.
Scalability & Performance The load and performance requirements for the application (high transaction volumes, low latency, etc.). Low latency requirements with a global user base requires significant geographic distribution and redundancy, while more tolerant or geographically narrow applications can work well in smaller geographic footprints.
Developer Productivity The amount of time spent by developers enhancing, fixing, or evolving the application. If you have a complex, custom module that is difficult to maintain and is offered as a cloud-native service, it could be worth the effort to replace that code with the cloud-native service.

  1. 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).

  1. 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.

  1. 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.

X

Get Your PDF Copy

Get a full, printable copy of the AWS Show conversation on the various approaches a FinOps program could take to address the #1 FinOps challenge from a practitioner's viewpoint.









Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.