With the popularity of cloud one of the key considerations for companies is how to go about migrating their legacy applications to the cloud. One common approach to classify the migration options available is to use the 7 R’s notation. They provide an easy way assess and approach migrations. A word of caution here, although the 7 R’s make it sound simple and straight forward to start a cloud migration, it is anything but. They are just meant to be very high-level guide lines on how to start thinking about the process of moving to the cloud. They are also not meant to be mutually exclusive where if you pick one, it has to be used for all aspects of the migration process. In fact in my experience every application requires a mix of these Rs when performing the actual migrations as different parts of the application infrastructure need to be approached differently. So what are they:

• Retire
• Retain
• Relocate
• Rehost
• Repurchase
• Replatform
• Refactor

Retire

When it comes to the point of performing a cloud migration, it offers the perfect opportunity to re assess if certain applications or components in applications are actually required. Often organisations have technical debit that exists because there has not been an opportunity to perform such a through assessment of the suitability or need for applications or part of applications. Hence one of the first things to look at is if these legacy applications or components can be Retired.

Effort wise this is probably the easiest of the Rs to attempt.

Retain

Although the hope is to migrate most applications to the cloud, the reality is there are often situations that result in the migrations to the cloud not being possible for creating applications or components. This could be the result of any of the following:

• Lack of compatibility between legacy code and cloud infrastructure
• Complicated Licensing
• Requirement of Multicast Networking (AWS supports multicast in a limited way and there is also option of overlay networks but that can get too complicated)
• Prohibitive cost
• Certain mainframe applications (AWS supports mainframe migration and modernisations via Microfocus and Blu Age and Google Cloud has G4)

Such applications/components then have to be Retained on premises and continue to be used. Effort wise this R is probably the same as Retire.

Relocate

This is the first of the R’s where we are starting to look at actual migrations to the cloud. Most organisations are using some form of hypervisor/virtualisation technology (for example: VMWare) or containerisation technology (for example: Kubernetes). Most cloud providers have the ability to run these natively in the cloud. This is where you take the on-prem application running in a VMWare or Kubernetes environment and Relocate it directly into the cloud on the same environment with minimal to no changes to the code or functionality.

Rehost

This often also referred to as Lift and Shift. A bulk of legacy migrations fall within the Rehost or Relocate categories. This is where you can take an existing on-prem solution and just build the basic matching infrastructure in cloud (EC2 instances or GCE VMs) and move the application binaries to just run on this matching cloud infrastructure with minimal to no changes. It is often the quick and dirty solution to moving applications to the cloud with minimal changes and effort. Most cloud providers have tools to automate this as well:

• AWS Server Migration Service (SMS)
• Google Migrate to Virtual Machines
• Azure Migrate

Repurchase

Often a limiting factor when dealing with a cloud migrations for legacy applications is licensing of components especially when the licences are very restrictive. If an organisation is willing to change these licenses then they can opt for a Repurchase. This gives the option to switch to a completely different product that is more cloud native (SAAS) but performs the same function. An example could be to move from self hosted CRM to Salesforce.com

Replatform

These final two R’s are where the bulk of the action is so to speak. Replatform is a bit like rehost with some tinkering and modifications performed to the components so they can take advantage of the optimisations offered by the cloud providers. Replatform involves assessing the Database, Operating System, Web Server, Load Balancers etc services and opting for cloud optimised versions of equivalent services offered by the cloud providers. Some of the key considerations are:

• Code changes could be required to make things work with the new services
• Automations is key and needs to be looked at in every part of the development and operational lifecycle
• Security should be looked at every level and every component

Another aspect to consider is if the cloud provider has certain native managed services that are automatically providing the features that these applications or components provide. Examples of this are:

• Local DNS
• Load Balancing
• Simple Message Queues
• Centralised Logging
• Audit Capturing

Refactor

This strategy involves the most change to the applications architecture, infrastructure, code, and configuration. It also requires a lot of investment time, effort, and money. In the long term it brings the most benefit of moving to the cloud as the application can finally take full advantage of all the services and features offered by the cloud that are not available in a on-perm environment. After a Refactor, an application can benefit from being serverless, cloud native, auto scaling, having reliability, agility, and devops to name but a few. From a Total Cost of Ownership (TCO) perspective this can have the largest impact as you can truly maximise the benefit of the cloud.