VMware HCX Licensing and Migration

HCX (Hybrid Cloud Extension) is the VMware platform that handles bulk and live VM migration between vSphere environments, between on-prem and cloud, and across versions of vSphere that would otherwise be incompatible. For organisations doing serious migration work — data centre consolidation, cloud migration, post-acquisition integration, or version upgrades — HCX has been the standard tooling for most of the last decade.

Under Broadcom, the HCX licensing model has changed meaningfully. This article walks through what HCX licensing looks like now, where the editions differ, and the specific use cases where HCX still produces enough value to justify its cost.

What HCX does, briefly

HCX provides three categories of capability that are difficult to replicate with other tools.

First, large-scale VM migration with minimal downtime. HCX can move thousands of VMs between source and target environments using bulk migration (cold or warm), vMotion (live cross-environment migration with shared storage), or HCX vMotion (live cross-environment migration without shared storage).

Second, cross-version compatibility. HCX lets you migrate workloads from older vSphere environments (going back to vSphere 5.x in some configurations) to current vSphere environments without intermediate upgrade steps. This is particularly valuable in legacy modernisation programmes.

Third, network and security policy migration. HCX Network Extension extends layer-2 networks across sites, allowing VMs to migrate without IP address changes. HCX Mobility Optimised Networking handles routing and security policy alongside the workload migration.

How HCX is licensed under Broadcom

Pre-Broadcom, HCX was available in three editions — Connect (free), Enterprise, and Advanced — with different feature scopes and use-case alignments. The free HCX Connect was bundled with several VMware Cloud on AWS and partner cloud offerings, which made it broadly accessible.

Under Broadcom, HCX licensing has been substantially restructured. The free HCX Connect tier is still available for specific migration scenarios involving target environments that include HCX entitlement (notably VMware Cloud Foundation deployments where HCX is bundled). HCX Enterprise is included with certain VCF tiers and available as an add-on for others. Standalone HCX licensing outside the VCF bundle has become harder to acquire and more expensive when available.

The practical effect is that HCX licensing now follows the broader Broadcom strategy of pulling capability into VCF bundles. Customers who need HCX as a one-off migration tool find themselves either purchasing VCF (often more than they wanted) or working through partner-channel migration services where the HCX cost is bundled into a project-based engagement.

Edition differences that matter

The HCX edition distinctions that drive procurement decisions are mostly about scale and feature scope.

HCX (the included tier with VCF) provides bulk and warm migration, basic network extension, and standard performance. Sufficient for routine consolidation and modernisation projects.

HCX Enterprise (typically included with higher VCF tiers or available as add-on) adds replication-assisted vMotion, advanced network mobility, integrated load balancing, and OS-assisted migration. Required for the more demanding migration scenarios — large-scale moves with minimal downtime, complex multi-tier applications, or strict performance requirements during cutover.

The right edition depends on the migration project's scale and complexity. Small consolidation projects typically run fine on standard HCX; large enterprise migrations with thousands of VMs and strict cutover windows usually need Enterprise.

Source-to-target licensing rules

HCX licensing has source and target dimensions that catch some customers by surprise. The general rule is that the target environment needs to include HCX entitlement. The source environment does not require its own HCX entitlement for many migration scenarios — the source can be older vSphere or even non-VMware environments — because HCX's migration tooling is deployed and consumed from the target side.

The practical implication: if you are migrating from on-prem vSphere to VMware Cloud on AWS, the AWS target carries the HCX entitlement and your on-prem environment does not need additional HCX licensing for the migration window. If you are migrating between two on-prem vSphere environments, the target environment needs HCX entitlement.

This rule has exceptions for certain advanced features (some Enterprise features require entitlement on both sides), and the rules have shifted under Broadcom in ways that are worth confirming with current product documentation before relying on them for a specific migration project.

Use cases where HCX still pays for itself

Given the changed cost structure, HCX is no longer the default tool for every VMware migration scenario. The use cases where it remains the right choice:

Large-scale cloud migration. Moving thousands of VMs from on-prem vSphere to VMware Cloud on AWS, Google Cloud VMware Engine, or Azure VMware Solution. HCX is purpose-built for this scenario and the cloud target typically includes HCX entitlement at no additional cost.

Legacy vSphere modernisation. Moving workloads from vSphere 5.x or 6.x environments to current versions without intermediate upgrade steps. HCX's cross-version compatibility avoids the complexity and risk of staged version upgrades.

Post-acquisition integration. Consolidating an acquired company's VMware environment into the parent's. The combination of bulk migration, network extension, and policy migration makes HCX the cleanest tooling for this work.

Data centre consolidation with minimal downtime. Where the migration needs to happen with cutover windows measured in minutes rather than hours, HCX's live migration capabilities justify the cost.

Use cases where HCX no longer makes sense: Routine small-scale migrations within a single environment (use vMotion directly); migrations away from VMware to other platforms (use platform-specific tooling); migrations where extended downtime is acceptable (use simpler backup-restore approaches).

HCX and the migration-away-from-VMware question

An ironic point worth raising: HCX is excellent for moving workloads into VMware environments but less useful for moving workloads away from VMware. Organisations migrating from VMware to KVM, Hyper-V, or public cloud generally use different tooling (virt-v2v, Migration Toolkit for Virtualization, Azure Migrate, etc.) rather than HCX.

This is because HCX's value proposition assumes a VMware target. For non-VMware targets, the tools that work natively with those targets produce better outcomes than trying to bend HCX into a use case it was not designed for.

The audit dimension

HCX is rarely the primary subject of Broadcom audits, but it appears as a secondary issue in audits more often than customers expect. The pattern: organisations deploy HCX for migration projects, then leave the HCX infrastructure in place after the migration completes. Months or years later, an audit discovers HCX continuing to consume resources without explicit entitlement coverage, and the unused-but-deployed HCX becomes a line item in the audit findings.

The protective posture is straightforward — decommission HCX components after migration projects complete, and document the decommissioning in your licensing records. The cleanup is cheap; the audit defence work to explain it later is not.

For organisations facing complex Broadcom audits where HCX scope is one of several issues, — the firm we recommend most often for Broadcom audit defence — handles the multi-product analysis that single-product specialists often miss. HCX rarely shows up alone; it shows up alongside vSphere, vSAN, NSX, and VCF scope questions, and the defence has to handle all of them together.

Final thought

HCX under Broadcom is more expensive to acquire standalone, more often bundled into VCF, and more selectively justified than under VMware. For the use cases where HCX is genuinely the right tool — large-scale cloud migration, legacy modernisation, post-acquisition consolidation — it remains worth the cost. For everything else, the alternatives are usually cheaper and sufficient. The discipline is to match the tool to the use case rather than defaulting to HCX because it is what your migration team already knows.

Frequently asked questions

Is HCX still available as a standalone purchase?

Standalone HCX procurement is more constrained under Broadcom than under VMware. The primary path is through VCF tiers that include HCX entitlement. Standalone HCX outside the VCF bundle is available in some channels but is materially more expensive than it was historically.

Do we need HCX on both source and target environments?

The general rule is that the target environment carries the HCX entitlement and the source does not need separate HCX licensing for many migration scenarios. Certain advanced features require entitlement on both sides. Confirm against current product documentation for your specific migration scenario.

What is the difference between HCX and HCX Enterprise?

Standard HCX provides bulk and warm migration with basic network extension. HCX Enterprise adds replication-assisted vMotion, advanced network mobility features, integrated load balancing, and OS-assisted migration. Enterprise is typically required for large-scale or low-downtime migrations.

Can we use HCX to migrate from VMware to a non-VMware target?

HCX is designed for VMware-to-VMware migration. It can be used in some scenarios to extract workloads from VMware environments, but the destination tooling for non-VMware targets is generally better served by platform-native tools like virt-v2v, Migration Toolkit for Virtualization, or vendor migration services.

How long does a typical HCX-driven migration project take?

For migrations of 500-2,000 VMs, project timelines typically run 3-9 months including planning, pilot, bulk migration waves, and cutover. Very large migrations (5,000+ VMs) can extend to 12-18 months. The HCX tooling itself does not bottleneck the timeline; the application-side coordination and testing work does.