What are 6 R's Strategies For Cloud Migration?

What is Cloud Migration?

Cloud Migration is about migrating your on-premise setup to cloud service providers like Azure/GCP/AWS. The Cloud Migration can involve migrating your VM's or applications deployment or database migration.

While performing the cloud migration not all on-premise can be migrated to cloud, they would require some enhancements which might include like OS version upgrade, SQL DB upgrade or .Net framework version upgrade. They are certains factors which helps us to know if we can migrate the application to cloud as-is , with minimum enhacements or major enchancement(rewriting the code), these factors which helps us to decide whether we can migration depending on different use cases comes under the 6 R's Strategies.

Why do we call as 6 R's stragegies, because the parameters are spread across 6 different scenarios staring with Letter "R".

Below are the 6 R's,

ReHost
Refactor/Replatform
Rearchitect
Retain
Repurchase
Retire

Let's go through each one of the scenario with example to understand where to apply this parameter.

1. ReHost

Rehost is where we lift & shift the current as-is on-prem to cloud mostly the VM's.

UseCase

Client1 has a scenario where they have a on-prem servers having OS & Linux OS with different number of VM's. The ask from customer is we need to migrate to cloud as-is they would like to have a VM setup in cloud. We can propose to use PaaS Service, but lets say if client is using SSRS where PaaS services doesn't support , we can't leverage to use PaaS Service provided by cloud.

Answer

In this case we need to migrate the VM from on-prem to Cloud using Azure Migrate tool provided by Microsoft, which helps in migrating the servers from on-prem which the same OS version & softwares, here since we are migrating as-is like a lift & shift approach where instead of hosting in on-prem we are now hosting in cloud, we call it as ReHost(where the as-is(on-prem) is being hosting again in the to-be(cloud)).

2. Refactor/Replatform

The term Refactor or Replatform are of same meaning, in few articles we might call as refactor or few other articles you would view as replatform.

Refactor is where generally we leverage to use Azure PaaS services with minimum changes or take advanatages/benefis of cloud and host our applications in cloud.

UseCase

Client2 has a scenario where he want to migrate the SQL database to cloud or web application to cloud which are currently hosted on-prem. Client is intersted in to leverage the services provided by cloud instead of creating infra on cloud like to use PaaS Service.

Answer

Since the client wants to migrate to cloud for the website, SQL Database, storages we can take the advantage of cloud services like migrating the sql database to azure sql db(PaaS), website to azure app service and files to azure blob storage/file share. Migrating the application would require minium effects to refactor the code slightly to deploy to cloud to use cloud native features.

Example. The code changes might include like integration with azure keyvault to read secrets which takes advantages of cloud native feature , reading configuration from app settings or using elastic pool to host multiple database to have better performance.

3. Rearchitect/Redesign

Rearchitect comes into play when we are making a major change in our code, like rewriting the application again or redesign the application.

UseCase

Client3 has a scenario where he has a legacy system which needs to migrated to cloud or would like to have a migrating monolithic application to microservice architect, which we require redesign.

Answer

The legacy code sometimes can't be deployed as-is to cloud due to limited support of OS compatablity, let's say client has developed a code with the older version of .Net framework 3.0 or 2.0 which has reached end of life and currently the OS versions are not being supported. In this case we need to redesign our application or rewrite the application with the supporting framework so that it can be deployed to cloud. This is would take a lot of effort & time as we have redesign the application, among the rest of R's this is the most challenging & would extra effort time for development.

Monolithic applications are a standalone applications where may be few years back most of the applications are written in this architect model. Now most of the organizations are keen & interested in using microsevices architecture due to scalability , availablity, Resilency. In case of migrating the monolithic applications to microservices we need to redesign or reachitecture the application how they currently designed to have microsevice type implementation. Like each module should be taken as independent service and should have its own database.

Hence, migrating monolithic application would require redesign effort and would also require rewritting the application this come under rearchitecture scenario.

4. Retain

Retain is where we tend to keep the application as-is without any changes.

UseCase

Client4 has a scenario where he wants to migrate few applications to cloud developed developed on old technology where there is no OS support or community support.

Answer

In this case, it is better to not to propose any migration, instead of retaining the infra & application in as-is state.

Example

The applications which are deployed on unsupported OS which can't migrated.
Due to business, client is not interested for migration.

5. Repurchase

Repurchase is where we purchase a another COTS or SAAS s/w instead of the currently available s/w which can have a better performance or it has the option to leverage in cloud & on-prem.

UseCase

Client5 is currently having email system on-prem and would to have a cloud email provider system or the infra he has is planned for decommionssing where currently the email system is configured.

Answer

The current system since is being planned for decommionssing, we can opt for Azure SendGrid which is a Cloud Email Provider, where we purchasing the service depending on usage. This usecase is mix of Rearchitect & Repurchase.

There also can be usecase where the the licence is nearing the expiration and we need to renew the license of the existing tool or use alternative tool by purchasing the license again.

6. Retire

After application discovery, you can also decide that you don't need these new applications in the future, so you’re just going to retire them. This is just getting rid of them as you’re not going to use them anymore.

Notes. During the application discovery, they can be chances that it can contain multiple R's factors being applied, in that case we need to consider the highest R's as stragegy approach.

Example. SSRS report migration to Power BI.

Here we need to migrate from SSRS to Power BI, which would require a lot of effort as the reports need to built from scratch, so it would be a rearchitect and also since we need to purchase the license of PowerBI it is Repurchase. It contains both Rearchitect & Repurchase, in such case we need to considered more time taking process as the stragegy, so in this case it would Rearchitect.

The Order of Priority is

Rearchitect > Replatform > ReHost > Repurchase > Retain > Retire.

Since I am background of Azure + .Net, the tech stack which I mentioned would be mostly on Microsoft tech stack, but the R's stragegy is common across the cloud providers, so it can be applied be to any cloud Provider like Azure/AWS/GCP.

MoveGroup

While planning for cloud migration you should also plan for movegroups where the application which are dependent on one another should be migrated in a same move group, non dependency can be considered and be migrated as part of initial/seperate move group.

Reference