Destination Points: six ways to differentiate an application transformation project

Having completed a feasibility study and built a Cloud Centre of Excellence (CCoE) team, the next step is to define what will happen with each workload. The beauty of Cloud infrastructure is that you can mix and match services to meet the needs of your business and it’s customers. But it helps to understand the various approaches and how they might apply.


To help classify these options, the Cloud industry uses the '6 Rs':

1. Rehost

The easiest of all Cloud migration models, and also the most likely to cause problems, increase costs, and alienate key stakeholders. Rehosting (also known as “Lift and Shift”), simply replicates an existing system on Cloud infrastructure.

This approach has the advantage of being quick and simple, but it also means that any inefficiencies or failings are transported into the Cloud as well. Many of the negative experiences reported about Cloud migration projects are because businesses chose re-hosting without fully evaluating the impact of that decision.

2. Re-platform

Re-platforming involves some degree of business analysis to identify processes and services that could be divested from your operations. Partnering with Cloud experts provides an opportunity to reduce costs and operational overheads – and to take full advantage of technologies that are probably little known or understood.

Switching to managed services facilitates a relatively swift move to the Cloud without having to heavily re-architect the application/workload. That's why this 'R' is sometimes called "Lift and Tweak".

3. Re-purchase

As the name suggests, you simply repurchase the SaaS version of an existing application you already rely on. Microsoft Exchange? Switch to Office 365 and get Exchange functionality included. Microsoft Dynamics ERP? Change over to Dynamics 365.

Initially, it’s likely your CFO will push back on buying something you already have, but there are good reasons to convince him or her that it is the right thing to do. First, SaaS is normally licensed per user per month, so you switch from CapEx to OpEx spending models and never pay for anything you don’t use. Second, on-site applications are a drain on internal resources, but switch to SaaS and it is the hosted application provider’s responsibility to keep systems up-and-running. In other words, you can create significant cost savings by removing these infrastructure management overheads.

4. Refactor

The most advanced – and initially costly – of the migration approaches, refactoring involves re-architecting applications and processes to take full advantage of Cloud technologies. Instead of creating a hosted virtual server to run an application, you containerise the software, and/or hook it into cloud-native services.

Yes, you have to redevelop an app (sometimes from scratch), but this approach ensures that Cloud resource usage is minimised, bringing greater control over billing. It also allows you to better scale the application and supporting services and data sets without the overheads of managing a farm of virtualised servers.

5. Retain

In some circumstances there won’t be a compelling reason to migrate a system to the Cloud. This could be because of existing licensing conditions (like hardware license keys), or general incompatibility with Cloud operating platforms.

In these cases you retain the application as-is. This is not a failing of your migration strategy – it’s a mature understanding that not everything belongs in the Cloud. There are still savings and improvements to be made elsewhere – funds that may be used to replace the retained systems at some later date.

6. Retire

Perhaps one of the most satisfying aspect of Cloud migrations. This is where you finally power-down some of the systems that have been draining budget and resources because they are no longer required.

Repurchased systems are an obvious candidate for being retired. Basically, anything that is no longer being used can finally be powered down and disposed of.

Mix it up

In all likelihood, your business will need to use a combination of these approaches to start your Cloud migration process. Rehosting infrastructure will get the ball rolling, but it won’t continue to deliver savings and efficiency in the long term. Refactoring is likely to be a significant investment, best spread over years according to funding availability.

Which brings us back to the importance of understanding your current IT and how it is used. Only then will you be able to properly specify how (or if) to migrate each application and service for maximum effect.

Key takeaways:

  • Rehosting is the quick and dirty option. This approach is only suitable in a small number of specific cases.
  • Re-platforming allows you to reduce infrastructure and begin the transition to an OpEx finance model.
  • In some cases, repurchasing Cloud versions of existing systems makes good business sense - even if the FD disagrees initially.
  • Refactoring applications is expensive initially - but engineering for the new Cloud infrastructure model will deliver significant long-term benefits.
  • Sometimes you may have to retain older legacy systems, and that may actually be a good thing.
  • The ultimate goal of Cloud re-engineering it to retire unwanted systems and applications. Keep your plans focused on achieving this.