What are the 6 R’s of Cloud Migration?

Cloud Migration
Voiced by Amazon Polly

When looking to migrate your on-premises IT infrastructure and applications to the public cloud, there are 6 strategies that you can adopt. It is important to analyze your existing application portfolio and categorize
them against the 6 Rs so you can build out your public cloud migration plan.  The 6 Rs were originally devised by Amazon Web Services but are now widely adopted by cloud managed service providers regardless of the chosen cloud service provider.  So, what are the 6 Rs, and what does each one mean?

1. Rehost

I’ve listed Rehost first as this is the most common strategy employed by businesses looking to move their IT infrastructure to the Public Cloud.  Rehost is often also referred to as ‘lift & shift’ – it is the easiest way to get your on-premises IT infrastructure into the cloud, as it requires the least change to your workloads and ways of working.  When choosing to Rehost, you simply ‘clone’ your servers and move them to the cloud provider’s Infrastructure as a Service offering.  The Cloud Provider now manages the underlying hardware and hypervisor infrastructure, and you continue to manage the same operating system and installed applications.   This is a quick way to get your servers into the cloud, using well established tools provided by the Cloud Service Providers such as AWS Cloud Endure and Azure Site Recovery to copy server images to the cloud.

2. Replatform

With a replatform, rather than lift & shift your servers ‘as is’, you can take advantage of the cloud migration to update your operating systems or databases, for example.  It may be that you have outdated operating systems that are no longer supported by the cloud provider so replatforming is an essential pre-requisite to migration. Or it may be that you want to move from a commercially supported platform to an open source platform to further enhance your business case for moving to the cloud.  But you are only changing underlying services, whilst maintaining the core application code, so the architecture of your applications will not change.

3. Refactor

A refactor is effectively an ‘application modernization’ – changes to the application code to leverage cloud
native services.  It may be that you want to move away from server-based applications to leverage cloud provider serverless functionality, for example.  This is the most resource intensive option requiring significant input from your software developers – many businesses choose to rehost or replatform first to get some momentum behind their cloud migration, but there is a risk here that if you rehost or replatform an application that you actually want to refactor, the refactor will be deprioritized and the application modernization may never happen.

4. Repurchase

Many commercial off the shelf (COTS) applications are now available as Software as a Service (SaaS), so it may be that you want to move away from managing installed applications on infrastructure that you manage, to simply consume those applications as SaaS.  Or maybe you want to simply replace that application with a different product from a different vendor.

5. Retire

Some applications simply won’t be required any more, so it is important to identify these prior to migrating to the cloud, so that you do not end up paying for application infrastructure that is not delivering any business benefit.

6. Retain

Finally, there may be applications in your portfolio that are simply not candidates for a cloud migration, in which case they may need to stay put.  Maybe you just invested in brand new on premises infrastructure for some applications, so it doesn’t make commercial sense to move them, or perhaps you have a specific piece of software that the vendor refuses to support in a public cloud platform.  Nowadays there are fewer and fewer reasons to retain an application on premises, but this will really depend on your specific circumstances.

In order to categorize your applications against the 6Rs you’ll need to discuss and agree the strategy with each application owner and get their agreement on the strategy for their application. It is helpful to
have a top down organizational mandate when conducting this exercise so that application owners are aware of the business strategy in relation to cloud migration – this will help remove any barriers that may otherwise result in more ‘retain’ decision due to a reluctance or resistance to change.

If you need any help with Cloud Migration, check out our AWS Migration Service.

You Might Be Also Interested In These...

AWS Global Partner Summit

6 key Announcements from the AWS re:Invent Global Partner Summit

Today saw the AWS re:Invent Global Partner Summit Keynote delivered by Doug Yeum, Head of Worldwide Channels and Alliances at Amazon Web Services.  After showcasing partner solutions from Amdocs and partner successes with BP, there were a number of announcements, as you would expect from a Keynote!   Don’t have time to view the whole keynote?  […]

View Post
AWS Snowball

AWS Snowball: What Does Amazon’s Import/Export Appliance Cost?

AWS Import Export with Snowball Originally a single device used for migrating data into AWS, Snowball is now part of the AWS Snow family of services used for both speeding up data import and export to and from AWS, and for secure edge computing. The AWS Snowball family includes: AWS Snowball Edge Storage Optimized AWS […]

View Post
Logicata AWS Charanga Webinar Speakers

Webinar – Optimising Availability & Performance Of EdTech Applications With AWS

Learn how AWS And Logicata can provide Your EdTech with Reassurance, Speed/Agility, Reduced Cost, Improved Security & Increased Observability

View Post
ebook featured image

5 Steps to a Successful

AWS Migration