The Broadcom transition and the perpetual sunset.
The Broadcom acquisition of VMware closed in late 2023 and was followed by a deliberate repricing of the VMware estate. The perpetual licence model that had defined the VMware commercial position for two decades was withdrawn; the SKU catalogue was compressed into two principal bundles, VMware Cloud Foundation (VCF) and VMware vSphere Foundation (VVF); and the consumption metric moved firmly to a per-core annual subscription.
The transition produces three immediate consequences for the buyer. Firstly, the existing perpetual licences continue to entitle the buyer to use the current version, but Subscription and Support renewal is no longer the path forward; the renewal is to the new subscription model. Secondly, the new subscription model bundles a broader set of components than the legacy vSphere standalone, raising the entry price for buyers who used only the hypervisor. Thirdly, the renewal price under the new model has shifted upward, on average, materially.
The buyer at the first VCF renewal under Broadcom ownership therefore faces a discontinuity. The price comparison against the legacy perpetual position is not informative; the bundle composition is different and the metric is different. The question is no longer ‘is the renewal price reasonable against last year’, but ‘is the renewal price reasonable against the alternative’.
This paper is the buyer-side answer to the second question. It sets out the alternative stacks, the cost of each alternative, the staged migration design and the renegotiation leverage that the exit posture creates at the Broadcom table.
The cost of stay.
The cost of stay is the cost of remaining on VCF or VVF through the renewal. The cost of stay comprises four components: the subscription price (per-core, annual), the bundled component cost (the components inside VCF that the buyer pays for whether or not they are used), the support cost (now bundled into the subscription) and the renewal escalator (the year-on-year price movement built into the contract).
The subscription is per physical core. Where the legacy estate ran on a per-CPU model with an unlimited-core-per-CPU position, the move to per-core can produce a substantial uplift on dense modern servers. The buyer position at the renewal should be informed by an inventory of the deployed cores, not the deployed CPUs.
The bundle composition matters. VCF includes vSphere, vSAN, NSX, Aria and a set of management capabilities. Where the buyer does not use vSAN (because storage is on a separate array) or does not use NSX (because the network is on a third-party SDN), the bundle includes capability the buyer is paying for and not using. The buyer position should be that the bundle cost is justified only where the bundled components are deployed at meaningful scale.
The renewal escalator is the third component. Broadcom contracts typically carry a year-on-year escalator; the escalator over a three-year term, compounded, is material to the planning horizon. The cost of stay should be modelled over the full planning horizon (typically five years for an infrastructure decision), with the escalator compounded across each year.
The cost of move.
The cost of move comprises six components: the alternative-stack licence cost, the migration tooling cost, the training cost, the dual-run period (where both stacks operate in parallel during the transition), the hardware refresh implication (where the alternative requires different hardware or a different storage architecture) and the residual-value position on the existing VMware investment.
The alternative-stack licence cost is the published list price of the alternative, discounted by the alternative vendor’s discounting position. For a major migration, the alternative vendors will compete; the buyer should run a structured dual-quote process and should use the dual quote as the price discovery mechanism.
The migration tooling cost is the cost of the migration engine (e.g., Nutanix Move, OpenShift Migration Toolkit for Virtualisation, Proxmox migration tooling) plus the cost of the storage migration (where the destination uses a different storage architecture). The migration tooling cost is typically a small line item compared to the rest of the move; it should be costed but not over-emphasised.
The training cost is real and is often underestimated. Each alternative carries its own operational model; the storage primitives, the networking primitives, the monitoring and the day-two operations differ. The buyer should budget for the training, the runbook rewrites, the monitoring integration and the build-up of operational confidence over the dual-run period.
The dual-run period is the largest line item in the cost of move. During the dual-run, both stacks are operating; the licence costs of both stacks accumulate; the operational overhead of both stacks accumulates. The dual-run period should be modelled honestly. A six-month dual-run is realistic for a small estate; a two-year dual-run is realistic for a large enterprise estate.
The hardware refresh implication is contingent on the alternative selected. Nutanix and Proxmox can typically run on the existing server hardware, although the storage architecture often changes; the hyperscaler-native landing zones change the hardware question entirely. The buyer position should be that the hardware refresh is costed against the natural refresh cycle, not against the migration in isolation.
Nutanix AHV as a primary alternative.
Nutanix Cloud Platform is the most direct alternative to VCF. The AHV hypervisor is bundled with the Nutanix subscription, the Prism management plane replaces vCenter, and the Nutanix storage architecture replaces vSAN. The platform is sold on a per-core subscription with bundled storage and software-defined networking; the bundle is narrower than VCF, the price point is, in most buyer-side comparisons, materially lower.
The migration path from vSphere to AHV runs through Nutanix Move, a free migration utility that handles the in-place conversion of VMs. The conversion is generally clean for standard Linux and Windows workloads; non-standard workloads (heavy-customisation appliances, embedded virtual-network functions, hardware-passthrough configurations) require additional handling.
The Nutanix posture is well-suited to two profiles. Firstly, buyers who are running vSphere on Cisco UCS, Dell PowerEdge or HPE ProLiant servers and are content with a forward-compatible hardware refresh on the Nutanix HCI appliance line. Secondly, buyers who want a single-vendor stack covering compute, storage and networking, replacing the multi-vendor VMware-plus-array architecture.
The Nutanix posture is less well-suited to estates with heavy specific dependencies on NSX (NSX-T security policies that do not map cleanly to AHV), heavy dependencies on Aria for end-to-end automation, or where the storage estate is on a high-end SAN that the buyer is unwilling to deprecate.
Red Hat OpenShift Virtualisation.
OpenShift Virtualisation is the Red Hat (and now IBM, post-acquisition) answer to the VMware question. The platform is built on KubeVirt, an open-source project that runs virtual machines as Kubernetes-managed workloads. The platform is sold on a per-core subscription as part of the OpenShift Platform Plus or OpenShift Virtualisation Engine SKUs; the bundle includes the container platform alongside the virtualisation layer.
The OpenShift posture is well-suited to estates that are already moving toward container-native operations. The same operational toolchain runs both the containers and the virtual machines; the same security model, the same storage primitives, the same networking constructs. For a buyer that is on the container journey, OpenShift Virtualisation reduces the number of platforms in production.
The migration path from vSphere to OpenShift Virtualisation runs through the Migration Toolkit for Virtualisation (MTV), a Red Hat utility that handles the workload conversion. The conversion is well-supported for standard workloads; complex workloads may require remediation in the operational model.
The OpenShift posture carries a commercial nuance worth flagging. The Red Hat subscriptions sit inside the IBM commercial relationship post the Red Hat acquisition. Buyers with an existing IBM Passport Advantage estate should reconcile the OpenShift entitlement against the Cloud Pak position; the entitlement reconciliation is set out in the companion IBM Passport Advantage paper.
Proxmox VE and the open-source posture.
Proxmox Virtual Environment is the open-source alternative. The platform combines KVM virtualisation and LXC containers under a single management interface, with optional commercial support subscriptions from Proxmox Server Solutions GmbH. The price point of the support subscription is, in buyer-side comparisons, an order of magnitude below the VCF subscription.
The Proxmox posture is well-suited to two profiles. Firstly, mid-market enterprises where the operational complexity of the VMware estate has historically been a luxury rather than a necessity; the simpler Proxmox operational model is a net positive. Secondly, large enterprises with selected workloads that do not require the VMware feature set, where Proxmox can be deployed as a tier-two virtualisation layer for these workloads at a fraction of the cost.
The Proxmox posture is less well-suited to estates with heavy dependencies on VMware-specific operational tooling, heavy compliance requirements that require commercial support attestation at every layer, or where the in-house Linux skills are not at the level required to operate the platform with confidence.
The Proxmox case is often best made not as a wholesale replacement for the VMware estate but as a tier-two platform for a subset of workloads; the rest of the estate then renegotiates the VMware subscription against a smaller core count, the leverage from the partial exit is realised, and the operational complexity of running two platforms is contained within a defined boundary.
Hyperscaler-native landing zones.
The hyperscalers each offer a VMware-on-cloud landing zone (Azure VMware Solution, AWS VMware Cloud, Google Cloud VMware Engine). The landing zones run the VMware stack on hyperscaler hardware, with the hyperscaler taking on the operational responsibility. From a licensing perspective, the landing zones are an extension of the VMware commercial relationship, not an alternative to it; the buyer continues to pay VMware-derived costs, with the hyperscaler taking margin.
The landing zones are best understood as a transition layer, not a destination. Workloads can be moved out of the on-premises VMware estate into the hyperscaler-native VMware estate at low conversion cost (it is the same hypervisor, the same management plane), and then progressively rationalised onto the hyperscaler-native primitives (Azure Virtual Machines, EC2, Compute Engine). The landing zone buys the buyer time and a different operational profile; it does not, by itself, reduce the VMware commercial dependency.
For buyers who are already heavy in one hyperscaler, the landing-zone path can be economically attractive over the planning horizon if the workloads are rationalised onto the native primitives. The economics of the rationalisation should be modelled honestly, including the egress cost on the way in and the egress cost on the way out. The egress economics are covered in the AWS EDP Commitment paper and the Azure MACC paper.
The staged migration design.
The staged migration runs in four phases. The phasing matters: a single big-bang migration is high-risk and unlikely to complete on the timeline that a renewal window will allow; a staged migration with clear gates between phases is a better fit for the renewal-driven economic logic.
- Workload classification. The estate is classified across three dimensions: workload criticality (tier-one, tier-two, tier-three), VMware-feature dependency (heavy NSX, heavy vSAN, light), and operational maturity of the alternative for that workload type. The classification produces the migration order.
- Pilot migration. A small set of tier-three workloads with light VMware-feature dependency are migrated to the chosen alternative. The pilot establishes the operational toolchain, the runbook, the monitoring integration and the team capability. The pilot lasts a defined period and produces a written go/no-go decision before the next phase opens.
- Bulk migration. The tier-three and tier-two workloads are migrated through the established toolchain. The bulk phase runs in dual-run mode: the workloads on the alternative are kept warm against the VMware-side workloads until operational confidence is established. The phase has a defined exit criterion (typically, the proportion of workloads that have completed thirty days clean on the alternative).
- Tier-one migration. The tier-one workloads are migrated last, with the operational team at full confidence on the alternative platform. The tier-one phase is often run with a rollback position on the VMware estate held warm for a defined window, after which the VMware estate is decommissioned and the cost of stay falls away.
The four-phase design is the typical Admodum recommendation. The shape of the design is adjusted to the specifics of the estate and the renewal window. The discipline is to define the gates between phases in writing, with a clear go/no-go decision at each gate, so that the migration can be paused, rolled back or accelerated according to the operational reality.
The renegotiation leverage.
The renegotiation leverage is the outcome the buyer is often most interested in, and it is the outcome the exit architecture most directly produces. A credible, costed, board-approved exit architecture changes the buyer position at the Broadcom renewal table in three ways.
Firstly, it sets a price ceiling. The buyer position at the table is that the renewal price cannot exceed the cost-of-move over the planning horizon. Where the cost of stay exceeds the cost of move plus the cost of the alternative, the buyer takes the alternative. The price ceiling is now the cost-of-move number plus a small premium that reflects the operational continuity of staying.
Secondly, it forces bundle justification. The buyer position at the table is that the bundle composition must be justified. Where the bundle includes capability the buyer does not use, the bundle is unbundled in the negotiation: the renewal is for the components actually deployed, not the full bundle. This is a hard negotiation; the credible exit posture is the leverage that opens it.
Thirdly, it contains the escalator. The buyer position at the table is that the year-on-year escalator must be capped at a defined number. Where the escalator is uncapped, the alternative becomes more attractive each year by the compounding amount; the credible exit makes this case explicit at the renewal table.
The three leverage points each produce a separate negotiation. The Admodum experience is that the credible exit architecture, presented as a board-approved document at the opening of the renewal negotiation, produces a renewal outcome materially different from the renewal that would otherwise be reached. The work to build the architecture is the work that creates the leverage.
Reading list and references.
This paper sits alongside three companion Admodum papers and the Broadcom / VMware practice page.
The VMware Cloud Foundation transition paper covers the inside of the VCF subscription itself: the bundle composition, the per-core mechanics, the perpetual sunset and the renewal posture at the first cycle under Broadcom ownership. Read alongside this paper inside a Broadcom engagement.
The IBM Passport Advantage paper covers the Red Hat overlay inside the IBM commercial relationship. Where the alternative selected is OpenShift Virtualisation, the IBM commercial relationship is a load-bearing input to the cost of move.
The Azure MACC design and defence paper covers the consumption economics on Azure. Where the alternative selected is Azure VMware Solution or Azure native, the MACC commitment design is the load-bearing input to the cost arithmetic.
For the Broadcom / VMware practice itself, see the Broadcom / VMware practice page and the Broadcom Knowledge Hub. For the engagement model, see fixed fee, contingency or annual retainer. For the programme that closes the renewal, see the Renewal Programme; for the benchmark that anchors the renewal price, see the Benchmarking Programme.
