7 Rs of Cloud Migration

Following on from my previous post about planning the migration of legacy enterprise applications into the cloud, one of the things I mentioned was the 5 Rs you needed to consider when you were carrying out your planning. This is a process of evaluating your existing estate and trying to determine the best way to migrate or modernise your workloads so that you can get the best return on investment once you move to the cloud.

Microsoft says there are 5 cloud migration R’s whilst Amazon likes to throw in an extra two for free.  However, they’re ostensibly designed to get you to the same point

R1 – Rehost

This is what we normally refer to as a “lift and shift”.  The basic premise is that you take what you currently have and move it to a new location with minimal changes to how it all works.

This is the quickest way to migrate your workloads and is normally used if you want to move to a new hosting provider/datacentre/cloud in the shortest amount of time.  The method is often used when hosting contracts are coming to an end, in the event of company divestments or any situation where time pressures are a concern.  The main benefits are that it is fast, reasonably low risk and doesn’t require you to retrain your IT staff on how to support a whole new infrastructure.

The downside to this method is that you don’t necessarily make the best use of Cloud technologies and, as a consequence, can end up paying more than is strictly necessary.  You also carry across any issues that exist in your current environment, such as underlying guest OS or application issues.

The final thing to consider when looking at this method is resource consumption.  One thing that is often missed as part of a lift and shift migration, especially from a traditional on-premise environment to the cloud, is that you will now pay in a granular way for the resources consumed; having a Virtual Machine (VM) on your own infrastructure that is vastly overprovisioned wouldn’t have any commercial implication, however, you will suddenly be on the hook for the unused resource if it is replicated “as is” into a Public/Private/Hybrid Cloud.  This is why it is important to “Right Size” any workloads using a process of constant monitoring and assessment.

Examples of services you may see include:

ACS – Aspire Cloud Services
ACS Migration

Azure Compute
Azure Migrate

AWS Elastic Compute
AWS Migration Services

R2 – Refactor

The second option to consider is whether you can refactor your workload to take advantage of some of the more “Cloud Native” methods of doing things.  This will generally refer to utilising Platform as a Service (PaaS) offerings but can also allude to a more comprehensive rearchitecting of application code.

I have already covered some of the different Cloud options, including PaaS, in an earlier blog post.  However, the main benefits of doing this are that you’re removing the operational element of deploying and managing a VM and all that comes with it (OS Security, Patching etc.) and putting that onus on the Cloud provider.  This makes it not only more cost effective from a management overhead perspective, but also lets you access resource in a way that allows you to only pay for exactly what you use, allowing you to quickly scale up and down operations without committing to under-utilised resources.

Examples of services you may see include:

Azure SQL
Azure Logic Apps
Azure Functions

AWS Relational Database Service
AWS Elastic Beanstalk
AWS Redshift

R3 – Rearchitect

Sometimes you will use applications that are developed in-house or have been made specifically for you.  When moving to the Cloud, these legacy applications are not always compatible with the Cloud way of working.

Rearchitect and Refactor are very similar (and are often merged into one), the main difference being that when rearchitecting your application, you’re rewriting the code to take advantage of Cloud Native technologies (for example, changing from a Monolithic to Microservices based architecture).

Examples of the services in this area are the same as those listed for Refactor.  However, it also enables the use of the full suite of Cloud native capabilities such as High Availability, CI/CD Pipelines for deployment, containerisation, auto-scaling etc.

R4 – Rebuild

Sometimes Rearchitecting/Refactoring your application isn’t enough.  In these instances, it is often necessary to start from a clean slate and develop a new cloud native code base from the start.

Instead of trying to retrofit legacy code into a Cloud Native format, a rebuild will allow a bespoke application to be created from the ground up to take full advantage of the Cloud.

This is a costly method and one that is (usually) out of reach for organisations that don’t have their own (or outsourced) development team. However, it is the method that allows you to maximise the benefit of using the Cloud and to take advantage of the cutting edge services that Cloud vendors provide.

You would use this method if you can’t make your legacy application function well in a Cloud environment or if you wanted to “SaaSify” your application – i.e. provide it as a service either internally or to your own customers.

R5 – Replace

Sometimes an application or process is no longer necessary or can be handled in a better way.  A good example of this would be email.

It wasn’t too long ago that the majority of organisations had their own Microsoft Exchange Server infrastructure in their datacentre; the platform was responsible for all of their Email, Calendaring and scheduling across an entire organisation.  In large organisations, this could involve multiple servers, dedicated storage and hosting in multiple datacentres in order to provide the resilience and uptime that is required of such a core enterprise service.  On top of that, dedicated Exchange administrators were often required to keep the system secure and performant.

Now, all that can be achieved by moving to Microsoft 365.  This SaaS platform will give you a resilient, multi-datacentre email/Calendaring platform with all the benefits of Exchange and few of the drawbacks.

A lot of the actively exploited, high profile security vulnerabilities that have been identified in the last few years have been found in Exchange server deployments (such as those that affected Rackspace at the end of 2022).

Examples of services you may see include:

Microsoft Office 365 (Microsoft 365)
Google Workspace

As mentioned at the start, Amazon like to throw a couple of extra Rs in for free, so we may as well cover them off as well!

R6 – Retire

Sometimes you just don’t need applications that run in your environment anymore.  In on-premise environments, where resource is often procured with Capital Expenditure months or years in advance, an application can sit unused on a virtual machine with no need to pay extra for it.  However, once you move that VM to the Cloud you are paying for it whether it is in use or not.

For that reason, it is a good idea to clarify whether something is required and in use before you start your Cloud migration.  If not, you should retire it, otherwise you’ll be paying on a monthly basis for something you don’t need.

R7 – Repurchase

Repurchase is a bit like Refactor/Rearchitect/Rebuild for those organisations that don’t have their own development teams.

It is not uncommon to see companies deploy a version of software that runs their enterprise and then continue to run the same version for years, even when the vendor has released a newer version that can take advantage of Cloud Native technologies or even run as a SaaS application.

In these situations, it is often better to purchase the new version of the software and, if possible, migrate to that instead of trying to shoe horn a legacy application into the Cloud.

Conclusion

The above gives a brief overview of the kind of things you should think of when approaching the analysis phase of a cloud migration.

It is important to remember that you don’t have to have completed all the migration analysis and planning before you start your migration.  This is an iterative process and can often take a protracted period of time.  You can’t allow yourself to become paralysed because you don’t think you’ve managed to analyse every application you’ve got – Don’t let perfect become the enemy of good.

As a rule of thumb, if your motivation for moving your workload to the cloud is innovation, you should start off from a position of Rearchitect.  However, if you’re motivation tends towards migration (from an existing platform/datacentre due to a contract ending for example) then starting with a Rehost mindset is a good starting point.