Choosing a Cloud migration strategy for applications

Inadequately migrating applications from on-premises to the cloud can completely waste the financial and practical benefits cloud offerings – both in the short and long run. That is why every cloud migration roadmap needs to define a clear migration strategy for every application that is based on a holistic application assessment. This assessment should not only take into account technical aspects but also business, organization, security, and compliance. The selected strategy fundamentally affects the expected migration effort, the potential amount of benefit of using the cloud, and possible long-term cost savings of the new operations model.

Essentially, you can think of each “R” as an available migration strategy for your applications. Each strategy indicates a clear outcome for a transformed application, but not necessarily the actual migration steps to take. The concept was first mentioned by the Gartner analyst Richard Watson in 2011. The 5 original strategies – namely the rehost, refactor, revise, rebuild and replace were revived and adapted by AWS in 2016. AWS kept some of Gartner’s strategies, renamed some and added a new one. The approach has been made public and became popular. Thus, the 5 R’s became the 6 R’s. Today, the 6 R’s are used as a fundamental guideline for almost any cloud transformation. Although there are still disputes about whether further strategies should be added, in this document we are just going to cover rehosting, replatforming, repurchasing, rearchitecting, retire and revisit.

This strategy, commonly known as lift-and-shift, is a widely chosen strategy due to the relatively low migration effort. The virtual machine and the application that runs in are simply copied as-is to a cloud provider. The most important benefit of this strategy is migration speed because no architectural refactoring needs to be done. Moreover, the migration can often be done automatically using a variety of lift-and-shift or so-called workload mobility tools.

However, the rehosting strategy has a major drawback. Using this approach it is not possible to exploit the cloud's entire potential since the applications are not built in a cloud-native fashion. Simply rehosted applications are, compared to cloud-native applications, not decoupled from the operating system and are usually much more difficult to scale. Experience shows that from a cost perspective rehosting usually does not lead to any major advantage.

In contrast to rehosting, replatforming leads to cloud optimisation due to some cloud platform adoption, while keeping the application core architecture the same. Replatforming requires deeper insights into the application or the virtual machines to be migrated than rehosting but does not lead to the complexity and effort typically associated with Rearchitecting. replatformed applications show some cloud-native characteristics like horizontal scaling and portability. Often, replatforming is used when replacing database backends of applications with a corresponding PaaS database solution of a cloud provider.

We recommend using the replatforming strategy if you want to take advantage of cloud with improved scalability, elasticity, cost and performance, but cannot invest the required resources and effort to re-architect the application. But be aware of potential vendor lock-in, particularly for databases and middleware technologies.

For highly critical applications that require cloud-native characteristics or applications that need thorough modernisation due to outdatedness or performance issues a higher migration effort is typically profitable and hence should be part of cloud considerations. Re-architecting (also called Refactoring or Rebuild) is the strategy that usually leads to the highest transformation cost. However, it allows optimised use of the cloud, leading to cloud-native benefits and making the application future-proof. In doing so, the affected application is refactored using an alternative application architecture. Typically this involves breaking down the application’s components into smaller building blocks, microservices and wrapping them into (Docker) containers for deployment on a container platform.

Re-architecting an application often comes along with the opportunity to even break down the supported business processes into fragments, which greatly improves the simplicity and makes a business process more agile.

The retire strategy means that an application is explicitly phased out. This makes sense when the business capabilities this application provides are not needed anymore or are offered redundantly. We see this often in those cases where organisations recently went through mergers and acquisitions. You should take the cloud transformation project as a welcome opportunity to screen your application portfolio and reduce obsolete applications on the go.

Revisit (also known as retain) means that you do not migrate the application at this point since you are lacking important information or are hindered by other factors. For some applications, a move to the cloud just does not make any sense. For example, due to latency requirements, compliance reasons, or simply because the benefits of a migration won't outweigh the cost and effort to be invested. You should, however, always set yourself a reminder to “Revisit” the application because the technical or compliance landscape might have changed.

Repurchasing (also called replacing) is the strategy where the legacy application is fully replaced by a SaaS-solution that provides the same or similar capabilities.

The migration effort heavily depends on the requirements and options of migrating (live) data. Some SaaS-replacements for on-premise products from the same vendor offer an option to quickly migrate data with little effort or even automatically. Some providers offer analysis tools to assess the to-be-expected migration effort. However, this might not be the case when switching to a product of a different vendor or if the migration path has been interrupted due to neglected maintenance of the on-premise application.

Categorising your workload to identify the approach to migration on a per-application basis is an essential tool for migration planning and brings structure into a data lead decision process. There are a number of challenges associated with categorising workload including the implications to dependent applications. As the assessment process is something that individual organisations will have limited experience of, we recommend engaging with an organisation who have experience in this area. We also recommend putting in the necessary effort. Good decisions made at this stage will reduce the effort at migration time and allow you to get the most out of your cloud transformation.