How many R’s are there in Cloud Migration?
Working in a cloud migration consultancy, we are used to assessing and categorising applications using an approach first defined by Gartner over a decade ago. Gartner first published the “5 R’s” around 2010 which defined 5 options for applications that are targeting cloud migration. This simple approach gave a quick assessment to provide an indication of a migration path for applications that make up a large estate moving to the cloud.
However, can it be that easy? I think the answer is not really a “yes” or “no”. From my experience working as a Version 1 principal consultant since cloud adoption first emerged, I can see how people would say “yes” — it can be that simple, and I agree as a tool, yes, it is a simple approach that can accelerate decisions.
The “no” answer is really what has driven me to write this article. We commonly see customers request assessments against the Gartner 5 R’s, we also now see a more frequent request from customers for assessments against the 6 R’s; hang on, when did 5 become 6?
The answer to that lies with Amazon AWS’s 6 strategies for migrating applications to the cloud which was published in 2016. This approach introduced one of the most commonly used graphics to illustrate the 6 R’s, providing an excellent workflow for migration when adopting the 6 R’s to categorise your estate.
The approach progressed from 5 to 6 R’s overtime, could that be described as a natural evolution of cloud migration? Yes, but that evolution becomes more complex as more players in the Public Cloud market emerged. Microsoft Azure has undergone massive growth to join Amazon as the leaders in Public Cloud, so what is their migration approach?
That is detailed in Microsoft’s Cloud Adoption Framework 5 R’s of cloud rationalization. We are back to 5 R’s with Microsoft; however, as shown later in this article they are different from the original Gartner 5 R’s. What about other cloud providers?
Google GCP also has a cloud adoption framework that has a 6’Rs approach which is almost identical to Amazon’s. Oracle also has some material around cloud migration that recommends 7 R’s of cloud migration .
Version 1 provides cloud-agnostic consulting for migrations to AWS, Azure and OCI on a daily basis, so I wanted to understand the “official” line from each provider. Also acknowledging the value that Gartner’s advisory services provide as the source of this approach long ago (in cloud terms 11 years is really long!), I began to notice they had further variants on the approach themselves. For example, Gartner published 7 options to modernize legacy systems (no longer 5) in 2020 and Amazon mention 7 R’s (no longer 6) in their Best practices for assessing applications to be retired during migration.
I wanted to compare the R’s so we can advise our customers across all public cloud platforms. The truth is they are all similar with some common categorisations, however, there are some differences that confirm, cloud migrations are complex!
Here is a comparison between the different approaches that I have referred to in this article. We can see that for five different vendor approaches, there are actually 11 Rs. If we were to include the further variants from Gartner and AWS, that would increase to 12 R’s with the addition of Relocate by Amazon and 1 non-R, with Encapsulation being added by Gartner.
Some of them are ever-present, with Rehost appearing in all of the approaches, Refactor does appear in all approaches also, however, Refactor in the Microsoft Cloud Adoption Framework is slightly different, with a focus on moving to PaaS services such as Azure SQL or Azure WebApps. Rearchitect for Microsoft is a new cloud-native build. AWS blend both Refactor and Rearchitect as the same option (represented by a lighter shade of green), similar to Microsoft’s Rearchitect.
Replatform does not exist in the Microsoft 5 R’s, yet this is a very common categorisation that we use to address technical debt and plan a change to the underlying platform such as an Operating System upgrade or a database release upgrade. Some R’s have common results such as Remain or Retain, the same could possibly be said about Replace or Repurchase. I think the takeaway from this is, that there is a common agreement that categorising applications against “x R’s” is a really powerful tool to assess your applications and migration requirements.
The one point that is not covered is probably the most important in the cloud migration journey. The business drivers and budget for the migration are really the defining factors in how you would categorise your applications. Everybody would like to Rearchitect all applications with cloud-native designs to introduce availability, scalability, and cost savings but is there the time or budget to achieve this, the answer for most migration projects I have been involved in is “no”.
Large-scale datacentre migrations are generally driven by compelling events such as datacentre contract renewals, hardware renewals, or technical debt. Datacentre contract renewal dates tend to result in projects with very high levels of Rehost categorisations which is the fastest way to move, however, this does not realise true cloud value. Allowing enough time for planning for such events can enable migrations that can make strategic use of all the migration R’s and get the maximum value from your budget.
Understanding your timelines and budget will really define which of the 5, 6, 7 or 11 R’s you choose for each application.
About the Author
Daragh McCormack is currently Cloud Practice Lead for Version 1’s UK Digital, Data & Cloud practice. Follow Version 1’s Medium publication for more Cloud, Digital and Data related blogs from the practice.
Read here about Version 1’s Cloud Migration Factory Service Offering.
