VMware License Portability Rules
Subscription licences move freely within the entitled environment, but the entitled environment is itself bounded. Cloud destinations, hosting partners, hybrid topologies, and DR scope each carry their own portability rules. Mis-reading the boundary is the most common audit-finding driver in this area.
VMware licence portability — the question of where, on what hardware, and under what cloud topology a licence can be used — has changed materially under Broadcom. The pre-acquisition portability story was relatively permissive: licences moved freely between hosts within an entitled scope, hybrid-cloud constructs used a defined set of partner programmes, and the principal restrictions were the per-CPU host-association and certain cloud-specific entitlement programmes.
The post-acquisition story is tighter on several axes and looser on a few others. Subscription licences are linked to a defined entitlement rather than to hardware, but the entitlement scope itself is more constrained. Cloud-portability programmes (notably the partner-cloud and dedicated-cloud constructs) have been adjusted. Hybrid deployments crossing the on-premises-to-cloud boundary face revised commercial treatment. The result is a portability map that customers built around pre-acquisition assumptions get materially wrong.
Portability under the per-CPU perpetual model
The pre-acquisition perpetual per-CPU model produced a relatively simple portability story. A perpetual licence was tied to a host (or, more precisely, to a CPU within a host) and moved with the workload provided the destination host was within the entitled scope. Customers operating a fleet of vSphere-licensed hosts could vMotion workloads, rebalance clusters, and reassign capacity within the licensed scope without portability concerns.
The principal portability restrictions were three. First, perpetual licences could not be moved to clouds operated by non-VMware-partner cloud providers without explicit programme participation — the partner-cloud programme governed cloud destinations. Second, certain edition-specific features (notably some vSAN and NSX scope) had host-association requirements. Third, the per-CPU host-association meant that a perpetual licence assigned to a CPU could not be transferred to a different CPU without administrative process.
The mental model the perpetual world produced for customers was that licences they owned could be used widely. The scope of legitimate use was broad provided the host was VMware-licensed.
Portability under the subscription per-core model
The post-acquisition subscription model changes the portability story on multiple axes.
Entitlement-linked, not host-linked
Subscription licences are tied to an entitlement (a defined core count for a defined term), not to specific hosts. Within the entitlement scope, the licensed capacity can be deployed across any compatible host. The host-association rigidity of the perpetual model is gone; the entitlement-scope rigidity of the subscription model replaces it.
The practical effect is that hosts can be added, retired, refreshed, or reconfigured within the entitlement scope without per-host licence transfer process. The subscription covers the cores; the cores can be deployed wherever the customer chooses within the entitled environment.
Entitled environment scope
The entitled environment under a subscription is bounded. VCF subscriptions, for example, cover the customer's on-premises deployment up to the entitled core count. They do not automatically extend to cloud deployments, third-party-operated dedicated clouds, or hybrid constructs unless the entitlement specifies the additional scope.
The scope distinction matters most at the boundary. A workload running on customer-owned on-premises hardware is in scope; the same workload migrated to a hosted-private-cloud arrangement may not be, depending on the contractual scope and the hosting partner's programme participation.
Cloud destination programmes
The partner-cloud programme governing cloud deployment of VMware-licensed software has been restructured. The principal partner programmes — covering AWS, Azure, Google Cloud, IBM Cloud, and Oracle Cloud — remain, but the commercial terms and the entitlement-portability rules have been adjusted. Customers operating in a partner-cloud deployment need to validate current entitlement scope and the cloud-specific licensing arrangements.
The portability of subscription licences within the entitled environment is broad. The portability across the boundary of the entitled environment is constrained. Validate the entitlement scope explicitly before assuming portability to cloud, hosting-partner, or hybrid destinations.
Specific portability scenarios
Host refresh within the licensed environment
Refreshing hosts within the on-premises licensed environment is uncomplicated. The subscription covers cores, not hosts; replacing one host with another within the entitled core count is permitted without licence administration overhead. The customer is responsible for ensuring the post-refresh core count does not exceed the entitled count.
Cluster reorganisation
Reorganising clusters, moving workloads between clusters, and reassigning capacity within the entitled environment is permitted. The subscription does not constrain cluster boundaries; it constrains core counts.
Disaster recovery and standby
Disaster recovery destinations sit at a portability boundary. Cold standby hardware that is not active typically does not consume entitlement, provided it is genuinely cold (powered down, software not running). Warm or active DR destinations consume entitlement on the cores running active software, even if the workload is not in primary production. Customers operating active-active or active-warm DR should validate scope explicitly.
vMotion to alternative on-premises infrastructure
vMotion between hosts within the entitled environment is permitted. vMotion to hardware outside the entitled environment is not. The on-premises environment scope is the relevant boundary.
Cross-site (multi-site) deployments
Multi-site on-premises deployments are covered provided the total core count across sites is within the entitled scope. The cross-site replication and federation features themselves may require specific edition coverage (NSX federation, vSAN stretched cluster) within the entitlement scope.
Cloud destination deployments
Deployment to AWS, Azure, GCP, IBM Cloud, or Oracle Cloud requires participation in the relevant partner-cloud programme. The portability of customer-owned subscription entitlement into the cloud destination depends on the specific programme; some programmes support bring-your-own-licence, others require cloud-specific licensing. The licensing model varies across destinations and requires per-destination validation.
Hosting-partner deployments
Deployment via a hosting partner (a managed-service-provider operating VMware on the customer's behalf) follows the partner's licensing arrangement, which may or may not allow customer-owned entitlement to be used. Some hosting partners require the customer to acquire the underlying VMware subscription separately; others bundle the VMware licensing into the hosting service. The customer needs to validate the licensing structure with the hosting partner.
The hybrid cloud portability question
Hybrid deployments — spanning customer on-premises and cloud destinations — are the most complex portability area. Three patterns are common.
Bursting from on-prem to cloud
Workloads that run primarily on-premises but burst to cloud during peak demand. Under the bursting model, the burst capacity in cloud consumes either bring-your-own-licence entitlement (if the cloud programme supports it) or cloud-provided licensing. The on-premises entitlement does not transparently extend to cloud bursting; the burst destination must have its own licensing arrangement.
Workload migration
Permanent migration of workloads from on-premises to cloud. The on-premises entitlement remains scoped to on-premises; the cloud destination requires its own licensing. Customers planning workload migration need to plan for the licensing transition explicitly, including the possibility of double-running during cut-over.
True hybrid architecture
Architectures where workloads span on-premises and cloud as an architectural choice, not as bursting or migration. These require explicit licensing arrangement for both the on-premises and cloud components, and the bring-your-own-licence portability between them depends on the specific cloud destination's programme participation.
Portability and audit findings
Portability-driven audit findings cluster in three areas.
First, deployment exceeding the entitled core count. The subscription model permits broad portability within the entitled scope, but customers who exceed the entitled core count — whether by host addition, cluster expansion, or under-counted minimum-floor application — produce findings. The audit reconciliation reconciles deployed cores to entitled cores at the subscription level.
Second, deployment outside the entitled environment without supporting entitlement. The most common variant is on-premises entitlement extended to cloud or hosting-partner deployments without the appropriate cloud or partner-programme arrangement. The audit team will identify deployment in destinations the entitlement does not cover.
Third, DR scope mismatches. Active DR destinations counted as "cold" by customers but reconciled as "warm" or "active" by the audit team. The DR-scope question is one of the more contested audit areas; documentation of DR site activity status is the customer-side discipline.
Portability negotiating handles
Portability scope is negotiable at deal time, particularly for customers with hybrid or multi-site deployments.
Multi-site entitlement scope. Explicit language covering multi-site deployment within the entitled core count, including the cross-site replication features required, is worth negotiating into the initial commercial.
DR scope. Explicit language covering DR site scope and the active/cold distinction, including the specific operational conditions under which a DR site is considered cold for entitlement-counting purposes.
Cloud-destination portability. Explicit language covering bring-your-own-licence to specific cloud destinations, including the operational arrangements required to maintain the portability.
Hosting-partner scope. For customers using hosting partners, explicit language covering the bring-your-own-entitlement model with the specific partner.
The general principle is that portability scope is whatever the contract explicitly grants. Customers relying on implicit or assumed portability scope produce findings; customers with explicit contractual scope language defend findings effectively.
Practical guidance for portability planning
For customers planning deployments across the portability boundaries discussed above, four practical recommendations apply.
Document the entitled environment scope explicitly. The on-premises core count, the site list, the cluster list, and the boundary between entitled and unentitled hosts should be documented and maintained. This documentation supports both internal operations and audit defence.
Validate cloud destinations against the relevant programme. AWS, Azure, GCP, IBM Cloud, Oracle Cloud each have distinct programmes; the customer's specific destination requires validation against the programme's current terms.
Plan workload migration with explicit licensing transition. Migration from on-premises to cloud or from cloud to on-premises involves a licensing transition that needs to be planned alongside the workload transition. Double-running during cut-over may be necessary; budget for the licensing implications.
Maintain DR-site documentation. The active/cold status of DR sites and the operational conditions under which each is operated should be documented. The documentation supports the cold-status claim at audit reconciliation.
Portability across the lifecycle of a deployment
Portability questions appear at predictable points in the deployment lifecycle, and customers benefit from anticipating them rather than addressing them reactively.
Initial deployment
At initial deployment, document the entitled environment scope explicitly: sites, data centres, clusters, host inventory, and the boundary between entitled and unentitled hosts. The documentation forms the baseline against which subsequent changes are reconciled.
Capacity expansion
Capacity expansions within the entitled environment require core-count validation against the entitled count. Expansion that pushes the deployment beyond the entitled count requires either entitlement uplift or migration of workload to other parts of the estate.
Hardware refresh
Hardware refresh decisions need to account for the entitled-environment scope. Replacement hardware within the entitled environment is uncomplicated; refresh that changes the entitled-environment scope (consolidation onto fewer sites, expansion to additional sites) requires entitlement-scope adjustment.
Cloud migration
Migration of workload from on-premises entitled environment to cloud destinations requires cloud-side licensing arrangement; the on-premises entitlement does not transparently extend. Plan the licensing transition alongside the workload transition.
DR-site adjustment
Changes to DR-site posture — from cold to warm, from warm to active, from a single DR site to multiple sites — produce portability implications that need to be reconciled against the entitlement scope.
Renewal
The renewal cycle is the natural point at which portability scope can be re-negotiated to reflect the customer's actual deployment topology. Multi-site, hybrid, and DR-scope language should be updated at renewal to match the operational reality.
Documenting portability scope for audit defence
Portability-related audit findings depend heavily on documentation quality. Several documentation practices support strong audit defence.
Maintain a current entitled-environment register, refreshed quarterly. The register should list sites, data centres, clusters, and the host inventory at each, with the licensed entitlement attributed across the inventory.
Document deviation events explicitly. When deployment scope expands beyond the entitled environment (intentionally or otherwise), document the deviation, the date of the deviation, the remediation action, and the date of remediation completion. The documentation supports the audit-defence position that deviations were detected and addressed.
Maintain cloud-destination programme participation records. Each cloud destination's programme participation, contract details, and entitlement-coverage arrangement should be retained in the entitlement records.
Maintain DR-site operational records. For DR sites operating in a cold or warm posture, document the operational conditions: power state, software activation state, workload activation state, and any operational events that may have changed the posture temporarily.
Related reading
For deeper detail on adjacent topics, see the VMware licensing complete guide, VCF licensing explained, per-core licensing mechanics, VMware Cloud on AWS licensing, and our VMware audit defence guide.