VMware Cloud 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. To facilitate the migration, there are four main types of migration that can be considered:

• Live Migration
• Parallel Infrastructure
• Bulk Migration
• Refactoring

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.

Live or 'Hot' Migration

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 such as IP addresses and hardware allocation. 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.

Parallel Infrastructure or 'Warm' Migration

When migrating to parallel infrastructure, VMs and applications are built out in the target site to match the source. Once the VM is ready, a backup from the source site is used to re-create the application and configuration on the target site. Once the target infrastructure is operating with the applications running as expected, a cut-over is performed. Typically, a final synchronization step is used to capture the latest application data. This method ensures minimal downtime, however the state of the VM on the target site is different to the source (e.g., IP addresses will differ). There must also be thorough checks to ensure the application is working correctly before the cut-off takes place. This is therefore the most complex method of migration and must be carefully planned.

Bulk or 'Cold' Migration

Bulk or cold migration is one of the easiest and safest way to move workloads. 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.

Refactoring

Applications often change how they operate 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.

Repurchasing and Licence Considerations

In some cases, a SaaS version of the application may be available as a direct replacement for the on-premises version. This approach is often ideal for larger legacy applications, such as ERP or CRM systems. 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. This is also a good choice for applications that are not easily virtualized or have out-of-date dependencies on hardware or operating systems. The cloud version of applications usually includes term or metered licencing. Furthermore, it may be that licencing 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.

Consolidation or 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.