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.