Well-Architected Design: Cloud Migration Tools Decision Guide


This guide provides detail when selecting migration tools for your cloud migration project. The context of this document assumes the migration target to be a VMware Cloud platform and the source of migration is assumed to be on-premises SDDCs. The primary focus is rehosting or relocating virtual machines as part of your overall cloud migration.

First, we will focus on the design considerations that drive your tool selection. Next you will learn about the characteristics of several cloud migration tools. We will outline the advantages and constraints of each tool This will provide the required guidance when selecting cloud migration tools for your project.

It is assumed the audience of this design is familiar with contents and terminology introduced in previous Cloud Migration articles within the Well-Architected Designs. For more information, refer to the Cloud Migration Strategy, Cloud Migration Planning and Cloud Migration Preparation designs.

Selecting a Tool for Migration to a VMware Cloud Platform – Decision Factors

In this section we will introduce various decision factors, which need to be considered with your selection of a migration tool.

Hybrid Connectivity Mode

Hybrid Connectivity Mode defines the high-level characteristics of a hybrid connection between an on-premises environment and the VMware Cloud environment. The intended duration of such a connection is the key factor to consider. The connectivity mode does not take into consideration the topology or architecture of the connection.

Long-Term Connectivity

Long-Term Connectivity is the permanent connection between an organizations on-premises environment and its VMware Cloud environment. This is the steady state connection used for all general communication from on-premises to VMware Cloud. Examples include application, user, and database traffic.

Temporary or Migration-Only Connectivity

Temporary Connectivity is the connection between an organization’s on-premises and a VMware Cloud with a goal of shutting down on-premises datacenters. In such a scenario the connectivity between on-premises and cloud environment is often only needed for migration purposes. The on-premises environment will be cut off after the migration. The migration process itself can be considered a one-time-effort.

When selecting a cloud migration tool, lower requirements need to be met as compared to the long-term connectivity scenario. This is because the cloud migration tool only needs to be capable of executing a one-time cloud migration with a finite scope.

Air Gap Environments (No Connectivity)

An air gap environment is where the on-premises and the cloud environment have no connectivity and should be treated as a special case in cloud migration scenarios. This scenario may exist due to technical, security, or compliance-related constraints. This can make it impossible to set up direct connectivity between an on-premises datacenter and the VMware Cloud.

In these special cases the selected cloud migration tool must be capable of handling “offline” migrations where the state of the source VM or workload is captured and saved on-premises before it will be transmitted to the destination cloud.

When selecting the right migration tool, you will need to exclude tools which have a hard requirement of a connection between the on-premises datacenter and the VMware Cloud.

Hybrid Connectivity Topology

The Hybrid Connectivity Topology describes physical and logical networking characteristics of the connection between the on-premises and VMware Cloud environment, which are relevant when selecting a cloud migration tool.

Network Underlay and Connectivity Options

The term “Network Underlay” describes the underlying infrastructure which provides connectivity between a source datacenter and a target cloud. Depending on the chosen cloud provider the technologies and characteristics of the connection may vary. Generally, for cloud connection scenarios the network underlay technology is not traditional L2/L3 networking but usually more complex. For selecting a cloud migration tool, it is not relevant to know the exact underlay technology being used, but the characteristics of the underlay may influence the support for a migration tool.

Dedicated Connectivity vs VPN Options

The type of connectivity may impose constraints for selecting a cloud migration tool. For example, HCX did not support VPN transports in earlier versions. While this restriction has been resolved, you should pay attention to the support of certain cloud connectivity options when selecting a cloud migration tool.

The typical connectivity options for cloud connections fall into 2 categories: VPN and Dedicated Connectivity.
For both options each cloud provider defines its own set of terminology and characteristics. For example, the following is the terminology for direct connectivity options for various providers:

  • AWS Direct Connect
  • Azure ExpressRoute
  • Google Cloud Interconnect
  • Oracle FastConnect

For VPN connections the same applies: Each cloud provider defines its set of terminology and characteristics. When selecting a cloud migration tool you need to check if it supports a certain cloud provider and the connectivity type.

Transit Networks and Network Virtual Appliances

Network security appliances or other tunneling technologies including SD-WAN may impose further constraints on the selection of a cloud migration tool. This can impact when connecting from an on-premises platform to VMware cloud and the connectivity does not terminate directly into the VMware Cloud SDDC, but somewhere else in the transit network.

Bandwidth and Latency

Cloud migration tools that implement “hot migration” have clearly defined requirements for the bandwidth and latency. Since these must be adhered to during a cloud migration process, ensure the requirements of the cloud migration tool are aligned with the corresponding bandwidth/latency characteristics of the connection.

Other Network Underlay Characteristics

Other significant network underlay characteristics to consider when selecting a cloud migration tool include:

  • IP Reachability
    Is the required IP reachability available between components of the migration tool in the source and target site based on the underlay network?
  • Supported MTU Packet Sizes
    What is the end-to-end maximum supported MTU size between the source and destination locations?
  • Network Address Translation
    Does the network underlay support direct IP communication or is Network Address Translation required? When selecting a cloud migration Tool either DNAT or SNAT-related restrictions may apply.
  • Packet Loss Rate
    This metric is not necessarily part of a cloud provider SLA but may need to be measured in a Proof-of-Concept, as some migration tools define requirements regarding the maximum allowed packet loss rate of a connection.

Workload Networking Requirements

In the previous sections we reviewed relevant aspects of the overall network migration infrastructure, which influence the selection of a cloud migration tool. In addition, you should also consider workload VM networking requirements.

Layer-2 Stretched Networking 

When planning a cloud migration, VMs may have the requirement to retain their IP address in the target cloud. We will look at examples where maintaining IPs are desirable or even required.

  • The migration plan outlines on-premises IP subnets will not be deprecated soon after the migration. Instead, a “stretching” of on-premises IP subnets into the cloud platform is required for communication between workloads.
  • The VM in scope of a cloud migration does not tolerate any downtime and will have to be migrated via vMotion.
  • Although it is planned to deprecate on-premises networks the migration planning has revealed that there will be a transition period, in which the same IP subnet needs to be available both on-premises and in the cloud.
  • External dependencies to other applications or end users require the IP address configuration to remain unchanged.

If there is a requirement for Layer-2 stretched networking, then you must ensure, that either the migration tool itself or another component of the infrastructure has established the layer-2 networking stretching.

IP-Address Change Requirements

As described in the previous section some applications may rely on an unchanged IP-address configuration when being migrated to the cloud. Other applications may have the requirement to change IP addresses during migration. Such a decision may be driven by a goal to simplify the cloud migration:

  • By assigning a new IP address configuration you can adopt new subnets without concern about existing on-premises subnets. On-premises to cloud IP communication will occur via standard Layer 3 IP routing.
  • Layer-2-Stretching can be a complicated configuration, which has its own failure scenarios. It has some potential performance impacts in case of heavy intra-subnet communication, which can occur across high-latency or low-bandwidth hybrid connections or in case of asymmetrical routing issues, when traffic is transmitted to outside the stretched subnet. There are good reasons to decide against Layer 2 Stretching right from the beginning of your cloud migration project.

IP Address change constrains:

  • Changing IP addresses will require downtime for the VMs during the migration process, as operating systems and potentially applications must be reconfigured.
  • Reconfiguration of IP addresses may be a time-consuming and tedious effort, which will require validation of applications.

When selecting a migration tool you should assess how the tool can assist you in automating IP address changes.

Workload Availability SLAs

Each workload may have availability SLAs. In consultation with applications owners, these SLAs may need to be lowered during a cloud migration, but this will depend on the type of migration being performed. The migration availability SLA may fall into the following categories:

  • No Downtime allowed
    If a workload falls into this SLA category, a hot migration or vMotion migration is mandatory to ensure uninterrupted availability during the cloud migration.
  • Minimal Downtime allowed
    In this SLA category a workload will tolerate a minimal amount of downtime. The time may range from a few minutes to up to an hour. If a high number of VMs belong to the same application and the application needs to “cut over” from the on-premises to the cloud, ensure you are considering the entire application SLA and not each service’s SLA.
  • Extended Downtime allowed
    This category gives the most flexibility when planning the migration. Depending on the workload the allowed downtime may range from multiple hours to even multiple days. One example is an internal application which is only used during weekdays and will be migrated over the weekend.

In summary, the required availability SLA of a workload or application will not only influence the decision on a migration tool, but also the selection of which migration type to choose.

Scope of Migration Project

The scope of a migration project is an important factor when it comes to selecting a cloud migration tool. The following aspects define a scope of a migration project:

  • How many migration waves do you plan for the next months or years? Do you plan for multiple waves over longer period or is the scope small, with a one-time effort?
  • How many VMs will be in scope of each migration wave and what will be the average estimated size of a VM in terms of number of virtual CPU cores and especially RAM?
  • What is the overall storage volume in TB to be migrated in each wave?

If the overall scope of your migration project is small, then you may not find it necessary to buy and implement a separate migration tool at all, but instead you may use the built-in functionality. The vCenter platform itself offers migration options using standard cold migration or vMotion procedures.
If you must manage multiple big migration waves over a longer period, then you will likely opt for a more complex, but also more powerful migration tool. Such tools offer enhanced logging capabilities, full transparency over planned and executed migration waves and multiple migration methods to choose from.

Existing Operational Standards and Tools in the On-Premises Environment

IT departments responsible for the management and operations of on-premises datacenters usually have a large operational toolset in use. When assessing the requirements towards a cloud migration tool, we recommend you assess which tools are already in place in an organization. These tools may meet the requirements of a planned cloud migration. The advantages of this approach:

  • The operational staff of an on-premises datacenter operations already has comprehensive experience with its existing toolset.
  • If one of these tools can be used for a cloud migration, there would be no need for additional software purchases and training to build up the necessary skills for a new tool.

In summary, when planning for a cloud migration an organization should consider existing tools that may be available for workload migrations.

Software Version Considerations

With a major migration of vSphere VMs, you should assess software and virtual hardware versions between the source and the target VMware platform.

vSphere Versions

Many migration technologies specify compatible vSphere versions for the source and target cloud. These version requirements will be outlined on a per-tool basis in the following section of this document. When selecting a cloud migration tool it is essential to know the landscape of the vSphere versions in your source and target cloud to ensure supported versions of the cloud migration tool are selected.

Virtual Hardware Versions

A VM running on vSphere is configured with a specific virtual hardware version. The virtual hardware version defines the capability of the virtual chipset, such as the maximum number of virtual cores supported per VM or the maximum amount of addressable RAM. Independent from the cloud migration tool you must ensure, that the virtual hardware versions used in the source environment are also supported to run in the target cloud. The list of supported virtual hardware versions is mapped to the ESXi hypervisor version. The detailed information on this compatibility can be found on the VMware Knowledgebase.

If you detect virtual hardware version incompatibilities, you have the following options:

  • Downgrade the virtual hardware version of your VMs to ensure support on both source and target cloud.
  • If a virtual machine version downgrade is not a viable option, consider selecting a VMware cloud provider platform which supports the required virtual machine hardware version.

For a list of supported features per virtual hardware version see the VMware Documentation.

In addition to the considerations described above there is a use case, where you may intentionally want to upgrade the virtual hardware versions of migrated VMs. Let’s assume a scenario where you migrate VMs to a destination cloud with no plans to migrate back to the source. If the source environment runs older vSphere versions compared to the target cloud, you may want to upgrade the virtual hardware version of your VMs after migration. This will ensure you can leverage new features and benefits of an up-to-date virtual hardware versions. In this case, select a cloud migration tool that supports automatic virtual hardware upgrade procedures as part of the migration process.

Hardware Platform Considerations


Underlying hardware platforms, on which VMs are hosted, have an influence regarding the selection of a cloud migration tool and cloud migration types.

Before diving deeper into the discussion regarding these factors, it is important to clarify some foundational terminology:

  • CPU Platform
    A CPU platform is a collection of CPU models belonging to the x86 CPU architecture and originating from a single vendor.
    Currently VMware ESXi is supported for 3 vendors of x86 CPUs:
    • Intel
    • AMD
    • Montage
  • CPU Microarchitecture
    A CPU Microarchitecture defines a certain CPU family within each CPU platform. For example, Intel Skylake and Intel Sunny Cove are 2 different CPU microarchitectures within the same CPU Platform Intel.

CPU Platform

Although the CPU Platform has no direct influence on the selection of a migration tool, it has an influence on the supported migration types. As a rule, a hot migration or vMotion migration is only supported if the source and target ESXi host run on the same CPU platform. It’s not possible, to migrate a VM via vMotion from an AMD host to an Intel host and vice versa. Cold Migration is the supported option when migrating between host running on different CPU Platforms.

If you have identified that the source and target cloud run on different CPU platforms in your scenario, there is no need for a migration tool to support hot migration as it is not supported.

Enhanced vMotion Compatibility (EVC) and CPU Microarchitectures

Even if you have ESXi hosts with the same CPU platform, the CPU microarchitectures may differ sometimes resulting in vMotion incompatibilities. As an example, a VM running on a host with Intel “Ice Lake” microarchitecture cannot be “vMotioned” to an ESXi host with Intel “Skylake” microarchitecture without the use of EVC mode. EVC is a configuration option enabled on a vSphere cluster or on a per-VM basis. Before enabling per-VM EVC on individual VMs these VMs must be powered off. Cluster-level EVC helps to ensure vMotion-compatibility between hosts with differing microarchitectures within the same vSphere cluster, while per-VM EVC helps to enable vMotion-migrations of VMs across clusters.

Certain migration tools help automate the configuration of per-VM-EVC modes, so this may be a decision factor for the selection of a migration tool.

The details around EVC can be quite complex and beyond the scope of this document. Please consult the VMware Knowledge base source articles KB 1005764 and KB 1011788.

VMware Migration Technologies and Tools


This section provides an overview of the different VMware technologies and tools that can be used to migrate workloads to a VMware Cloud. We will use the terms source and destination to define the 2 sites involved in a cloud migration. For the context of this section, source will refer to a on-premises VMware SDDC and destination will refer to a VMware Cloud offering. As part of the VMware portfolio, some migration technologies are a dedicated product, and others are features of within a product. As an example, vCenter is the product and the migration feature is vMotion. As we review these tools and help you through the decision process, it is important we look at a cloud migration as a large-scale task with many types of workloads, sites and requirements. In many cases a single migration tool will not cover all requirements. As an example, you may use HCX as your primary tool and use vCenter Converter for a group of isolated workloads.


VMware vCenter is a virtual server management software that provides a centralized platform for controlling your VMware vSphere environments, allowing you to automate and deliver a virtual infrastructure across the hybrid cloud. vCenter provides the virtual infrastructure foundation at both the source and destination sites to run your VMs. As part of vCenter functionality, it includes built-in features to migrate workloads between clouds.

vMotion Technologies

vMotion is a live migration technology that allows you to move a running virtual machine from one host to another with no downtime. The VM retains its network connection and transfers its memory state over a high-speed network. vMotion was originally used to move live VMs from one host to another in the same vSphere environment. As IT infrastructure evolved to be multi-site, the vMotion technology has been enhanced to allow migration of VMs from a source VMware Cloud to a destination VMware Cloud. In the following section we will look at the different vMotion capabilities.

Cross vCenter vMotion

The traditional boundary of a vMotion migration was within a single vCenter server instance. Since our goal is to migrate workloads from one VMware cloud to another, we need to overcome the single vCenter boundary for vMotion. Two options are available to overcome this authentication boundary.

Cross vCenter vMotion with linked mode - One option to accomplish this is using vCenter Enhanced Linked Mode (ELM). ELM allows you to join multiple vCenter Servers in the same SSO domain and manage the inventories together, hence extending the authentication context to 2 or even more vCenter server instances. Once linked, privileges can be assigned to execute vMotion processes in all linked vCenter server instances.

Cross vCenter vMotion with separate SSO domains - An alternative, Cross vCenter vMotion uses PowerCLI and allows you to authenticate to each SSO domain separately without the need for ELM.

Prerequisites for Cross vCenter vMotion

  • The source and destination vCenter Server instances and ESXi hosts must be running version 6.0 or later.
  • The cross vCenter Server and long distance vMotion features require an Enterprise Plus license.
  • When using the vSphere Web Client, both vCenter Server instances must be in Enhanced Linked Mode and must be in the same vCenter Single Sign-On domain so that the source vCenter Server can authenticate to the destination vCenter Server.
  • When using the GUI (webclient) ELM (same SSO Domain) is required
  • When using sdk/api/PowerCLI ELM (same SSO Domain) is NOT required
  • Both vCenter Server instances must be time-synchronized with each other for correct vCenter Single Sign-On token verification.
  • For migration of compute resources only, both vCenter Server instances must be connected to the shared virtual machine storage.
  • When using the vSphere APIs/SDK, both vCenter Server instances may exist in separate vSphere Single Sign-On domains.
  • Ports 8000 and 902 for vMotion and NFC between ESXi
  • Port 443 between both vCenter Servers
  • Port 443 between vCenter Server and the ESXi server (this is a requirement to have the ESXi host added to vCenter Servers)

Advanced Cross vCenter vMotion

With vSphere 7.0 U1 VMware introduced Advanced Cross vCenter vMotion. This enhancement builds on the previous PowerCLI capability by adding support to the UI. With this, your vMotion UI can authenticate to vCenter Servers in different SSO domains. This means it’s possible to migrate virtual machines (VMs) between vCenter Servers that are in different Single Sign-On (SSO) domains through the traditional UI tools.

Prerequisites for Advanced Cross vCenter vMotion

  • The source and destination vCenter Server instances and ESXi hosts must be running version 7.0 U1 or later.
  • Ports 8000 and 902 for vMotion and NFC between ESXi
  • Port 443 between both vCenter Servers
  • Port 443 between vCenter Server and the ESXi server (this is a requirement to have the ESXi host added to vCenter Servers)

When to Migrate with vMotion

vMotion can be used to migrate workloads as part of your larger cloud migration strategy. We will discuss some of the use cases and factors to keep in mind when considering vMotion as a migration tool.

  • vMotion is a feature of vCenter already available to you at both sites. No additional software or license is required.
  • vMotion is a well-known technology to vSphere admins and will have a reduced learning curve.
  • vMotion has a wide range of supported source and destination vSphere versions.
  • vMotion is good for small migrations or as a supplement to other tools for larger migrations.

Potential Constraints When Using vMotion

vMotion is a key feature in vCenter server, which also meets the requirements for certain cloud migration scenarios. However, there are also some constraints:

  • vMotion supports 8 concurrent migrations per host in vSphere 8. If your migration scope if small this may be an acceptable constraint. For larger scaler migrations or application that must be moved as a group, this number may not be sufficient. However, if the requirement is to cutover hundreds of VMs at the same time, you may leverage other migration techniques like HCX Bulk Migration or Replication-Assisted vMotion.
  • vMotion has strict requirements towards the available bandwidth between the source and target SDDC. Your hybrid connection link will need to support the bandwidth requirements of concurrent vMotion processes but must also support the requirements of regular applications which use the link as well. If you just do not have sufficient bandwidth in your hybrid connection link to satisfy both requirements, consider using a migration tool which has some offline or asynchronous data shipment options.
  • vMotion is an online migration method which means that downtime for a VM is usually not required. However, there may be certain types of applications that cannot tolerate reduced performance during a vMotion process or the small network interruption at the end of a vMotion process. High transaction databases and I/O heavy applications can sometimes fall into this category. From your on-premises vSphere environments you should already know which of your VMs are sensitive towards vMotion processes. Consider using a cold migration method for these candidates or shut down the application services prior to using vMotion. Complete applications, which are sensitive to vMotion processes, are very rare.
  • The vMotion feature in vCenter has not necessarily been designed to guide you through a cloud migration at high scale. For example, it does not assist you in planning your migration waves or provide reporting on your migration project status. If you would like end-to-end guidance of your migration project in all phases from assessment, planning to execution you may want to leverage other tools like for example VMware Aria Migration or VMware HCX. These build upon vMotion migration technology and provide additional capabilities.


VMware HCX is an application mobility platform that is designed for simplifying application migration, workload rebalancing, and business continuity across data centers and clouds. It simplifies the onboarding to the cloud by providing an abstraction layer between your on-premises datacenter and the cloud. HCX is VMware’s flagship product for cloud migration. In the following section we will look at HCX use cases, migration types and help organizations identify when HCX should be selected as a tool for your cloud migration.

Use Cases

Application Migration

You can schedule and migrate thousands of vSphere virtual machines within and across data centers without requiring a reboot.

Change Platforms or Upgrade vSphere Versions

With HCX, you can migrate workloads from vSphere and from non-vSphere (KVM and Hyper-V) environments within and across data centers or clouds to current vSphere versions without requiring an upgrade.

Workload Rebalancing

HCX provides a multi-cloud mobility platform across cloud regions and cloud providers to allow organizations to move applications and workloads at any time to meet scale, cost management, compliance, and vendor neutrality goals.

Business Continuity and Protection

Using HCX capabilities, administrators can protect workloads by replicating them to other HCX sites. Workload migration is available on-demand, or it can be scheduled for business or for maintenance planning.

Migration types

HCX provides multiple migration technologies that allow you to move workloads from source to destination clouds. To make the correct choice when selecting cloud migrations tools, you must consider each feature and how they can address your cloud migration requirements.

Bulk Migration

Bulk Migration uses the host-based replication to relocate a virtual machine between HCX data centers. This process seeds and updates the replication data at the destination without impacting the VM at the source cloud. At time of cutover, final replicas are synchronized, the VM is powered down at the source and bootstrapped at the destination.

HCX vMotion

VMware HCX vMotion can transfer a live Virtual Machine from a source site to a destination site (or from the destination site towards the source site). The vMotion transfer captures the virtual machine active memory, its execution state, its IP address, and its MAC address. The migration duration depends on the connectivity, including both the bandwidth available and the latency between the two sites.

Replication Assisted vMotion

HCX Replication Assisted vMotion (RAV) uses the HCX along with replication and vMotion technologies to provide large scale, parallel migrations with zero downtime.

Operating System Assisted Migration (OSAM)

The HCX OS Assisted Migration service uses an agent installed on Linux or Windows guest VMs to assist with migration from a non-vSphere environment to vSphere environments. The agent works in conjunction with appliances deployed at the source and destination site to replicate VM data and schedule the cutover.

HCX Cold Migration

An HCX Cold migration moves a powered-off virtual machine from source to destination in much of the same way vMotion moves a powered on VM. Cold migration uses the same network path as HCX vMotion to transfer the powered off VM data. During a cold migration, the VM IP address and the MAC address are preserved.

Network Underlay - Bandwidth and Latency requirements

The source and destination of an HCX deployment have management and dataplane network requirements. The following table shows the requirements for the various migration types supported by HCX.

Network Parameter

HCX vMotion

Replication Assisted vMotion

Bulk Migration & DR (Protection)

OS Assisted Migration

Min Bandwidth (Mbps)





Min MTU (bytes)

(1350 if version < HCX 4.2)





Max Packet Loss (%)





Max Latency (ms)





When to use HCX?

The decision to use HCX as your migration tool requires an understanding of the feature-set and comparing that to your migration requirements. We will look at HCX considerations and give examples to help organizations in deciding when HCX is the right tool for migration.

  • HCX provides the ability to stretch layer 2 networks from your source to destination clouds through the network extension. This allows workloads to be migrated without changing IP addresses. Retaining IP addresses can be a hard requirement for your cloud migration. In that case, HCX is a great choice.
  • In previous examples we looked at workload migration requirements that include maintaining the same IP address. This is commonly achieved through stretched L2. Another IP migration requirement could be the desire to change IPs for all VMs in a migration wave. An example could be a source network where only half of the VMs are migrating, but you are unable to stretch the network. In this case, HCX migration type can automate the IP change as part of the VM switchover process.
  • If your cloud migration is complex with thousands of VMs, HCX may be a good fit. Through the bulk migration features, you can organize your VMs into waves, schedule and seed the data migration and automate the cutover to the destination cloud.
  • In some cloud migrations, you may be limited to connections with limited performance such as a remote office using a VPN. HCX has technologies such as WAN optimization that can help overcome connection bottleneck. For such cases, HCX could be a good fit.
  • Cloud migrations projects typically contain a variety of guest VMs and may even have non-VMware hypervisors running these VMs. With HCX OS Assisted Migration, you can migrate workloads running on 3rd party hypervisors to a VMware Cloud Platform.
  • Cold Migration is a good choice to move test/dev machines as well as validate your source and destination infrastructure for more robust migration tools. As an example, Cold Migration uses the same paths and has the same requirements as HCX vMotion. First test a few Cold Migrations to validate your setup for future vMotions and RAV Migrations.
  • One migration business case is cloud extension. This is where workloads permanently run at both the source and destination cloud. In this example, you may have an initial migration, moving a large quantity of virtual machines to the destination site. Once initial migration is complete, your business frequently requires a quantity of workloads to move between sites seamlessly. This is a scenario where HCX could be a great fit for not only the initial large migration, but also the ongoing shift of workloads. Possibly using Bulk Migration for the initial waves and then using RAV and HCX vMotion to non-disruptively shift workload between the sites.
  • Virtual machines have settings and characteristics that define the way they operate. Such example may be CPU/Memory setting and virtual hardware settings. During a cloud migration you may want or need to change these setting. With some migration tools, this would consist of a 2-step operation, migration of VM and then maintenance window to update settings. In other cases, the migration may not complete due to incompatible VM settings with the destination hypervisor. This is a great place to consider HCX. During the HCX migration events, the user can update and change many VM properties and extended options. This will improve migration efficiency and decrease workload downtime. See the following table for the VM options that apply to each HCX migration type.

Potential Constraints When Using HCX

HCX is the leading migration tool from VMware. Its purpose build for large-scale cloud migration. In this section we will discuss some of the constraints when using HCX for you migration.

  • Cloud migration scope can vary depending on the number of workloads you will migrate from source to destination. HCX can accomplish all migration sizes but excels when moving many workloads in concurrent fashion. If your cloud migration, or a piece of you cloud migration has a small number of VMs that can withstand serial migrations, a better sized tool such a vMotion is appropriate. In addition, this is a good example of where multiple migration tools could be the answer. For example, your cloud migration consists of workloads moving from a main data center and a remote office, both destined for a VMware Cloud. You may choose HCX for your main data center due to the number of workloads and choose vMotion for the smaller remote office migration.
  • Each of the migration tools discussed have a set of requirements such as versioning, bandwidth, and ports. In most cases, the more feature rich a product is, the more complex the deployment and requirements become. As HCX is designed for the largest migration cases, it has more significant architecture and requirements. Balancing the complexity of deployment with the scope of your migration may result with not choosing HCX as your preferred migration tool.
  • An HCX deployment consists of a number of management VMs at both the source and target site. These VMs are used for management, control plane and dataplane functionality. Examples include the site pairing, network extension, data replication and WAN optimization appliances. The source site may be a legacy deployment with limited available CPU and memory resources. Such a case could make HCX a prohibitive choice as resources may be unavailable to deploy the components required.
  • With an HCX deployment, you have a source, destination and a central HCX service managed by VMware. The HCX SaaS service is used for some management tasks such as licensing, updates, and support. Connectivity to this service is required for product functionality over the public internet. Some organizations compliance requirements limit access to the internet. For such cases, tools should be considered that only require source to destination connectivity or no connectivity at all. vMotion and vCenter converter would be good candidates.

VMware vCenter Converter

vCenter Converter is a simple but powerful tool initially design to convert physical machines in vSphere-based virtual machines. As the use cases evolved, vCenter Converter was also commonly used to convert non-vSphere based virtual machines, to vSphere based virtual machines. As IT infrastructures began spanning sites, vCenter Converter evolved into a migration tool.

  • Offers broad support for source physical machine, virtual machine formats and certain 3rd party disk formats.
  • Allows conversion without downtime of the source machine.
  • Can be used to simultaneously convert large-scale deployments.
  • Provides centralized management console to allow scheduling of conversions and migrations.

When to use vCenter Converter?

vCenter Converter plays an important role in many virtual machine migration strategies. Below we will look at examples and help organizations in the selection process.

  • Although most workloads are virtualized in the modern datacenter, physical servers are still common. When your cloud migration requirements include physical servers, we should consider the use of vCenter Converter. It can be used to convert the physical server to a VM as well as relocate it to a remote vCenter server. This include both Windows and Linux physical servers. See the following table for full OS support.
  • Part of your cloud migration may include converting virtual machines running on Microsoft Hyper-V to VMware Clouds. vCenter converter can connect to a Hyper-V deployment and convert to vSphere based VMs.
  • You may have VMware Virtual Machines running on ESX hosts that are not managed by a vCenter servers. This could be a scenario at small branch offices or lab environments. vCenter Converter supports connecting directly to ESX as a source for migration.
  • One of the hybrid connectivity modes described earlier in this document is an air-gapped deployed. This refers to a source and destination cloud that do not have external connectivity to one another. This could be due to security and compliance reasons or even a remote office lacking internet. For this cloud migrations we must perform offline migrations where we can convert or extract the virtual machines and then transport them to the destination site without external connectivity. This is a great place to consider VMware converter.
  • In some migration scenarios, your network bandwidth may not be sufficient to support the additional traffic of a cloud migration. An example of this would be an edge location that has limited internet access. In this scenario, using VMware converter for offline migrations makes sense. This will allow the existing bandwidth to support the business operations.
  • If your cloud migration included Amazon EC2 instances, VMware converter is a tool to consider. With the release of Converter 6.4 you can now migrate virtual machines from an EC2 source to a VMware cloud destination. This migration uses an agent installed in the EC2 virtual machine and supports both Windows and Linux guest operating systems. The following article describes this in further details.

Potential Constraints When Using vCenter Converter

  • vCenter Converter is an additional tool, which is not part of vCenter Server. So, its installation and resource assignment must be planned separately. You also must ensure you meet all compute resource and networking requirements for a vCenter Converter deployment.
  • vCenter Converter does not directly compare to other migration tools described in this guide, as it serves a different use case, namely the format conversion between source and target machine. For migration scenarios, where VMs are migrated from a source VMware SDDC to a target VMware SDDC without any format conversion, other migration tools described in this document are more appropriate.

VMware vCenter Site Recovery Manager (SRM)

Site Recovery Manager (SRM) is the VMware disaster recovery (DR) solution that provides policy-based management, minimizes downtime in case of disasters via automated orchestration, and enables nondisruptive testing of your disaster recovery plans. In addition to being a DR solution, SRM has capabilities that make it a powerful migration tool for moving workloads between clouds. The following section will focus on those workload migration capabilities as you make your tools selection.

When to use SRM?

  • In your IT infrastructure you may be using SRM today for disaster recovery. Taking advantage of the additional workload migration capabilities may allow you to leverage an existing investment for your cloud migration.
  • If your cloud migration planning must consider complex application dependencies, you may want to select SRM with its advanced orchestration capabilities, when migrating workloads.
  • Your cloud migration strategy may be more than a one-time move from source to destination cloud. As an example, your business application may need to float between sites depending on resource availability. SRM has failback and re-protect capabilities that will make it easy to manage the workload migration in both directions with a single recover plan. Starting with vSphere 7.0 U2 the “reprotect” process has been optimized to drop the operation from hours to minutes. More can be read about the Persistent State File (PSF) in the VMware Documentation.
  • One of the common benefits to a DR solution is the ability to test a failover before the disaster event to ensure applications function as expected. This same benefit can be applied to your cloud migrations. By testing a recovery plan, you ensure that the virtual machines migrated correctly to the destination site. If you do not test recovery plans, an actual cloud migration might not recover all virtual machines, resulting in data loss.

Potential Constraints When Using SRM

  • When comparing SRM as a migration for example with HCX, there are many overlapping features. For example, both have extended orchestration capabilities when it comes to VM migration. SRM, however, is more focused on a disaster recovery use case than a cloud migration use case. With that, you will see, that SRM supports fewer migration options and types than HCX, which supports various flavors of hot and cold migration.
  • For SRM to function it is required to set up some form of storage replication. Either array-based replication, or vSphere Replication. While HCX can leverage vSphere Replication as well, it is not a strict requirement when using HCX.
  • If one of your primary use cases in your on-premises environment has been disaster recovery and you have already deployed SRM as a solution, then you may seem a natural fit to extend your existing investment in SRM to a cloud migration use case. If on the other hand have a big scope and complexity of your migration project, then you may consider the selection of HCX as your migration tool as a better fit.

Aria Migration

VMware Aria Migration can quickly provide migration assessments, including actual inventory-based assessment from your own vCenter(s), along with providing a cost-benefit analysis of VMware Cloud on AWS or Native AWS compared to on-premises, and more.

Use Case

Migration Assessment

  • The assessment service provides accurate assessments based on live data collection, enabling you to make data-driven decisions. In other words, you can make an actual inventory-based assessment from your vCenter(s). You can also import (e.g., from RVTools) and add data offline in layers. You can also export data from VMware Aria Migration for use with other tools.
  • The service applies Machine Learning to discover your applications by automatically grouping machines into applications, including grouping them into resource usage-based categories (e.g., high, medium, low storage, CPU, or Memory).
  • You can then leverage the system intelligence to scope the migration based on your migration style (e.g., by vLAN, by applications). Flexible filters also allow for coarse grain or fine scoping (e.g., based on a cluster, vCenter tag, resource usage, and vCenter folder). You can further analyze application dependencies to properly scope your migration, gaining insight into what you might include or exclude.


Migration Use Cases (Scenarios)

VMware Aria Migration is planned to support migration use cases (or scenarios) across various cloud environments. The current release supports migration assessments from on-premises vSphere environments to VMware Cloud on AWS, along with on-premises vSphere environments to Native AWS, and we will continue to add more use cases to the free migration assessment. Regardless of the choice of target for assessment, core capabilities of discovery, application grouping, and dependency analysis can still be used.

When to use Aria Migration?

  • Implementing a Multi-Cloud Strategy: Aria Migration is an invaluable resource for organizations looking to distribute their applications and workloads across multiple cloud platforms. It streamlines and accelerates this complex process, intelligently identifying the best cloud for each application based on user-defined parameters like security, performance, cost, and time.
  • Inventory-Based Assessment: Aria Migration provides offline and online options for executing an inventory-based assessment from vCenter(s), making it a versatile tool for various operational needs.
  • Automated Application Discovery and Grouping: Managing and organizing applications and workloads can be challenging. Aria Migration's Automated Application Discovery feature addresses this by automatically grouping machines into applications and categorizing applications based on resource usage.
  • Migration Planning: If you're in the initial stages of migration planning, Aria Migration offers Migration Sizing Recommendations to guide your strategy.

Aria Operations for Networks


VMware Aria Operations for Networks delivers intelligent operations for software-defined networking and security. VMware Aria Operations for Networks consists of both SaaS and on-premises solutions. These offerings help customers build an optimized, highly available, and secure network infrastructure across multi-cloud environments. They accelerate application discovery, migration, network segmentation planning, and deployment; enable visibility across virtual and physical networks; and provide operational views to manage and scale VMware NSX, VMware Cloud on AWS, VMware NSX Advanced Load Balancer™, VMware HCX®, and many other VMware and 3rd Party deployments.

Use Case


  • Gain unified visibility across hybrid and multi-cloud environments
  • Gain visibility for NSX, VMware SD-WAN, VMware HCX, Kubernetes, VMware Cloud on AWS, Amazon Web Services (AWS), Microsoft Azure, Azure VMware Solution, Google Cloud VMware Engine, Oracle Cloud VMware Solution, and VMware Cloud on Dell
  • Gain visibility between overlay and underlay networks
  • Enable end-to-end troubleshooting, traffic, and path analytics
  • Enable network assurance and verification
  • Utilize guided network troubleshooting for intuitive root-cause analysis


  • Enable application discovery and plan application migrations
  • Measure application latency and performance
  • Reduce mean time to repair (MTTR) for application connectivity issues
  • Optimize application performance by eliminating network bottlenecks
  • Analyze traffic and apps across hybrid cloud and multi-cloud

When to use Aria Operations for Networks?

  • VMware Aria Operations for Networks (formerly VMware vRealize® Network Insight™) supports the addition of VMware HCX as a data source. It collects configuration information about service meshes, appliances, Layer 2 extensions, and the like. VMware Aria Operations for Networks also collects metrics, such as receive/transmit (Rx/Tx) packets, bytes, and packet drops, for the tunnels between appliances.
  • VMware Aria Operations for Networks receives IPFIX flow data from the vSphere Distributed Switch™ (VDS) in the case of pure VMware vCenter Server® environments and from the NSX Distributed Firewall™ in the case of modern software-defined data centers (SDDCs) based on NSX Data Center for vSphere or NSX-T. These IPFIX flows are enriched with information about the VMs, the host, the data center, security groups, and the like.
  • VMware Aria Operations for Networks identifies flows traversing the VMware HCX network extension transport tunnels and enriches them with the information about the VMware HCX L2 extension they are part of. This helps you understand the network traffic in your VMware HCX environment deeply.
  • VMware Aria Operations for Networks, the initial dashboards provide an immediate overview of the VMware HCX environments. The starting point to check this can be the VMware HCX Manager dashboard.
  • VMware Aria Operations for Networks also raises alerts if the health statuses of the VMware HCX services, appliances, or tunnels change.

VMware Aria Operations for Networks collects various metrics related to the VMware HCX appliance VMs and the tunnels that exist between the IX and NE appliance pairs. Monitoring the health of these two entities is important to ensure the smooth functioning of your VMware HCX workload migrations and network extensions.

3rd Party Migration Tools

In addition to the VMware migration tools covered in the previous section, many 3rd party vendors have products to migrate virtual machines to a VMware Cloud.

Workload Migration Whitepaper (comparison across vendors)


Hyperscaler Tools

AWS Migration tools


Google Migration tools


Azure Migration tools


Oracle Migration tools


Filter Tags