Executing Your Journey to the Cloud

This post has been adapted from the 2021 DevOps Enterprise Forum guidance paper by Satya Addagarla, Anderson Tran, Mik Kersten, Rob Juncker, Betty Junod, and Sasha Rosenbaum.

Alright, you’ve come a long way on your journey to the cloud. You’ve pitched to the executive board, planned your journey, and become organized. But migrations take a long time. When it’s time to execute your move, choose your OKRs correctly and be ready to adapt to change.

Choosing OKRs to Report on Execution Status

OKRs (Objectives and Key Results) are the currently popular goal-setting framework used by many successful enterprises. An OKR consists of a clearly defined goal (objective) and three to five “key results”—specific metrics used to track progress toward that goal. OKRs propagate throughout the organization and help make sure that employees at all levels are aligned on what the primary goals are and what measurable outcomes will get them there.

Enterprise-wide cloud migration is an initiative that is likely to span multiple years. One of the most important tasks as you go into the planning stages is choosing the right goals and milestones for the project. The incentives you choose for executives and middle management will, to a large extent, dictate the results you get. Choose wisely. As Leonard Sherman writes in If You’re in a Dogfight, Become a Cat! “the trouble with incentives is that they work.”

For example, take a look at the following key results:

• Move X% of IT footprint to the chosen cloud within Y months.
• Reduce the time it takes to get a server for a new application by X% within Y months.
• Improve the corporate website SLA to 99.95% within Y months.

The first key result is the most appropriate if the main business objective of moving to the public cloud is moving out of the on-premises datacenter to save costs. The second is the most appropriate if the main goal is improving the agility of the IT department. The third fits if the goal is to improve the high availability of your customer-facing applications and so on.

While the public cloud offers many benefits, it is difficult to realize all of them at once. Measuring the organization on the wrong metrics will drive the wrong outcomes.

Make your OKRs as outcome based as possible. For example, the SLA OKR (the third in the above list) states an outcome that is clearly valuable to the customer and the business, so aim for those at the organizational level. In contrast, OKR 2 is important for the Dev and Ops team in support of OKR 1.

Ensuring that you have the right kind of OKRs for the various levels of the organization helps drive activities toward the outcomes that support your business case. At the top-level of the organization, having business and customer centric OKRs (such as improving the speed of innovation as measured by flow time) is critical. 

Another benefit of OKRs is that they assign clear deadlines and measure progress toward it, connecting technology activities to business outcomes. In many cases, enforcing a strict deadline on the cloud migration process, such as the date of the on-premises  datacenter lease renewal, can speed up the process.

Lastly, as with any large-scale initiative, it is crucial to track and celebrate short-term wins. As John P. Kotter writes in Leading Change, “Transformations sometimes go off track because people simply don’t appreciate the role that quick performance improvements play in a change effort.”

If we are only tracking the progress toward the finish line, which may be months or years away, we are likely to lose momentum as people across the organization get discouraged by the seeming lack of progress. Therefore, it is important to track progress on at least a monthly basis and reward short-term successes along the way.

The 5 Rs and a G

As you are approaching application migration, it is useful to use an appropriate assessment framework, such as the 5 Rs (repurchase, rehost, rearchitect, retire, retain). Having a framework allows you to classify applications and use pre-defined criteria to select the migration approach. There are multiple versions of this framework; the important part is to select the R’s that support your IT strategy and standardize on a consistent set of migration criteria across the enterprise.

• Repurchase: This is a classical build versus buy decision. If a high-quality SaaS version of the application exists, would purchasing it from a dedicated vendor save time and effort compared to maintaining the custom enterprise-specific version?
• Rehost: For many applications, it makes sense to move them to the cloud while maintaining the existing architecture. This is especially true when the migration effort has a tight deadline. Lift-and-shift is usually the easiest and fastest way to move the majority of existing applications out of the datacenter.
• Rearchitect: Many existing applications cannot be moved to the cloud as is, and need to be refactored or rearchitected to be moved. Cloud migration presents an excellent chance to invest in getting rid of technical debt and modernizing old but critical applications.
• Retire: In some cases, it makes sense to retire an application altogether. Cloud migration is an excellent chance to do a full application inventory and find out which existing applications are no longer in use.
• Retain: Some situations still remain when a particular application cannot be moved to the public cloud due to technical, financial, or legal reasons. It is usually a good idea to consolidate such applications to a single leased datacenter space in close physical proximity to your primary cloud datacenter.
• Green Field: Once you are fully committed to enterprise-wide cloud migration, it makes sense to mandate that all newly developed applications must be deployed to the cloud.

Are You a SaaS Provider or a SaaS Consumer?

Generally, applications fall into one of the two broader use cases after the cloud migration: applications that remain mostly identical in functionality and number of users as they were on-premises, and applications that become Software as a Service (SaaS).

For instance, if you had an enterprise-wide web application for HR benefits management, its functionality will largely remain the same after the move. In such a case, the move to the cloud either won’t affect the amount of IT time spent operating the application or may reduce it due to cloud efficiencies such as auto-scaling.

On the other hand, you might have an application that was offered to external or internal customers for self-installation that is now becoming SaaS. For example, most large retailers have a portfolio of custom applications developed in house. Pre-cloud, such applications were installed and operated by local staff at each store. With the migration to the cloud, many of these applications are now offered as a SaaS tool to all of the store locations, potentially globally, and maintained by the central IT.

If an application is transformed to SaaS, it is now central IT’s responsibility to deploy, upgrade, and maintain it. This can drastically increase the number of Ops/SRE resources dedicated to the application and is likely to require a different skillset. Modern SaaS services are expected to operate with upward of 99.95% SLA, which translates to less than five hours of downtime a year, including planned maintenance. Meeting high standards like this usually requires changes to the CI/CD processes, on-call structure, and even software development practices.

Adapting to Change

The migration effort is likely to span multiple years. During this time, cloud technology will evolve, the global IT landscape will advance, and your company priorities will change. It is important to keep pace with technology advancements and organizational priorities and realign the migration OKRs on a quarterly and yearly basis.

Aright, you’re almost there. But the journey isn’t quite over. Before we end this series let’s take a look at omni-cloud versus multi-cloud.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•