There may come a time where a user wants to have the current HCX environment operating in a different cluster, but does not want to create a completely new Compute Profile and Service Mesh. Hence, the need to migrate the HCX appliances to a different cluster.
Note: Modifying compute and storage resources while HCX is actively managing workload migrations or Disaster Recovery (DR) replications can cause severe disruptions. The migration path depends heavily on whether storage (datastores) is changing alongside the compute cluster.
VMware HCX
Please note that it is recommended to deploy a new Compute Profile and Service Mesh for the new cluster, rather than attempting to manually vMotion the HCX appliances to a different cluster.
If you must utilize the existing mesh, the procedure depends on whether you are migrating just the ESXi cluster, or both the cluster and the datastores.
Scenario 1: Compute-Only Migration (Changing ESXi/Cluster, Datastores remain unchanged)
If the underlying datastores remain exactly the same, ongoing DR replications can survive the migration because vSphere Replication natively handles compute vMotion, provided the new hosts are authorized in HCX first ie included in the service cluster in compute profile.
Verify Prerequisites: Ensure the new cluster meets all HCX requirements and port configurations (HCX Ports and Protocols).
Verify Networking: Ensure the desired cluster is attached to the same dvSwitches/transport zones as the previous cluster.
Update Compute Profile: Edit the Compute Profile to add the new cluster to the "Service Cluster" and change the "Deployment Cluster" to the new cluster.
Resync Service Mesh: Perform a resync in the HCX UI. The resync will display a message indicating that the appliances will be redeployed to the new cluster.
Migrate Workloads: Safely vMotion workload VMs to the new cluster. Because the target storage is unaltered and the HCX appliances now have administrative scope over the new hosts, active DR replications will continue without interruption.
Scenario 2: Compute and Storage Migration (Changing ESXi/Cluster AND Datastores)
If the target datastore is changing, active replications cannot survive a manual vCenter migration. You must stop migration/protections prior to the move to prevent replication database mismatches and orphaned replica disks.
Halt Active Protections: Remove/Stop all ongoing HCX DR replications via the HCX UI and ensure no active workload migrations (vMotion, RAV, Bulk) are running.
Warning: Do not manually Storage vMotion protected VMs or replica disks via vCenter while replications are active. HCX tracks replica files via specific datastore UUIDs. Out-of-band storage migrations permanently break the DR topology (-> ?).
Migrate Workloads: Perform the vMotion and Storage vMotion of your workload VMs to the new cluster and datastore via vCenter.
Update Compute Profile: Edit the Compute Profile to reflect the new Deployment Cluster, Service Cluster, and the new Datastores.
Resync Service Mesh: Resync the Service Mesh in the HCX UI. The appliances will be redeployed to the new infrastructure.
Reconfigure DR: Once the Service Mesh is healthy, re-protect the workloads in the HCX DR interface to map to the new target resources and initiate a fresh initial synchronization.
Note: Please know this process requires a redeploy of the HCX Appliances, which will cause downtime for the HCX management and data planes. It is recommended to take a maintenance window during this process in case any issues arise.
Workaround: Create a new Compute Profile with the desired Deployment Cluster and create a new Service Mesh.