VCF Migration: The Complete Guide for 2026

Since the Broadcom acquisition of VMware closed in November 2023, the migration of customer environments to VMware Cloud Foundation (VCF) has become the central commercial event in the VMware portfolio. The migration is presented to customers as a technology upgrade — a unified, software-defined data centre stack with integrated management. The commercial reality is that the migration is a fundamental restructuring of the customer's licensing position, with cost, contractual, and operational implications that extend over the full term of the new subscription. This guide is the comprehensive playbook for customers facing a VCF migration in 2026, written for the CIO, the architecture lead, the licensing manager, and the procurement officer who together carry the decision.

This is a long read because the migration is a long decision. We have made no attempt to shorten it, because the decisions described here will shape three to five years of VMware spend, three to five years of operational posture, and the customer's exit options should the relationship deteriorate. The customers we work with read this guide carefully, then come back to specific sections as their migration progresses. We have organised it for that pattern of use.

What VCF actually is

VMware Cloud Foundation (VCF) is a bundled subscription that combines vSphere (the hypervisor), vSAN (storage), NSX (networking), and Aria (operations and automation) into a single subscription SKU. The bundle is delivered with a unified lifecycle manager (the SDDC Manager), with the explicit Broadcom positioning being that the integration reduces operational complexity and eliminates the need to license the components individually.

The technical components are largely the same software the customer has been running individually for years. vSphere in VCF is the same vSphere; vSAN in VCF is the same vSAN; NSX in VCF is the same NSX. What changes is the licensing model (bundled subscription per core, with vSAN capacity included up to a threshold and licensed beyond it), the delivery model (SDDC Manager-driven lifecycle), and the commercial relationship (a multi-year subscription commitment, typically three years minimum).

VCF is currently offered in two principal editions: VCF (the full bundle including all components) and VVF (VMware vSphere Foundation, a more limited bundle including vSphere, vSAN, and a smaller Aria footprint, without NSX). Customers should not assume that VCF is the appropriate edition; VVF is frequently the better fit and is materially less expensive.

The commercial structure of a VCF migration

A VCF migration is commercially a conversion from the customer's existing licensing position (typically perpetual entitlements with SnS) to a subscription position. The conversion has three commercial dimensions: the immediate cost of the subscription; the disposition of incumbent perpetual entitlements; and the long-term commitment to subscription pricing.

The immediate cost

The immediate cost of a VCF subscription is, in our recent engagements, typically 4x to 6x the equivalent perpetual cost on an annualised basis. A customer who was paying $100 per core per year in SnS on a perpetual vSphere Enterprise Plus entitlement will typically face $400 to $600 per core per year in VCF subscription, depending on the specific edition, the negotiated discount, and the inclusion of optional components.

This is not a typographical anomaly. The price multiple is the commercial intent of the conversion. Broadcom's revenue model assumes a substantial subscription price relative to historical perpetual pricing, and the multiple is consistent across the customer base. Customers who expect to convert at parity with their previous SnS spend are routinely surprised by the actual quote.

The disposition of incumbent perpetual entitlements

The customer's incumbent perpetual entitlements have residual value. The customer paid for them, the customer continues to hold them, and the customer's right to use them in production is preserved by the perpetual grant. The disposition of these entitlements in the migration is a negotiation point that Broadcom typically prefers to leave undefined.

Three dispositions are possible. The customer can retain the perpetual entitlements, run them in parallel with VCF for a period, and use them as a fallback if the migration is unsuccessful. The customer can trade the perpetual entitlements to Broadcom for credit against the VCF subscription. The customer can simply allow the perpetual entitlements to lapse out of relevance as VCF takes over.

The first disposition (retention) preserves the most customer optionality and should be the default. The second (trade-in) can be commercially attractive if Broadcom offers a substantial credit. The third (lapse) is the disposition most customers default to and is the least favourable. Customers should explicitly negotiate the disposition of their perpetual entitlements as part of the VCF migration deal.

The long-term commitment

The VCF subscription is a multi-year commitment with renewal at term end. The renewal price is not contractually fixed. Broadcom typically reserves the right to set the renewal price at the prevailing list, subject to whatever discount can be negotiated at renewal. This creates a long-term price exposure that customers should structure into the initial deal.

The protective measures customers should negotiate at initial VCF execution include: price protection for renewal (a cap on year-over-year price increase, typically 5-7%); right of first negotiation at renewal (a defined period during which Broadcom must engage in good-faith renewal discussion before terminating); and a defined renewal scope (the products that will be available at renewal at protected pricing). Without these protections, the renewal becomes a fresh negotiation at whatever price Broadcom proposes.

The technical structure of a VCF migration

VCF is delivered as a software-defined data centre (SDDC) stack. The stack is deployed in workload domains, with each workload domain being a group of vSphere clusters managed under a common configuration. The first workload domain is the management domain, which runs SDDC Manager and the infrastructure services for the rest of the VCF deployment.

The management domain

The management domain is the foundation of VCF. It runs SDDC Manager, vCenter, NSX Manager, and the lifecycle services that drive the rest of the deployment. The management domain is typically deployed first, on dedicated hardware, and is the platform from which all subsequent workload domains are deployed.

The management domain has minimum hardware requirements that exceed the requirements for the workload it directly runs. Customers migrating from existing vSphere environments frequently underestimate the management overhead, which can add 10-20% to the hardware requirement of the overall VCF deployment.

Workload domains

Workload domains are deployed under the management domain and host the customer's actual workloads. Each workload domain is a logical grouping of vSphere clusters with a common configuration. Workload domains can be deployed in different configurations — production, test, development, disaster recovery — with different sizing, different storage policies, and different network configurations.

The number and structure of workload domains is a substantial architectural decision. Too few workload domains creates a rigid environment that does not segregate workloads appropriately. Too many workload domains increases management overhead and licensing complexity. The typical pattern we see in successful migrations is two to four workload domains: one for production, one for non-production, one for disaster recovery, and (in some cases) one for management or specialised workloads.

The migration sequence

VCF migrations typically follow a structured sequence: deployment of the management domain on greenfield hardware; deployment of the first workload domain; migration of pilot workloads (typically 20-50 VMs) to validate the configuration; migration of the bulk of production workloads in phases; decommissioning of the legacy vSphere environment. The full sequence typically takes 12 to 24 months for an enterprise of substantial size.

The cost framework

The cost of a VCF migration extends beyond the subscription cost. The full cost model includes the subscription itself, the hardware refresh required to meet VCF specifications, the professional services for deployment and migration, the operational change costs, and the parallel-run costs during the migration period.

Hardware refresh

VCF has specific hardware requirements that are typically more stringent than the requirements for individual vSphere deployments. SDDC Manager has minimum CPU, RAM, and storage requirements. vSAN within VCF requires specific disk configurations (all-flash for the cache tier, capacity disks of supported models). NSX within VCF has network adapter and bandwidth requirements that exceed standard vSphere networking.

Customers migrating from existing vSphere environments frequently find that 30-50% of their existing hardware does not meet VCF requirements. The hardware refresh adds substantially to the total migration cost — typically $1,500 to $3,000 per server, or more for specialised storage and networking hardware.

Professional services

VCF deployment requires specialised skills that most customer organisations do not maintain in house. Broadcom partners and Broadcom Professional Services offer deployment engagements typically priced at $200,000 to $1.5 million depending on the scope, the customer's environment, and the complexity of the migration.

Customers should evaluate professional services from multiple providers, including Broadcom-aligned consultancies, independent VCF specialists, and the established hyperscaler partner ecosystem (where the customer is deploying VCF on VMware Cloud on AWS, Azure VMware Solution, or Google Cloud VMware Engine). The pricing differentials between providers can exceed 50%.

Operational change costs

VCF introduces operational patterns that differ from the patterns most customer organisations have developed around standalone vSphere. SDDC Manager-driven lifecycle, integrated NSX networking, vSAN storage policies, and Aria-driven automation each require operational changes. Training, runbook updates, monitoring integration, and process redesign together add typically $50,000 to $500,000 in operational change costs over the migration period.

Parallel-run costs

During the migration period (typically 12 to 24 months), the customer is running both the legacy vSphere environment and the new VCF environment. The legacy environment continues to consume SnS, power, cooling, and operational support. The parallel-run period adds typically 10-25% to the customer's annual VMware spend during the migration year.

The architecture decisions

The architecture of the VCF deployment is shaped by several decisions that should be made early in the migration planning and that are difficult to change later.

Edition selection

The choice between VCF and VVF is the first edition decision. VCF includes NSX, which is appropriate for customers who use network virtualisation, micro-segmentation, or software-defined networking. VVF excludes NSX and is appropriate for customers whose networking is provided by traditional physical infrastructure or by an alternative software-defined platform.

The price differential is substantial. VVF is typically 60-70% of the price of VCF for the same core count. Customers who do not use NSX should default to VVF and add NSX as a separate purchase if needed, rather than defaulting to VCF and discovering at deployment that NSX is not used.

Deployment topology

VCF can be deployed on premise (in the customer's own data centre), on hyperscaler infrastructure (VMware Cloud on AWS, Azure VMware Solution, Google Cloud VMware Engine), or in a hybrid topology. The choice has substantial cost, performance, and contractual implications.

On-premise deployment preserves the customer's existing data centre investments and operational patterns. Hyperscaler deployment offloads infrastructure management but introduces a triangular commercial relationship between the customer, Broadcom, and the hyperscaler. Hybrid deployment provides flexibility but introduces substantial complexity in lifecycle management and licensing.

Sizing

VCF sizing should be based on the customer's actual workload requirements, not on the auditor's assertion of the customer's deployment footprint. Customers who size VCF based on auditor methodology typically over-provision substantially — buying VCF for cluster cores that are running non-VCF workloads or that are idle. Independent sizing based on actual workload analysis typically reduces the VCF subscription by 20-40%.

vSAN inclusion

vSAN is included in VCF up to a defined capacity threshold (typically 1 TiB per core, depending on the edition). Customers whose vSAN deployment exceeds the included threshold must purchase additional vSAN capacity, which is a separate line item with its own pricing structure. The vSAN sizing should be done explicitly and documented in the deal.

The migration playbook

The following playbook is the structure we have seen in the most successful VCF migrations we have supported. It is not the only structure, but it captures the elements that consistently produce favourable outcomes.

Phase 1: Planning (months 1-3)

The planning phase establishes the architecture, the commercial structure, and the operational plan. The deliverables include an architectural design document, a workload migration sequence, a hardware refresh plan, a professional services scope of work, a commercial term sheet with Broadcom, and an executive-level cost model covering the full migration period.

The planning phase is also when the commercial negotiation with Broadcom is most influential. Customers who finalise the architecture before the commercial negotiation have substantially less leverage; the negotiation positions are driven by alternative paths the customer can credibly take. Planning should preserve commercial optionality.

Phase 2: Foundation (months 4-6)

The foundation phase deploys the management domain, the first workload domain, and the initial integration with existing services (Active Directory, certificate authorities, monitoring, backup). The foundation phase is typically executed by professional services with customer engineering shadowing the work to build internal expertise.

Phase 3: Pilot migration (months 7-9)

The pilot migration moves a defined set of workloads (typically 20-50 VMs covering a representative mix of operational characteristics) to validate the deployment, the operational runbooks, and the support model. The pilot is the last opportunity to identify architectural or operational issues before scaling.

Phase 4: Production migration (months 10-21)

The production migration moves the bulk of the customer's vSphere workloads to VCF in phases. The phasing is typically driven by application criticality, change windows, and dependency relationships. Most enterprises migrate 50-200 VMs per change window, with windows scheduled weekly or biweekly.

Phase 5: Decommissioning (months 22-24)

The decommissioning phase removes the legacy vSphere environment, terminates the legacy SnS, and finalises the licensing position. The decommissioning is also the point at which the customer's commitment to VCF becomes effectively irreversible; the legacy environment, once decommissioned, is not easily restored.

Common migration failure modes

The migrations that go badly typically fail in one of a small number of recognisable ways. Each failure mode is preventable with planning.

Insufficient sizing analysis

Customers who size VCF based on Broadcom's recommended sizing or based on the auditor's deployment assertion routinely over-provision. The over-provisioning is locked in for the term of the subscription. Independent sizing analysis, based on the customer's actual workload characteristics, is the single most impactful cost-reduction step.

Hardware compatibility surprises

Customers who do not validate hardware compatibility before commercial commitment to VCF frequently discover that material portions of their existing hardware do not meet VCF requirements. The hardware refresh becomes a constraint on the migration timeline and adds substantial unbudgeted cost.

NSX scope creep

Customers who select VCF (including NSX) without a clear plan for NSX adoption frequently spend substantial professional services budget integrating NSX during the migration, only to use NSX in limited ways post-migration. VVF (excluding NSX) is the better choice for customers without a clear NSX use case.

Inadequate parallel-run planning

Customers who underestimate the parallel-run period frequently face budget pressure mid-migration that constrains the technical execution. The parallel run is real and should be funded explicitly.

Migration during audit

Customers who initiate VCF migration while an audit is in progress effectively concede the audit's licensing position. The migration becomes the remediation, and the customer loses the negotiating leverage that defence of the audit position provides. The migration and the audit defence should be sequenced — defence first, migration after settlement.

The exit options

No VCF migration should be undertaken without a documented exit strategy. The exit options include: continuation on perpetual entitlements (preserved through the migration); migration to an alternative hypervisor (Nutanix AHV, Microsoft Hyper-V, Proxmox VE, open-source KVM); migration to hyperscaler-native infrastructure (Azure, AWS, GCP without VMware); or hybrid approaches that combine VCF for some workloads with alternative platforms for others.

The documented exit strategy is a planning artefact, not a current commitment. Its purpose is to inform the architectural decisions made during the VCF migration in ways that preserve future optionality, and to provide the commercial leverage that protects the renewal negotiation.

What good looks like

A well-executed VCF migration completes within 18-24 months at a total cost (subscription, hardware, services, operations) that is competitive with the alternative paths the customer evaluated. The architecture is appropriate for the customer's actual workload requirements. The licensing position is documented and clean. The commercial relationship with Broadcom is structured with renewal protections that constrain the long-term price exposure. The customer's operational organisation has absorbed the VCF operational patterns. The exit options are documented.

A poorly executed VCF migration completes late, over budget, with an architecture that over-provisions, with operational patterns that have not adapted, and with no exit options. The renewal negotiation at year three becomes a fresh negotiation at whatever price Broadcom proposes, with the customer's only alternative being a multi-year migration to a different platform that the customer has not planned for.

The difference between the two outcomes is, in our experience, primarily a function of the discipline applied to the planning phase and the commercial structure. The technical execution of VCF migrations is well understood by the partner ecosystem. The commercial and architectural decisions are where the variance lives.

The bottom line

A VCF migration is a fundamental restructuring of the customer's VMware relationship. The migration is technically a deployment exercise; commercially it is a multi-year subscription commitment with renewal exposure; strategically it is a decision about the customer's long-term posture toward Broadcom. The planning, negotiation, and execution deserve the level of attention an organisation gives to any decision of comparable consequence.

For an independent assessment of a VCF migration plan, an evaluation of Broadcom subscription terms, or coordination of a VCF migration alongside an active audit defence, Contact us →. We work independently of Broadcom and have supported VCF migrations across the customer size spectrum.