In the realm of cloud computing, transitioning from on-premises infrastructure to cloud services can be challenging. As you embark on this journey, it’s crucial to evaluate your options and identify the optimal strategy for each application or workload. In this post, we’ll delve into Azure’s cloud rationalization model, highlighting key strategies and explaining them in straightforward terms.

What is Cloud Rationalization Anyway?

In simple terms, cloud rationalization is a way to figure out the best approach for moving your applications and workloads from your own servers (on-premises) to cloud-based services.

It helps you find the right method to make the transition smooth and cost-effective, while taking advantage of the cloud’s benefits, such as scalability, flexibility, and reduced maintenance.

Every cloud provider offers their own rationalization strategies, with minor differences in terminology. However, they all tend to use terms beginning with “R,” likely for marketing purposes and to create a catchy, memorable framework.

Azure defines the 5 R’s of Cloud Rationalization:

  • Rehost
  • Refactor
  • Rearchitect
  • Rebuild
  • Replace

Personally, I struggle to differentiate between Refactor, Rearchitect and Rebuild! They seem somewhat ambiguous terms and arguably confuse the matter.

It’s much easier to understand when they are given a friendlier substitute, also-known-as (aka), name:

Microsoft Name Also-Known-As
Rehost Lift and Shift
Refactor Repackage
Rearchitect Reimagine
Rebuild Recode
Replace Retire or Repurchase

We’re now in a better position to explain what they mean.

The 5 R’s Explained

“Lift and Shift” breaks the whole it begins with R idea, but it’s now a lot easier to see what the rationalization approaches are.

Rehost (Lift and Shift)

This approach involves moving an application or workload from on-premises to the cloud with minimal or no changes. The primary goal here is to migrate the application quickly and easily, without making significant modifications to its architecture.

Refactor (Repackage)

Refactoring involves making minor changes to the application’s code, configuration, or architecture to better leverage cloud-native features.

The application’s core functionality remains the same, but it may be updated to use Azure PaaS services (Azure WebApps, Azure SQL, etc), improve performance, or enhance scalability.

With this approach, you’re taking advantage of cloud capabilities while minimizing changes to the application itself.

Rearchitect (Reimagine)

Rearchitecting is the process of redesigning an application’s architecture to optimize it for the cloud.

This may involve breaking down monolithic applications into microservices, adopting serverless technologies, or implementing new patterns for improved scalability, resiliency, or maintainability.

This can be a significant transformation, but you will start to unlock the full potential of the cloud if you are willing to make the investment.

Rebuild (Recode)

In this approach, you would be rebuilding an application from scratch using cloud-native technologies and best practices. This often involves rewriting the application code, adopting new frameworks or languages, and leveraging managed services.

Rebuilding is suitable when the current application is outdated, difficult to maintain, or unable to meet modern performance and scalability requirements that Rearchitect would achieve.

Replace (Retire or Repurchase)

Replace involves either retiring an application or replacing it with a cloud-native or Software-as-a-Service (SaaS) alternative.

Retiring means decommissioning an application that is no longer needed, while repurchasing involves adopting an off-the-shelf solution that fulfills the same business needs.

Introducing the 6th R: Retain

As I mentioned, all the main cloud providers put their own spin on the rationalization strategies, each using slightly nuanced descriptions. Inspired by AWS however, there is really a 6th option to consider: Retain.

When considering an existing workload to move to Azure from on-premises, there is still the option of doing nothing!

It may be necessary to Retain it, to leave it on-premises. Using hybrid connectivity, you can still get your systems up and running, but it’s important to factor this in as you plan a cloud migration.

Comparing Time and Effort: The Trade-offs of Each Approach

Now that we’ve settled on it being The 6 R’s of Cloud Rationalization, it’s important to understand the trade-offs between each option.

6 R's of Cloud Rationalization showing relative cost and effort

Relative cost and effort for each Rationalization approach

The visualisation above is obviously very crude, and not to any scale (it’s probably logarithmic!), but it does provide a nice visualization for the relative time and effort needed for each option.

The blue items - Rehost, Refactor, Rearchitect, and Rebuild - are for workloads that are actually going to be migrated to Azure. It makes intuitive sense that it’s a progressive scale in time, effort and skills as you move from lift and shift all the way through to a full rebuild.

There’s subtlety in the the yellow Replace option as it encompasses both retiring a workload, or purchasing some alternative. It’s not necessarily at no cost. What do you replace it with? How do evaluate the options? If retiring the workload, what’s the impact to the business?

The same can be said for Retain. It still has the potential to incur some kind of cost. Whether that is for the effort in setting up connectivity between the cloud and on-premises, or even on staff re-training on how to follow business processes that span both on-premises and the cloud.

Nothing is for free, so it’s invaluable to be aware of the unique implications for each workload given the chosen rationalization option.

Putting It All Together

Understanding the various cloud rationalization approaches offered by Azure (and other cloud providers) can help you make informed decisions when migrating workloads to the cloud.

By carefully evaluating each option and considering the unique requirements and potential costs of each strategy, you can optimize your cloud migration efforts and fully realize the benefits of cloud computing.

Whether you’re just starting your journey to the cloud or refining your strategy, the 6 R’s of cloud rationalization are essential tools for navigating the ever-evolving world of cloud technology.

As always, feel free to drop your thoughts or questions to me on twitter @matttester. Happy architecting!