Cloud Migration Strategies: Analysis of the Gartner Framework 5 Rs

19/04/202219/04/2022 LuisMi Gracia

Why migrate to the Cloud?

Much has been said about changing local environments for the cloud, but can you say why?

The migration to the Cloud or the outsourcing of IT from the direct control and operation of the company to one or more external service providers is a strategic decision of the company, and can happen for a number of reasons:

Reduce costs, in addition to improving value delivery and moving from fixed costs to variable costs.
Refocus the efforts of the IT team on the core part, and take to the Cloud what is not the core of the business (commodities).
Respond to changing business conditions more quickly and effectively, creating a value-based strategic partnership with the business.

There are different strategies to carry out this migration, so in this post we are going to see and analyze one of them.

Gartner Framework 5 Rs for migration to the Cloud

In 2010 Gartner published the first version of the 5 Rs framework, which defines all the basic options to migrate an application to the Cloud (we can find more information about it at this link, registration required). Since then, Gartner has been improving and completing it, and other companies have used it as a base framework to build their own Cloud migration strategies and methodologies, such as the AWS 6 Rs model.

In Gartner’s 5 Rs model, application migration strategies are:

Rehost: Also known as «lift and shift», the application moves from its current physical or virtual environment to an IaaS in the cloud. By doing so, any modification of the system, other than what is necessary to adapt to the hosting environment itself (monitoring, for example), is avoided. Although this is the least ambitious and beneficial alternative, it is also the fastest to implement to «reach the cloud». In this case, the application is not Cloud-native as such.
Revise: The application is modified so that the application can begin to take advantage of the capabilities of the cloud to obtain elasticity and minimize the use of resources. This strategy focuses on reducing operational burden through the use of managed cloud services (for example, database PaaS). One can choose to use IaaS or CaaS to reduce operational complexity.
Rearchitect: The application is significantly modified to be able to adapt it to a Cloud-native architecture, making intensive use of the cloud-native capabilities. The rearchitecture alternative is a deep task that requires changes in the methodology, the technology, the development process, etc. This strategy includes PaaS (aPaaS), Kubernetes, Function PaaS (fPaaS), and Serverless capabilities.
Rebuild: It recommends that you start from scratch, scrapping some or all of the existing code that has accumulated over the years. This alternative prescribes the use of Cloud services, Kubernetes, aPaaS, fPaaS, etc. The reasons for using this approach are, among others, to allow:
- Developers, to focus their efforts on code delivery.
- Non-developers, to deliver applications using LowCode models.
- Technical debt, to be amortized.
- Adopting new architecture paradigms that are better adapted to current business requirements (streaming processing, Big Data, etc.).
- Simplify the application.
Replace: Opt for a SaaS solution to replace your COTS software suite or fully custom application. Although this is a common pattern for replacing older on-premises COTS solutions, it also applies to custom software applications. These SaaS solutions have low entry barriers in terms of capital and technical constraints, making them a very attractive option from a capital/upfront cost and lead time perspective if a vendor can be found that meets the requirements of your application.

Examples of the strategies

Having said all of this, here are some examples of what we mean:

Rehost: Deploying an existing Java EE application to Amazon Web Services (AWS) Linux EC2 instances.
Revise:
- Move from using the JMS implementation of Java EE applications, to using a cloud-based messaging provider.
- For an application hosted on Amazon EC2, replacing a cloud-hosted Oracle DBMS instance with Google Cloud SQL, Azure Sql Database, or Amazon Relational Database Service (RDS).
Rearchitecture: Redesign of a monolithic Java application, breaking down the functionality into smaller services to be deployed independently, and then deploying to Amazon EC2 Container Service or Google Kubernetes Engine.
Rebuild:
- Build a modern banking application that can be accessed through multiple channels, packaged in containers, and deployed and run on Kubernetes with the Istio and Prometheus service mesh for monitoring.
- Reconstruction of parts of an ERP through simple workflows using a Low Code Platform such as Mendix, OutSystems or Onesait Platform.
Replace:
- Salesforce CRM and Microsoft Dynamics 365 for the CRM management of an organization.
- Microsoft 365 as a productivity suite.

Comparison of framework strategies

Having seen some case examples, below we are going to summarize in a table some of the differences that affect the scope, complexity and level of effort that each of the alternatives introduces:

Vistos algunos casos de ejemplos, a continuación vamos a resumir en un cuadro algunas de las diferencias que afectan al alcance, la complejidad y el nivel de esfuerzo que introduce cada una de las alternativas:

	Rehost	Revise	Rearchitect	Rebuild	Replace
Source code	No changes	Minor changes	Update + New	New	N/A
Configuration	No changes	Extension	Transformation	New	N/A
Configuration and deployment	No changes	Update or New	Transformation	New	N/A
Application data	No changes	No changes or adjustments	Transformation	Transformation	Transformation

The scope, complexity, and level of effort associated with each migration strategy vary. Cloud computing has the potential to bring significant benefits to your business, but the more benefits you want to unlock, the more investment you have to make in the migration.

Not all applications need to be rebuilt from scratch, and ROI goals vary from app to app. If you don’t go far enough with application modernization, there may be issues with lower quality of service in the migrated application versus the original.

Considerations in choosing a migration strategy

Now, before launching to migrate to the cloud, we have to take into account certain considerations when choosing the strategy to follow, both at the level of the 5 Rs and business principles.

About the 5Rs:

Not all apps need to be rebuilt from scratch, and ROI goals vary from app to app. In some cases, insufficient application modernization can lead to issues with lower quality of service in the migrated application versus the original.
Migrating applications to the cloud does not always lead to a positive business outcome or return on investment, in which case other alternatives should be evaluated. For example, there are two additional strategies that are Retain and Retire.
Organizations are increasingly adopting Cloud CAPS and Containers-as-a-Service, requiring their custom developments to be Rearchitect or Rebuild to benefit from cloud capabilities, requiring further commitment from both development and operations, but offering better scalability, resiliency, and flexibility.
The Rehost strategy is the most direct path to the cloud, but also the least beneficial. Rehosting offers a limited opportunity to improve application runtime features and offers no opportunity to redesign the underlying architecture to take advantage of cloud-native and cost optimization capabilities.
The Replace strategy through SaaS is an alternative way of transitioning business capabilities to a cloud service. This option carries the highest risk of lock-in with the SaaS provider, especially if customization is also required.

Business principles

When a migration option is chosen, it must be considered under some exclusive principles of the organization, so it is important to take them into account. Some of them are these:

Degree of autonomy: Due to the pay-per-use and self-service features of the cloud, migration of applications to cloud providers can support a strategy of autonomy of teams, departments or business units. This influences the migration as some alternatives may require less IT support. An example of this is the use of Low Code platforms.
Closed versus open solutions: Organizations that favor solutions based on open platforms (eg Kubernetes, Kafka, etc.) have a reduced choice of services from their cloud provider because many provider services are closed/proprietary. With an open source solution, you don’t have to pay a vendor and often have multiple vendors to choose from that offer support, while closed vendor services are much cheaper.
Single vendor vs. mix of best-of-breed: The organization’s procurement principles may dictate the use of a single vendor rather than a mix of best-of-breed vendors and influence the decision when multiple migration options meet the requirements of one application.
Lock-in, portability, multicloud and interoperability: Portability would not be a consideration if an architect could migrate an application, along with its data, to a cloud provider and leave it there for its entire life. But ignoring platform lock-in is risky, so architects should consider a multi-vendor strategy for the many facets of cloud portability.
Development and operations capabilities: Outsourcing an application by migrating to a cloud platform means giving up some of the operational control to the provider’s staff. Examination of the competency profiles of the remaining development and operations teams will determine the degree of control to relinquish to the vendor.
Migration cost: Migrated applications have to meet adequate service levels. Breaking down existing application service level agreements is an important step. Engineers tend to ignore the need because local application budgeting can capitalize resources, such as server or storage, to make the cost of those resources disappear as «sunk cost».

Well, as you can see, migrating to the cloud is something as simple or direct as it seems at first, so it’s time to make a little reflection about what we are looking for and need.