The 7 R's of cloud migration: How to choose the right method
Gartner's easy-to-remember model summarizing cloud migration options, later expanded by AWS, neatly captures the choices. Here are the benefits and drawbacks of each.
Although the public cloud has existed for many years, organizations are still working to migrate applications that are running in their data centers to the public cloud. In some cases, they might want to move an application to take advantage of consumption-based pricing. In other cases, the cloud makes it easier to scale or modernize the application. Or, they just want to avoid the expense of new data center hardware.
But there is a big difference between deciding to migrate to the cloud and doing it. While some applications can be moved with relative ease, others are notoriously difficult. What's more, there are many types of cloud migrations and methods.
The 7 R's model is a helpful way to remember them.
Why 7 R's?
The R's model isn't new, but it has evolved significantly over the years. Its genesis is usually attributed to Gartner, who came up with the 5 R's model back in 2010. The original five were rehost, refactor, revise, rebuild and replace.
As the cloud continued to evolve and more diverse workloads were being migrated to the cloud, AWS added a sixth R -- retire -- and eventually, a seventh, for retain. This seventh R is effectively an acknowledgment that not all workloads are suited to being hosted in the cloud.
Here's what each of the 7 R's means in practice.
1. Rehost
Rehosting is often referred to as lift and shift. It involves moving an application, as is, to the cloud.
Rehosting can be done in a few ways, but it often means creating cloud-based virtual machines that mimic the infrastructure an application is currently running on. Because the cloud infrastructure is so similar to the on-premises infrastructure, moving the application to a new home in the cloud becomes a relatively simple undertaking. For instance, some organizations rehost an application by building its virtual infrastructure in the cloud and then restoring a backup to the new, cloud-based infrastructure. There are usually some minor post-migration tasks, such as updating DNS records so the application can be accessed in its new location.
2. Relocate
The second R, relocate, is similar to rehosting. Both methods involve moving an application that is running on-premises to a VM instance running in the cloud, but there is one key difference. Rehosting an application requires you to create a cloud VM instance and then move the application onto that instance. Relocating, on the other hand, involves moving an existing VM from an on-premises environment to the cloud without making significant changes to it.
Suppose your organization is running VMware virtualization software and you need to migrate one of your virtual machines to the cloud. Rather than working through a tedious manual migration process, you could find a provider that offers VMware in the cloud and migrate the VM to the provider's cloud.
The biggest advantage of this type of migration is its simplicity. Another advantage is that because you're using a cloud version of the virtualization platform that you were using on-premises, there is almost no learning curve for IT staff.
3. Replatform
While rehosting is sometimes referred to as lift and shift, replatforming is more of a lift and reshape. Originally revise in Gartner's 5 R's model, it's sometimes referred to as lift, tinker and shift.
The idea behind replatforming is that if you are migrating a legacy application, the cloud providers probably offer many features and capabilities that didn't exist when the application was created. It can make sense to enhance the application as part of the migration process so it can take full advantage of what the cloud has to offer, such as scalability and flexibility.
Replatforming an application tends to be costly and time-consuming, but in some cases the effort is justified. This is especially true if you're updating a core line-of-business application in a way that will increase revenue or enable you to keep using the application for years to come.
One thing to keep in mind is that not every application can be replatformed. Replatforming is primarily an option for open source applications or ones developed in-house. Commercial software vendors don't typically provide their source code, which is an absolute requirement for replatforming.
4. Refactor
The fourth R, refactoring, is like replatforming in that it involves modifying an application to take advantage of everything the cloud has to offer, but there are important differences. Most notably, when you replatform an application, you retain its architecture, and it continues to work in much the same way. In comparison, refactoring means making fundamental architectural changes to the application. For example, you might break an application down into a collection of microservices.
Refactoring is arguably the most difficult of the migration types, but it is sometimes worthwhile as a way to future-proof an application. As with replatforming, you need access to the application's source code to refactor it.
5. Repurchase
The fifth R, repurchase, has a few meanings. For one, it can mean replacing an on-premises application with a competing, cloud-native application that does the same things. It can also mean replacing an on-premises application with a SaaS version of the application.
Finally, repurchasing can refer to phasing out legacy architectural components in favor of serverless managed systems. For example, an organization might replace its SQL Server database with a managed service, in which the cloud provider runs SQL Server in the cloud. The advantage of this approach -- as opposed to just running SQL Server on a cloud-based VM -- is that when a database is offered as a managed service, the cloud provider handles all the associated maintenance. The provider keeps the service running, provides the necessary redundancy and handles any required patch management.
6. Retire
It doesn't always make sense to move every workload to the cloud. You might be better off retiring some legacy applications.
A workload might be suitable for retirement if it is no longer actively supported by the vendor. In such cases, it's important to make sure you have a workaround before retiring an application the organization still uses. That might mean adopting a competing application that offers similar functionality or developing one in-house.
Occasionally, you might need to make significant changes to the organization's business processes before you can retire an outdated application. For example, if an application is no longer supported and suitable replacements prove cost-prohibitive, you might be better off changing the business processes instead.
7. Retain
The seventh R, retain, essentially means leaving an application alone for the time being.
Suppose your organization depends on a particular application that currently runs on-premises. While there might be pressure to migrate it to the cloud, the vendor has announced a SaaS version for later in the year. It probably doesn't make sense to endure the cost and hassle of a cloud migration when you can wait for the cloud version.
The retain strategy can also come into play when application dependencies must be considered. Suppose, for instance, that your organization has a particular application it wants to move to the cloud. During the planning stage, you discover that another application running on-premises depends on the application that the organization wants to migrate and could stop working. In this situation, the application must be kept in its current state until dependent applications have been migrated or retired.
Brien Posey is a former 22-time Microsoft MVP and a commercial astronaut candidate. In his more than 30 years in IT, he has served as a lead network engineer for the U.S. Department of Defense and a network administrator for some of the largest insurance companies in America.
