6Rs of Cloud Migrations

14 min readMay 12, 2022

There are 6 common paths to migrating applications to the cloud — commonly known as the 6Rs:

Rehost — lift and shift the app, making as few changes as possible, likely using some kind of virtual machine import/export tooling
Replatform — make a small number of changes to take advantage of “low hanging fruit” cloud benefits, perhaps moving to consume some cloud provider managed services like databases or queues
Refactor/rearchitect — making significant changes, perhaps from the ground up, taking full advantage of the cloud providers managed services and building in a cloud-native way
Repurchase/replace — binning the application, replacing it with a SaaS service
Retire — just binning the application, and not replacing it
Retain — meaning do nothing for now, ideally because other applications are higher-up the list of priorities, and come back to this one at some point in the future

This post is going to look at each of the 6Rs in more detail, reviewing pros and cons, and asking which migration methods the different kind of cloud stakeholder is going to prefer.

Disclaimers:

There are very blurry lines between Rehost, Replatform, Refactor/Rearchitect and they should really be considered parts of a continuum running from Rehost = “change it as little as possible” to Rearchitect = “Rewrite it from the ground up”: and it is likely there will be a couple opportunities for rearchitecting on even the most list & shifty migration.
It’s not worth arguing about whether to call something is a Rehost or a Replatform — instead worry about whether the proposed migration meets the stakeholders needs
There is no suggestion any of these options is better or worse than the others. They are simply different options, with different strengths and weaknesses appropriate for different scenarios
None of the options are the endgame. There will always be maintenance, future enhancements, defect fixes, tech-debt and other opportunities for further work.

Rehost

The concept is to minimise effort, risk, time, transformation (and thus: benefit), typically picking up a set of virtual machines and “lift and shift” them into an IaaS based cloud environment, or running a physical to virtual (p2v) conversation process to get the machines running in that IaaS based cloud environment. Either way, it’s likely to be done with tools like the AWS Server Migration Service, and the target environment is going to look an awful lot like the source: same number of instances, same operating system same COTS products, same version.

Some tinkering may still be needed, for example:

Changing from physical networking equipment like firewalls and load balancers, to the cloud providers software defined alternatives like security groups and ELBs
Updating DNS entries, repointing monitoring, swapping over monitoring and management agents to cloud based alternatives
Right-sizing the infrastructure to use the required amount of CPU, Memory and instances
Updating deployment and operational guides
Moving and activating COPTS product licence keys
Regenerating key material, admin passwords and TLS certificates

This will suit systems that are:

In relatively good shape (stable, working, patched) — because rehosting doesn’t provide for patching/version upgrades, or tech-debt reduction, or significant new features
Cloud friendly (you generally can’t run Solaris, AIX or VME in the cloud, running Oracle RAC in AWS is painful, some licences prevent cloud hosting)
With a relatively static load — because rehosting doesn’t bring the elasticity benefits needed to respond to dynamic load
That are manually deployed — because rehosting doesn’t rewrite CI/CD pipelines, it just moves virtual machines around
That need a FAST move to cloud (e.g. because their datacentre has been condemned) and after the rehost programme completes, modernisation is planned to make the application more cloud native: taking advantage of cloud elasticity & resilience, or using managed services to speed delivery and reduce operational overhead.

The process is going to be quick, following a 5-phase approach:

Discovery: Where you understand what is out there:

Identify what machines are out there; what they talk to; what operating systems with what software and what versions; who uses them & for what
Identify where the applications are being migrated into and what those landing zones provide / what the application expects
Identify the wider requirements: including what data security/sovereignty requirements are in play, when can applications take down-time

Analysis, Design and Planning: Where you figure our how rehosting is going to work, or if you need to punt the application to replatforming or rearchitecting (etc), understanding:

If the applications will work in the cloud unchanged (e.g. CPU architecture, operating system, licencing)
How the migration tooling will be used to provision the infrastructure and all associated data into the cloud
What changes the landing-zones need to receive the applications: e.g. support for the applications flavour of Windows/Linux, additional security controls aligning to what was available on-prem
What changes the migrated applications need — updating DNS entries, pointing to different active-directories, applying new licence keys, swapping out monitoring agents or repointing them to the cloud-based management servers
What changes the wider enterprise environment needs — updating monitoring to point to the new application, audit and compliance changes
How the application needs to be tested (functionally + non-functionally) and the state of existing test scripts / data (can they be reused / must it be recreated)
Who the users and operations teams are, and what support they will need post migration
How the wave-plan must be updated, showing the timelines for which applications move when & dependencies between them
How the detailed migration plan for this application must be structured to deliver the migration

Execution: where you do the migrations in dev/test/production, checking it works, providing early live support while the snags are addressed, and feeding lessons learn back into the previous phases.

Transition: where you hand the migrated applications over to their support teams.

Clean up: where you decommission the old on-premises infrastructure, and archive the old applications and data — you do this post migration, so when everything goes pear-shaped you still have a working application to fall back to!

Replatform

This approach is very similar to Rehost, but it caters for more invasive change, and rather than doing a lift and shift (copy the VM), the application will probably be redeployed by updating its existing CI/CD pipelines, or through creating CI/CD pipelines for the first time. Rather than describe the whole thing, I’ll focus on the differences.

Typical items to tinker with:

Changing operating systems and CPU architectures to match the commodity services in the cloud — usually x86 or ARM CPU, running the latest versions of Windows or Linux
Tech-refreshing COTS products and libraries like Java, Tomcat, and Log4j, so that the latest mainstream supported versions are in use
Replacing COTS products like databases, message queues, monitoring and container orchestration with the cloud providers managed services like Aurora, SQS, CloudWatch and EKS — potentially using conversion tools like the AWS Database Migration Service
Replacing or at least refactoring the CI/CD pipelines in dev/test/production to deploy to the new infrastructure
Reworking quality assurance approaches to be fully automated and cover static code quality/lint/complexity analysis, functional testing, non-functional testing, integration testing, and security vulnerability scanning.
Incorporating defect fixes, capacity right-sizing and even functional changes

This will suit systems that:

Can accept the time, effort, cost and risk to required to implement a replatforming, and are likely to be used for a sufficiently long enough period to pay back the investment
Require more signification modernisation, or tech-debt repayment in order to facilitate the migration
That carry significant operational overheads that can be removed through the consumption of managed services

The process is going to look similar to rehost, in that it’s a 5-phase approach, but the differences are:

Discovery: No huge changes — you still need all the facts on which to base decisions

Analysis, Design and Planning:

Much more effort is needed, to understand each improvement, its impact/risk and how it is to be tested & accepting there will be several improvements likely to be delivered over a multi-phased roadmap
More funding will be required, more resource needed, and timelines will be longer
More consideration will be given to the target landing zones, and the services they must offer
More stakeholder management will be needed to explain the benefits of the changes, and ensure all stakeholders are bought into the migration, and their needs are met

Execution

There are likely to be several execution phases over several weeks, each delivering part of the migration
Much more effort is needed, to carry out the migration and test that the system operates correctly, with no loss of functionality/performance/resilience/data/etc
The migration will not be carried out by lifting and shifting VMs — new infrastructure will be provisioned, and application code will be deployed via CI/CD.
Data migration will become a big issue (the database isn’t just being lifted/shifted alongside the other VMs), thus data will need to be exported, cleansed, transferred, and reuploaded in a secure manner — if data cannot be incrementally exported and “topped up during the final migration” the outage needed to carry out migration may take many hours

Transition: Will require more effort to explain the changes, and up-skill the support teams on the new technologies and designs

Clean up: Is pretty much the same: decommission the old on-premises infrastructure, and archive the old applications and data (both original and cleansed data)

Refactor/rearchitect

This approach is very similar to Refactor/replatform, but it caters for much more invasive change, and rather than tinkering with the application, it will see significant changes, likely being broken up into microservices to better leverage the cloud native services of the cloud provider. Rather than describe the whole thing, I’ll focus on the differences.

Typical items to rearchitect:

Going beyond the consumption of infrastructure based managed-services and the cloud-hosted server-based mentality (i.e. IaaS), to consuming fully elastic, serverless solutions
Breaking up the monoliths into microservices, making much more use of containers, or step-functions, and adopting an event based model to manage messaging through the system
Having those microservice each master their own data, and control access to their functionality through versioned APIs — allowing each microservices to be changed/released independently
Changing the release mentality further, allowing change to be deployed multiple times each day — rather than the bi-annual “enterprise release”
Breaking out the AWS Well Architected Framework, and fully implementing its receomendations

This will suit systems that are:

Can accept the significant time, effort, cost and risk to required to implement a rearchitecting, and are likely to be used for a sufficiently long enough period to pay back the investment
Require very signification modernisation, or tech-debt repayment in order to facilitate the migration
That carry significant operational overheads and workload variability that can be addressed through the consumption of managed services

The process is going to look similar to replatform, in that it’s a 5-phase approach, but the differences are:

Discovery: No huge changes — you still need all the facts on which to base decisions

Analysis, Design and Planning:

Much more effort is needed, to understand each improvements impact/risk and how it is to be tested & accepting there will be many improvements likely to be delivered over a many-phased roadmap
Much more funding will be required, more resource needed, and timelines will be longer
The application architecture is likely to shift over to an event-based approach, with business logic and partitioned into discrete microservices each mastering their own part of the data model. Idempotence, message replay, and using eventual consistency to reconcile changes to the data from multiple sources will become vital.
More consideration will be given to the target landing zones, and the services they must offer
Much more stakeholder management will be needed to explain the benefits of the changes, and ensure all stakeholders are bought into the migration, and their needs are met
Risk is much higher as the changes are very invasive, but so too are the benefits

Execution:

There are likely to be many execution phases over an extended period (months or years), each delivering part of the migration
Much more effort is needed, to carry out the migration and test that the system operates correctly, with no loss of functionality/performance/resilience/data/etc
The migration will provision new services in the cloud (many of which will be serverless) using very heavy automation, IaC driven by CI/CD pipelines.
Data migration will become an even big issue: its not just export/transform/load, rather the data is likely to be distributed over a number of microservices

Transition: Will require more effort to explain the changes, and up-skill the support teams on the new technologies and designs

Clean up:

Becomes a multi-phased challenge as the application migrates to the cloud, and evolves over many phases as the architecture progresses.
The endgame remains the same: decommission the old on-premises infrastructure, and archive the old applications and data (both original and cleansed data)

Repurchase/replace

Repurchasing: AKA replacing with a SaaS service

Certain application needs are so common across many so many businesses they have become commoditised, and are available to purchase on a SaaS basis from many vendors:

User management? Stop running your own directory services and consume AzureAD from Microsoft
Day to day collaboration? Stop running your own exchange & messenger, and consume Office365 from Microsoft
Developer collaboration? Stop running your own Jira, and Git, and consume Atlassian Cloud, or Github, or Gitlab

There are many other SaaS providers, but the value propositions are very similar: “you get no business benefit from managing your own X, therefore just consume it as a fully managed service from Y”. The repurchase option applies this option to a cloud migration. It is used to identify the SaaS alternative, commission it, migrate the data across, prove it all works, and engage with the end users to ensure they are bought into the replacement, that the replacement meets their needs, that they understand when the change happens, and thay they have been retrained to use the replacement system.

The replacement may not be like4like: it’s usually better to bend business processes to fit the vendor recognised way of working, than to bend the SaaS product to fit a way of working for which it was not designed. If the business process cannot bend, to fit the SaaS product, then it’s the wrong SaaS product! It might also not be a 1:1 repurchase. 80% of the application might be replaced with SaaS, leaving 10% to be rehosted and 10% to be retired.

Delivery process will follow the approach outlined above:

Discovery to understand what is out there, and ensure the SaaS service will meet all requirements (including compliance and data security)
Analysis, design and planning, to work out how to conduct the migration
Execution, to complete the transfer from the existing service to the new SaaS
Transition, explain the impact to support teams
Clean up, to archive off the old application and data

Retire

Retire recognises that some applications have just reached the end of their useful life and are no longer required, so they can be shut down, and neither replaced or migrated. It’s a simple option, that usually needs a slot of stakeholder management, as nobody likes being told the thing they do is no longer needed. However, if everyone can agree, the data can be archived and the app shut down.

This option isn’t nuclear: the application data is likely to be placed in long term storage (e.g. Glacier) where it can be accessed/searched if needed using tools like Athena, and the application source code will be retained in similar long term storage, should it ever be needed. It also doesn't have to be all or nothing: 50% of the application could be retired, 25% rehosted and the remainder replaced with a SaaS.

Delivery process will follow the approach outlined above:

Discovery to understand what is out there, and ensure the SaaS service will meet all requirements (including compliance and data security)
Analysis, design and planning, to ensure the application can be retired
Execution, to complete the retirement, turning off the system
Transition, to stand down the operations team
Clean up, to archive off the application and data

Retain

On the face of it, retain is the easiest of the options, it’s essentially do-nothing in terms of cloud migration, leaving the applications running in the existing on-premises datacentres, with their current mix of software, servers, networks and storage equipment. This can be great holding position, allowing:

Focus to be given to other applications with a higher business priority to be migrated
Landing zones and hosting platforms to be created in advance of migration
Migration blockers like data security/sovereignty/compliance issues to be addressed
Investment cases for cloud migration to be created, and for funding to be secured

However, Retain is unlikely to be sustainable in the long term. The exiting hosting environment retain their “feeding and watering” needs — long lists of projects applying patches, upgrades, maintenance and occasionally swapping in spare parts. Completing such maintenance gets harder each year: the supply of spare parts dries up for legacy hardware (mainframes, midrange), software vendors end-of-life older versions so stop producing the patches needed to maintain compliance with security regulations, the staff who know how to maintain the software and infrastructure retire, and new joiners all want to work on the new & sexy systems in the cloud. All these costs must still be covered, by the ever-shrinking pool of lower-priority retained applications.

Meanwhile the cloud continues to advance, bringing new features that remove common barriers to migration: better security controls, better scalability and elasticity, better speed of delivery, avoidance of the risks of running your own datacentres, managed services reducing operational overhead & risk, and larger pools of skilled people — meaning retain starts to be associated with larger opportunity costs. So, sooner or later the costs of retain hit an inflection point (e.g. the datacentre requiring significant capital expenditure to upgrade the air-con) and so the business case for retain ceases to be viable, and an expedited programme of Rehost/Retire/Repurchase is undertaken. But in the meantime, Retain is a useful way to buy time to migrate more urgent applications and prepare landing zones.

Summary

This post looked at the 6 common paths to migrating payloads to the cloud — commonly known as the 6Rs:

Rehost — suitable for lift/shift of infrequently changing applications, or where there is a business imperative to get it done ASAP
Replatform — taking more effort than rehost, but starting to gain more benefits from the cloud
Refactor/rearchitect — doing a major rewrite to take full advantage of the cloud
Repurchase/replace — moving away from managing the application yourself
Retire — moving away from the application all together
Retain — prioritising other applications, or just holding off a migration until conditions are more favourable

The first 4 options get those payloads running in the cloud, but will appeal to different kinds of stakeholder. Of 3 kinds of cloud migration stakeholder:

Investors are more likely to use the Rearchitect and Repurchase methods, — because they want the benefits of Cloud Native
Optimisors are likely to start with Rehosting but then quickly follow up with a some Replatforming and Refactoring — because they like the sound of Cloud Native but don’t yet have the stomach for it
Migrators are likely to stick with Rehosting, with a pinch of Retire/Retain — because they prefer the stability of Cloud Hosting

Or in other words: the big benefits from the cloud (elasticity to cope with demand shifts without breaking the bank, managed services to reduce operational overhead and increase delivery velocity, resilience to outages, and access to the latest innovations) come from the more invasive changes — from rearchitecting and repurchasing, so as always you get what you pay for, so choose wisely.