Well-Architected Design: Cloud Migration Strategy

Types of Migration

When considering the migration of workloads to new infrastructure, it is important to carefully consider and plan the process. There may be many interdependencies and specific application requirements that need to be addressed. Factors such as performance, availability, and backup requirements can vary widely between workloads and need to be considered. Additionally, other issues may emerge during the discovery phase, such as hardware dependencies or change management considerations. When classifying cloud migration types, a standard terminology has emerged and is referred to as the “6Rs of cloud migration”.

• Rehosting
• Replatforming
• Repurchasing
• Refactoring
• Retaining
• Retiring

There are also other options for consideration such as repurchasing as SaaS, retaining, or retiring applications. The use of these methods will depend on the specific needs of the organization.

Rehosting

Rehosting is perhaps the simplest form of migration. This migration type refers to moving workloads from one location to another. Typically this relocation is from on-premises hardware to a cloud platform. It can be achieved by reprovisioning from scratch, cold migration, or live migration. Rehosting may also be referred to as “Lift and Shift” or “Relocating”.

Cold Migration

When performing a cold migration, a workload is stopped, moved over to your cloud solution (for example a VMware Cloud SDDC) and then restarted there. During this process, VMs are powered off and data is migrated in a 'cold' state (without change) to the new infrastructure. This is to ensure data integrity is protected throughout the migration process. Additionally, if a backup is taken before the migration any issues on data transfer are mitigated. Checksums can be compared before and after the migration to ensure data integrity is intact. However, it is not always practical to stop business activity for the duration of the migration and therefore not all workloads cannot be migrated in this way. Applications that cannot tolerate downtime or interruptions in availability (including a reboot) cannot be considered for this approach. 

VMware vMotion allows for seamless movement of VMs across infrastructure boundaries with minimal impact. Access to the VM is still possible during the whole migration phase and therefore, applications do not require scheduled downtime for the migration. The biggest advantage is that continuous availability is preserved and the entire state of the VM (and its hosted application) is the same as before the migration. Configuration details such as IP addresses and hardware allocation are not changed during a live migration. However, it should be noted that this approach is resource intensive and bulk migrating many workloads with this method may not be practical. Additionally, VMs need to be checked beforehand to ensure that any issues that could potentially stop VMotion from occurring (such as mounted virtual media or shared disks) are not present. These checks, along with infrastructure requirements need to be factored in at the planning stage.

Reprovision from Scratch

While reprovisioning may not technically be considered a migration, it can be an option for some  ephemeral or non-persistent workloads. Instead of moving the workload, it might be possible to spin up new workloads platforming the destination environment and simply turn off the old workloads off in the source environment.

Re-platforming

Re-platforming is a slight modification of Rehosting. The core architecture of an application is retained while replacing one or more components of the application by equivalent cloud offerings. For example, an application consisting of multiple VMs may already separately host a relational database system in one VM. When moving this application to the cloud it may be decided to replace the database VM with an equivalent cloud offering of the relational database system.

Refactoring

This approach requires entirely re-architecting an application to take advantage of unique cloud provider features. When cloud-native features are required, or the agility and scalability of micro-services-based applications call for it, applications are typically broken up into smaller pieces or services. These services are deployed in a containerized environment on one or more public clouds. Although this can be and expensive approach to migration, the resulting benefits can exceed the potential risks. Over time, many applications that were migrated with another migration type may become refactored as the increased benefits of cloud-native applications require.

Applications often change how they are operated after initial deployment. Depending on the application type, use, and growth characteristics there may need to be an application architecture assessment. Applications may be able to leverage a set of common containerized micro-services for their dependencies. Similarly, applications themselves could be candidates for containerization. Cloud-native technologies can change the way applications are hosted and interact with one another. Refactoring an application need considerable effort from both application and infrastructure teams. Refactoring sometimes is also referred to as “Re-architecting”.

Repurchasing

Repurchasing decommissions the existing application and replaces it with an already available cloud-based version from the cloud provider’s marketplace – in essence replacing one license fee with another. This approach is often utilized for older on-premises applications or legacy applications not easily virtualized or migrated in other ways.

Application vendors sometimes offer cloud equivalents with better functionality, resiliency, and update cycles to encourage their customers to migrate away from an on-premises hosted model. The cloud version of applications usually includes term or metered licencing. Furthermore, it may be that licensing on ‘traditional’ applications need to be reviewed and it is most cost effective to license cloud-based applications.

Retaining

There may also be applications that simply cannot be migrated and must stay on-premises. For instance, specialist applications that need to run on specific hardware or operating systems that are not available in the cloud. Mainframes and specialist medical applications often fall into this category. Migrating these workloads may be impossible or have a detrimental effect on the business. In these cases, the decision may be to keep these workloads untouched. Some work may be needed to alter any dependencies with other services that are being migrated. Other examples calling for retaining applications are data sovereignty and compliance reasons, which dictate data to stay on-premises and cannot be hosted on a cloud platform.

Retiring

In the discovery phase, it may transpire that there are applications or services that are little used, or that can be safely turned off without affecting much else. Typically keeping these workloads running would cost more than their net worth. Further, there may be duplicate sets of services performing very similar actions such that a common service can be utilized. As migrating applications can be resource intensive, it is worth taking the time to see if services and duplicates can be optimized. This is a good opportunity to assess inter-dependencies and usage.