Most migration projects I get called into have already made at least one method-selection mistake before I show up. Not always catastrophic — sometimes it's a maintenance window that ran four hours longer than planned, sometimes it's a licensing conversation nobody wanted to have mid-engagement, sometimes it's a client calling at 4am because their backup console is showing "VM not found" on everything that moved the night before. Always avoidable.
HCX gives you four migration types. The official documentation exists and is reasonably complete. It's also dense enough that most teams read it once, land on the method they're most familiar with, and apply it to the whole estate. This is the version I wish existed when I first started running HCX migrations — specific enough to be actionable, with the operational gotchas that live in the footnotes of the official docs if they appear at all.
vMotion: One VM, No Downtime, Sequential
HCX vMotion works the same way native vMotion does, with HCX providing the cross-site transport layer between appliances. Memory state migrates live. The source VM disappears, the destination VM takes over, no service interruption. Zero downtime, full stop.
The constraint is baked into how it works: one VM at a time, sequentially. HCX will queue jobs, but the actual switchover for each VM happens one after the other. If the first VM in the queue has a 200GB working set that takes ninety minutes to stabilize across the WAN link, every other VM in that batch is waiting. In a large wave, that math doesn't work.
vMotion belongs on your genuinely tier-1 applications — the transaction processor that someone will definitely call you about if it sees a two-minute outage, the database cluster with no tolerance for any service interruption. It's not the right primary method for moving hundreds of VMs through a structured migration program. The hardware requirements also matter in older environments: VM hardware version 9 minimum, x86 architecture only. In estates that haven't been modernized in years, those constraints quietly eliminate the "zero downtime" option for specific VMs before the planning conversation even starts.
Bulk Migration: Where the Volume Actually Goes
Bulk migration handles the majority of workloads in almost every large HCX engagement I've run. HCX uses the vSphere Replication protocol to pre-seed VM data to the destination while the source keeps running. You define a cutover window in advance — when that window arrives, the source powers off, a final sync runs to capture changes since the last replication pass, and the destination powers on. The service interruption is a reboot. That's the trade.
For most workloads in a typical enterprise estate — file servers, development environments, batch processing systems, application tiers with RTOs measured in minutes rather than seconds — a scheduled reboot window is a reasonable requirement. The wave planning flexibility is what makes bulk practical at scale: replication can seed for days before the actual cutover window, which collapses the final sync time to a fraction of what it would be if you started from cold. A wave that looks like it needs a twelve-hour window on paper often completes in under two hours when the data pre-seeding was planned correctly.
The scheduling capability is what most teams underuse. Replication for days, cutover in hours. That's the model that actually works at scale.
Bulk also handles hardware version upgrades and VMware Tools updates as part of the migration process, which matters in environments moving from older vSphere versions to VCF. That cleanup happens during the cutover sequence rather than requiring a separate post-migration maintenance window.
RAV: The One That Gets Consistently Undersold
Replication Assisted vMotion is the migration type that most teams either skip over entirely or don't fully understand. It's also the right answer for a specific and common scenario — large-scale migration where zero downtime is a genuine requirement, not just a preference.
RAV combines the parallel replication model from Bulk with the live vMotion cutover instead of a power-off sequence. Multiple VMs replicate simultaneously, delta changes sync continuously, and when the switchover window arrives, RAV initiates a vMotion for each VM's final cutover rather than shutting it down. The replication phase runs in parallel; the live switchover happens serially. The result is that you can pre-seed a hundred VMs over several days, define a switchover window, and cut them all over with zero service interruption — even though the per-VM switchover itself is sequential.
Two requirements that trip people up. RAV needs 100 Mbps of actual sustained throughput between sites. Not advertised link speed, not burst capacity — actual sustained throughput measured during active replication. Environments with constrained WAN links that technically hit 100 Mbps at 2am but not during business hours need to validate this before committing to RAV as the migration method for a wave. VM hardware version 9 is also required, same as vMotion.
- Two destination folders instead of one. RAV creates separate folders for the VM infrastructure definition and disk data at the destination, rather than the single consolidated folder that vMotion produces. This is documented in the Broadcom TechDocs, but it's not prominent. Backup agents that locate VMs by folder path will fail silently — the VM exists on the destination vSphere, but the backup job can't find it where it expects to look.
- When this surfaces. Almost always the morning after the migration wave, when the overnight backup job runs and generates failures for every VM that moved. The error shows "VM not found" rather than anything that obviously points to the folder structure.
- The fix. Storage vMotion to consolidate the two folders, or update the backup agent inventory to locate VMs by the new paths. Either works. The conversation is significantly better before the wave than at 4am after it.
- Disk UUID changes. RAV generates new disk UUIDs at the destination. If any application on the migrated VM has a disk UUID dependency — certain licensing mechanisms, some storage agents — vMotion is the better choice for that workload.
OSAM: When the Source Isn't vSphere
OS Assisted Migration is the mechanism for bringing non-vSphere workloads into VCF. Hyper-V, KVM, or bare-metal physical servers — if the source doesn't have a VMware hypervisor underneath it, OSAM is the path.
The architecture is fundamentally different from the agentless methods above. OSAM requires a Sentinel agent installed on each source guest VM. That agent communicates back to a Sentinel Gateway appliance deployed at the source, which forwards data to a Sentinel Data Receiver at the destination. The conversion process quiesces the guest VM, converts it to vSphere format, and brings it up on the destination cluster.
Two things to know before scoping an engagement that includes OSAM. First: licensing. In VCF 4.x and 5.x environments, OSAM required a separate HCX Enterprise SKU — distinct from HCX Advanced, which is bundled with NSX Data Center Enterprise Plus and several VMware Cloud offerings. Under VCF 9's per-core subscription model, HCX is included in the base subscription and the separate Enterprise procurement step largely goes away. However, HCX still internally distinguishes Advanced from Enterprise service tiers, and Enterprise activation within HCX Operations is still required before OSAM is available — it's not on by default. Whether you're on a legacy perpetual license or a VCF 9 subscription, confirm that Enterprise services are activated in your HCX deployment before OSAM is scoped into the migration plan. Finding out it's grayed out in the console the week the Sentinel agents are supposed to be deploying is not the right time for that conversation.
Second: the downtime window for OSAM is variable in ways that catch people off guard. Broadcom's own documentation states the conversion process "can vary from minutes to hours depending on virtual machine size and activity." A large Hyper-V VM with heavy disk writes and a significant data footprint can take considerably longer than the initial estimate suggested. OSAM migrations need a tested time estimate based on actual VM profiles, not a generalized planning assumption. Running them in a Saturday morning window without that baseline is how you end up with a migration that was supposed to finish before Monday's business hours still converting VMs on Monday afternoon.
OSAM requires HCX Enterprise service activation. In VCF 4.x/5.x environments this meant a separate Enterprise SKU procurement. Under VCF 9's per-core subscription, HCX is bundled — but Enterprise services still need to be explicitly activated in HCX Operations before OSAM is available. Confirm activation status before the migration plan is finalized.
If HCX Advanced is already in place, upgrading to Enterprise is possible — but the licensing conversation and procurement cycle needs to happen before the Sentinel agents are being deployed, not when they are.
OSAM supports Linux and Windows guests from Hyper-V and KVM sources. Physical-to-virtual migrations using OSAM are also supported but require a vSphere HA-enabled cluster at the destination.
Putting the Right Method on the Right Workload
A realistic large migration program doesn't use one method. It maps each workload tier to the appropriate tool based on actual RTO requirements, source platform, available maintenance windows, and bandwidth reality between sites.
The pattern that works: RAV for tier-1 systems with zero downtime requirements and large enough datasets to benefit from the pre-seeding phase, Bulk for the majority of workloads where a scheduled reboot window is acceptable, vMotion reserved for the handful of applications that are both genuinely downtime-intolerant and small enough that RAV's pre-seeding overhead isn't warranted, and OSAM scoped and licensed separately whenever non-vSphere sources are in the picture.
The planning conversation — method selection, wave sequencing, cutover window sizing, backup agent impact — is worth having before the HCX service mesh is deployed. The problems I've described in this post are all easier to handle on paper than they are during an active migration wave.