Choose Wisely from the 7 Rs of Cloud Migration Success

Keith Worfolk Associate Partner

As you launch your cloud program, and your initial migration waves, you are implicitly addressing both the retrofitting of “old development” solutions as well as setting the development standards for new cloud solutions. There’s no getting around this, and there needs to be balance between short-term migration efficiency and longer-term operational efficiency.

The “7 Rs” has become a cloud industry standard way to think about the most effective architectural change management needed for any particular solution as it is considered for migration to the cloud. While there are subtle differences between cloud providers when looking at the target design for a solution, the target architecture choices are mostly cloud-agnostic for your planning and to start any redesign process.

The way you migrate or design your cloud application and its infrastructure initially will affect (or haunt) your solution throughout its lifecycle.

If you simply choose to “Lift n’ Shift” your solutions by Re-Hosting or Re-Platforming (2 of the available 7 Rs choices), you may be setting a dangerous precedent for your cloud’s future. You are implicitly deferring:

Already available cloud optimization opportunities from your cloud provider
Early cross-team cloud learning (and tooling) opportunities that can support your future cloud optimizations (e.g. reusable optimized designs)

You are also explicitly entrenching old design inefficiencies (e.g. in your solutions, operations, staffing, and skills). Worse, the same inefficiencies you may have allowed on-prem are likely to be more costly when replicated into your cloud.

While cloud provides many cost benefits for optimized solutions, it has no forgiveness for inefficient design when you choose a poor target architecture and “R” for a solution.

It’s become quite common for a company that employed a mass Lift n’ Shift migration to later regret this and wonder why they aren’t getting the cost savings they expected in the cloud.

Hence, the target design choices you make early in your cloud migrations will affect your cloud solutions maturity and operational efficiencies for a long time. So, you should make it a priority to learn about and employ cloud optimization best practices – including informed 7 Rs decisions – early in your cloud journey. If you don’t, you’re deferring many optimization benefits indefinitely, and ensuring the path to get there will be harder, both technically and skills-wise.

This brings us to the choice of Rs you have when migrating, and what these mean for your solution, your teams, and your FinOps goals. Here’s an overview of each (with planning detail in the chart below):

Re-Platform (“Lift n’ Reshape”) – Moving a solution to cloud (or new cloud platform) with minimal changes for a similar platform foundation (e.g. between clouds)
Re-Architect – Redesigning/restructuring a solution at a modular or service level to make use of selected cloud services
Re-Factor – More comprehensive re-design for cloud optimization that may include significant re-coding
Re-Host (“Lift n’ Shift”) – Moving a solution to cloud “as-is”; strictly an Infrastructure-as-a-Service (IaaS) transplant from on-prem configuration to the cloud
Re-Purchase (“Drop n’ Shop”) – Moving away from current design to a new solution with comparable functions and features (e.g. a Software-as-a-Service alternative)
Rationalize – Retain initially, but plan to rationalize this solution with other options currently available in the enterprise
Retain/Retire – Keep as-is, where-is, and revisit later (e.g. for decommissioning)

Graphic: Cost and Savings Estimates per “R” Migration Approach

The first decision you’ll want to tee up for your migration candidate solution is – how “cloud-ready” is it? “High” means that it’s already structured in a way to utilize efficient cloud Platform-as-a-Service (PaaS) services rather than needing to become an infrastructure (IaaS) transplant in the cloud.

Such a “High Cloud-Ready” solution is generally written in a modern language, modularized or service-oriented to enable new services integration, and key components (e.g. database) can utilize other “plug-in” options (e.g. DBaaS). If the solution to migrate is “High Cloud-Ready,” you have more R choices towards a more efficient target cloud design. But if your solution is not cloud-ready, it will need a technical “upgrade” of some sort to bring it into the cloud. There is a third possible disposition, simply stated “N/A,” for solutions to be either rationalized or retired.

Upon understanding the candidate solution’s disposition, the next decision you’ll want to make is related to the effort, costs, and savings potential. This is where you choose the “right R” for your solution’s target architecture and design. The above graphic can help you hone in on a few top “R” choices for your particular solution; from which you can analyze further (e.g. via comparative business cases) to decide the final target design (which, by the way, can come from a reusable set of approved, pre-optimized target designs you should build up over time).

Hence, architectural and engineering strategic decisions made early in cloud target designs have lasting impacts that can be cost-effective (or not) or performant (or not). This is where most “Lift n’ Shift” approaches die; and should.

With the potential of high cloud setup, run, and scale-up costs, which can grow more quickly in cloud than traditional on-prem infrastructures, the establishment and maturation of optimization capabilities, processes, and skills will be critical when Planning, Designing, Migrating/Developing, and Operating your cloud solutions.

A Cloud Optimization Strategy should be applied throughout all stages of your SDLC.

A well-designed cloud strategy will include an optimization approach and process, working across multiple stakeholders’ needs, and starting during a candidate solution’s plan for migration (and its chosen target design, its “R”).

A cloud strategy without optimization priorities and proactivity is flat-out incomplete. This unfortunately is the state of most mass Lift n’ Shift efforts.

For successful cloud adoption and rollout, a natural part of a successful cloud strategy must include initial (during migration) and continual optimization of performance and cost benefits. This drives further adoption and promotes further optimization, as stakeholders see the benefits.

Beyond your SDLC, where migrations (or development) occur right after Planning and Design steps, your CloudOps teams will want to experience operational agility, efficiency, and transparency provided by new cloud services and tools in support of their regular activities; and bringing your cloud stakeholders full circle, your Finance/FinOps teams will want to regularly see cost savings as promised by the cloud strategy.

Without optimization, which starts during migrations, you won’t have the savings or efficiencies expected; and the sooner you build optimization into your solutions, preferably as you set these up (e.g. migration), the better your opportunity to enjoy and maximize these benefits. If you try to “fix it later,” as many have tried, your cloud strategy may likely fail, in perception and reality.