VMware Cloud Foundation 9.x -- Overview and Path-Choice Decision Map¶

Scope¶

This document is the conversation-level anchor file for VMware Cloud Foundation 9.x. It is the file a solution architect or account team should open first when a client conversation turns to VCF 9, before reaching for the deeper layers. It covers the one-paragraph "what is VCF 9" orientation, the 9.0 -> 9.1 evolution, the path-choice decision map that determines whether a VCF 9 adoption requires a hardware refresh, the when-VCF-9-vs-alternatives framing, and the irreversibly-different elements an architect must call out before any commitment is made. It is deliberately not a deep technical reference -- for SDDC Manager and bring-up, see providers/vmware/vcf-sddc-manager.md; for the 5.x -> 9.0 upgrade sequence, see providers/vmware/vcf-upgrade-5-to-9.md; for vSphere/VCF version notes and Aria-rename context, see providers/vmware/platform-services.md; for licensing mechanics and TCO posture, see providers/vmware/licensing.md; for vSphere 9 compute-side removals (VUM, Host Profiles, Auto Deploy), see providers/vmware/compute.md.

What VCF 9 is¶

VMware Cloud Foundation 9.x is Broadcom's unified full-stack private-cloud platform: vSphere 9, vSAN 9, NSX 9, and the renamed VCF management suite (VCF Operations, VCF Automation, VCF Operations for Logs, VCF Operations for Networks, VCF Automation Config), lifecycle-managed by SDDC Manager and -- increasingly in 9.x -- by VCF Operations Fleet Management. The version-number jump from 5.x straight to 9.0 (there is no VCF 6.x, 7.x, or 8.x) was a deliberate Broadcom alignment so that every bundled component shares the same major version. Two other Broadcom-era changes define what VCF 9 is as much as the technology does: subscription-only licensing on a per-core basis (perpetual licenses cannot be carried into 9.x), and the consolidation of the Aria suite into VCF-prefixed names. Under Broadcom, vSphere 9 is not sold standalone -- the only path to vSphere 9 is through VCF -- so "should we move to vSphere 9" and "should we move to VCF 9" are the same question.

Checklist¶

Orientation¶

[Critical] Is the conversation correctly framed as "VCF 9.x" and not "vSphere 9"? (Under Broadcom there is no standalone vSphere 9 SKU; adopting vSphere 9 means adopting VCF 9, which means accepting per-core subscription licensing and the bundled VCF management suite; conversations that frame the move as "just a vSphere upgrade" miss the commercial and operational scope and produce wildly low cost estimates)
[Critical] Is the current VCF 9 minor release lineage tracked, and is the customer's adoption target a specific minor release rather than "VCF 9"? (VCF 9.0 GA'd in mid-2025 and 9.1 followed at the end of 2025; the 9.x line is a moving target with quarterly-ish minor releases, and the version-specific gotchas -- e.g., 9.0.0 vs 9.0.1 link-local-IP behaviour for vCenter RDU -- mean that a recommendation should always cite a specific minor)
[Critical] Is the customer's current starting point known precisely? (VCF 5.1/5.2 can upgrade directly to 9.0; VCF 5.0 must stage through 5.2 first; VCF 4.x must stage through 5.2 first and may also require NSX-V to NSX-T transition; vSphere-only deployments outside VCF have a fundamentally different motion that is not covered by the 5.x-to-9.0 upgrade guide)

9.0 -> 9.1 evolution¶

[Critical] Is the difference between "VCF 9 as a platform" (long-lived, multi-year) and "the current minor release" (quarterly cadence, sometimes carrying significant behavioural changes) understood? (Treat the 9.x line as analogous to the vSphere 7.x or 8.x lines -- the platform is durable but specific minor releases bring meaningful changes that must be re-verified at design time; recommendations frozen against 9.0.0 will drift)
[Recommended] Has the current GA minor release been confirmed with Broadcom or an authorized partner rather than inferred from older documentation? (Broadcom's release cadence under the post-acquisition model has shifted, and the publicly-indexed release-notes pages move; the customer's Broadcom Support Portal entitlement view is the authoritative source for "what is the currently-supported VCF 9 minor")
[Recommended] For customers on 9.0.0 specifically, is the upgrade-to-current-minor planned as a maintenance activity rather than a new project? (Within-9.x minor upgrades are documented as roughly 4-8 hour per-domain maintenance operations with snapshot-based rollback supported -- materially simpler than the 5.x-to-9.0 motion -- but they still require the SDDC Manager / VCF Operations Fleet Management lifecycle workflow and a tested backup)

Path-choice decision map¶

[Critical] Has the four-quadrant path-choice decision been made explicitly, rather than collapsing into a single "we will upgrade to VCF 9" statement? (The matrix below distinguishes existing-hardware vs hardware-refresh on one axis and low-disruption-deployment vs full-private-cloud-transformation on the other; each quadrant has a different motion, a different commercial shape, and a different delivery model)

Condition	Existing-hardware path	Refresh-cycle path	Likely motion
Existing hardware / low disruption (pre-EOS deploy)	Deploy minimal VCF 9.x on existing hosts to land on a supported version before vSphere 7.x / 8.x EOS pressure forces the issue; carry forward as much of the existing operating model as possible	Upgrade to minimal VCF 9.x on new hosts purchased ahead of refresh cycle; old hosts retired or repurposed as the new fleet stands up	Managed-services starting point -- minimal-scope landing, often delivered as a controlled lift to a supported version with operational continuity as the goal
EOL server refresh / transformation (full re-architecture)	Deploy full private cloud with VCF 9.x on existing hosts, layering in VCF Operations, VCF Automation, NSX microsegmentation, vSAN ESA where the hardware allows; treat as a transformation programme rather than an upgrade	Deploy full private cloud with VCF 9.x on new hosts as part of an EOL-driven refresh -- the cleanest greenfield-shaped motion within an existing site	Consult-led architecture and delivery -- full design engagement (NBIE, Solution Design, ADRs across every layer), multi-phase delivery, formal cutover plan

[Critical] Is "existing hardware" path-choice validated against the VCF 9.0 hardware Bill of Materials before being committed? (VCF 9.0 raised the ESXi boot-bank minimum to 1 GB -- up from 500 MB -- and the system-disk minimum to 32 GB; older servers that meet vSphere 8.x today may not meet 9.x; vSAN HCL must also be re-verified; "existing hardware" is sometimes not actually compatible, which collapses the matrix to a refresh-only conversation)
[Critical] Is the path-choice paired with the licensing-conversion prerequisite? (Regardless of which quadrant is chosen, perpetual licenses must be converted to Broadcom subscription before the technical upgrade can begin; customers who defer this conversation until upgrade day will be blocked, which makes path-choice partly a commercial-readiness question, not just a technical one)
[Recommended] For the existing-hardware-minimal-deployment quadrant, has the timing relative to vSphere EOS been put on the deal sheet? (vSphere 7.x reached end of general support October 2025; vSphere 8.x is scheduled for October 2027; the further out the customer's renewal/EOS pressure, the more optionality they retain to evaluate alternatives instead of committing to VCF 9)
[Recommended] For the new-hardware quadrant, has the per-core licensing cost been modelled against likely CPU SKUs? (Modern high-core-count CPUs -- AMD EPYC Turin / Granite Rapids -- inflate per-core licensing cost significantly versus older 16-32 core parts; new-hardware decisions made on hardware-cost grounds alone produce surprising VCF subscription costs at renewal)
[Recommended] For the full-private-cloud quadrants, are the mandatory VCF 9 management-suite components (VCF Operations, VCF Operations Fleet Management, VCF Automation) included in the operating model from day one rather than treated as future-phase deferrals? (VCF 9.0 makes these mandatory; they deploy automatically during upgrade whether previously installed or not; planning the operating model without them produces operational gaps post-cutover)

When VCF 9 vs alternatives¶

[Critical] Has the alternative-platform conversation been had explicitly with the customer, or has VCF 9 been adopted by default because it is the incumbent? (Broadcom-renewal pressure has made "stay on VMware" a non-default for many customers; an architect who designs a VCF 9 landing without surfacing the alternatives is doing the customer a disservice, even if the answer is ultimately to stay)
[Critical] When evaluating hosted private cloud as an alternative, has the operating-model shift been understood? (Hosted private cloud -- delivered by Kyndryl, IBM Cloud, partner MSPs -- moves the VCF / SDDC Manager operational burden to the provider but retains VMware-native compatibility, so applications need no re-platforming; the trade is operational ownership for monthly OpEx with little reduction in the underlying VMware licensing cost)
[Critical] When evaluating hyperscaler-hosted VMware (AVS, VMC on AWS, GCVE), has the BYOL-vs-host-included licensing question been resolved? (BYOL on hyperscaler-hosted VMware became effective November 2025 and changes the TCO calculation versus host-included; see providers/vmware/licensing.md and the specific hyperscaler files for depth -- but at the conversation level, the architect must know whether the customer is bringing licenses or paying for them through the hyperscaler)
[Critical] When evaluating replatform to non-VMware (Nutanix, OpenShift Virtualization, OpenStack, Proxmox, Azure Stack HCI), has the migration cost and timeline been honestly estimated against the VCF 9 subscription cost over the same 3-5 year window? (Migration costs and operational retraining frequently exceed 2-3 years of VCF licensing savings; the calculation is rarely as favourable as the headline subscription-cost-delta suggests, but it is sometimes correct -- the discipline is to run the actual numbers rather than to assume either direction)
[Recommended] Has the VCF Edition (full) vs VVF Edition (vSphere-only foundation) been considered for customers who do not actually need vSAN / NSX / the management suite? (VVF is materially cheaper than VCF but excludes the lifecycle-managed full stack; under Broadcom, VVF availability has been geographically inconsistent -- discontinued in parts of EMEA in December 2025 -- and vSphere 9 itself is gated to VCF only, so the VVF path may not actually deliver vSphere 9 even where it remains available)
[Recommended] For customers whose primary driver is escape from Broadcom commercial terms, has the destination been chosen on its own merits rather than as a pure exit motion? (Nutanix, OpenShift Virtualization, and Azure Stack HCI each have very different operating models, ecosystem support, and skills profiles; choosing the destination because it is "not VMware" produces poorly-designed landings that frequently boomerang back to VMware within 18-24 months)

Irreversibly different in 9.x¶

[Critical] Are the one-way-door transitions associated with VCF 9.x identified and stakeholder-approved before commitment? (The cross-link is providers/vmware/vcf-upgrade-5-to-9.md, which is the authoritative catalogue; the four most-load-bearing one-way doors are: vLCM baseline-to-image transition, vSAN on-disk format upgrade, Enhanced Linked Mode removal, and NSX Manager-to-Policy promotion -- each is a documented go/no-go decision)
[Critical] Has the perpetual-to-subscription licensing conversion been acknowledged as a commercial one-way door alongside the technical ones? (Once converted, returning to perpetual is not on the table; this is sometimes underweighted in architect-led conversations because it is a procurement decision, but it materially changes the customer's cost shape for the life of the platform)
[Critical] Are the vSphere 9 compute-side removals -- VUM removed, Host Profiles deprecated, Auto Deploy deprecated -- accounted for in the operating model? (See providers/vmware/compute.md for depth; VUM-based patching workflows must be redesigned around vLCM images; Host Profiles consumers must move to image-based standardization; Auto Deploy stateless ESXi must be re-architected before adopting 9.x -- these are not items to discover at cutover)
[Recommended] Is the Aria -> VCF rename treated as a documentation-and-tooling impact rather than a marketing artifact? (Runbooks, dashboards, alert names, KB references, monitoring integrations, and trained-operator muscle memory all key on the old names; a VCF 9 cutover without a documentation-pass cleanup produces months of operational friction; the rename is also load-bearing for Broadcom Support Portal KB searches which fail against legacy names)
[Recommended] Is the SDDC Manager UI deprecation trajectory factored into operational runbook design? (Lifecycle management is moving to the VCF Operations console under Fleet Management; runbooks built against the SDDC Manager UI in 9.0 will need to be re-pointed; investing heavily in SDDC-Manager-UI-based runbooks during the 9.x lifecycle is a sunk-cost trajectory)
[Recommended] Is the vIDM -> VCF Identity Broker (VIDB) transition planned as greenfield rather than as migration? (There is no migration path from vIDM to VIDB; vIDM continues to be supported by Aria Suite Lifecycle 8.x during the transition; SAML / OIDC federation must be re-implemented in VIDB rather than imported)

ADR triggers (VCF 9-specific)¶

[Critical] Is there an ADR for platform-vs-alternatives -- VCF 9 vs hosted private cloud vs hyperscaler-hosted VMware vs replatform -- with the decision rationale, the alternatives evaluated, and the cost / timeline / risk basis recorded?
[Critical] Is there an ADR for hardware-vs-existing-hardware -- whether VCF 9 lands on the existing fleet, on a hardware refresh, or on a mixed transition?
[Critical] Is there an ADR for deployment scope -- the path-1 (minimal landing) vs path-2 (full private cloud) decision within the path-choice matrix?
[Recommended] Is there an ADR for VCF vs VVF if VVF is available in the customer's geography and the customer does not need the full stack?
[Recommended] Is there an ADR for vSAN architecture -- OSA vs ESA vs non-vSAN principal storage (new in VCF 9.0)?
[Recommended] Is there an ADR for NSX Manager-to-Policy promotion strategy for customers with significant Manager-API legacy?
[Recommended] Is there an ADR for identity -- VCF Identity Broker greenfield deployment vs continued vIDM under Aria Suite Lifecycle 8.x during transition?
[Recommended] Is there an ADR for licensing conversion timing -- when the perpetual-to-subscription conversion happens relative to the technical upgrade, including renewal-date penalty exposure?

Why This Matters¶

VCF 9 is the largest VMware platform change in the past decade -- larger, in commercial-and-operating-model terms, than the vSphere 5-to-6 or 6-to-7 transitions, because the underlying licensing, packaging, and product-naming all changed at the same time as the technical stack. The version-number jump from 5.x to 9.0 was a marketing choice that conceals how much of the change is non-technical: subscription-only licensing, the elimination of standalone vSphere 9, the Aria-to-VCF rebrand, the consolidation of HCX and Tanzu into VCF, the deprecation of the SDDC Manager UI in favour of VCF Operations Fleet Management, and the deprecation of VUM, Host Profiles, and Auto Deploy on the vSphere side. An architect or account team walking into a VCF 9 conversation needs to hold all of this simultaneously, against a customer who may have framed the conversation as "we are looking at a vSphere upgrade." The path-choice decision map exists because the single most common opening question -- "does every VCF 9 path require a hardware refresh" -- has a "no, but" answer that takes ten minutes to articulate from first principles each time without an anchor. The matrix makes the answer immediate: there are two existing-hardware quadrants and two refresh-cycle quadrants, the existing-hardware quadrants are viable but constrained by the VCF 9 hardware Bill of Materials, and the choice between minimal landing and full private cloud is a separate axis from the hardware question. Once that map is on the table, the rest of the conversation -- alternatives, licensing, irreversible transitions, operating model -- can proceed against a shared frame rather than relitigating the hardware question repeatedly. The alternatives conversation is similarly load-bearing. Under Broadcom-renewal pressure, customers who would once have adopted the next VMware version by default are now actively evaluating hosted private cloud, hyperscaler-hosted VMware, and full replatform to Nutanix / OpenShift / OpenStack / Azure Stack HCI. An architect who lands a VCF 9 design without surfacing those alternatives is not doing thorough work, even if the customer's final answer is to stay. Conversely, an architect who pushes replatform without honestly modelling migration cost against VCF subscription cost over a 3-5 year window will frequently produce a design that boomerangs back to VMware within two years, having spent the customer's migration budget in the wrong direction.

Common Decisions (ADR Triggers)¶

Platform vs alternatives -- VCF 9 on-premises (incumbent, lowest re-architecture cost, highest commercial exposure to Broadcom renewal) vs hosted private cloud via Kyndryl / IBM Cloud / partner MSP (VMware-compatible with operating burden shifted to provider, similar underlying VMware licensing cost) vs hyperscaler-hosted VMware (AVS, VMC on AWS, GCVE) under BYOL or host-included licensing (elastic capacity, cloud-adjacent services, longest-term commercial uncertainty as hyperscalers themselves negotiate with Broadcom) vs full replatform (Nutanix, OpenShift Virtualization, OpenStack, Proxmox, Azure Stack HCI) (largest re-architecture, largest skills shift, lowest long-term VMware exposure)
Hardware: existing vs refresh -- existing hardware (lower capital spend, but constrained by VCF 9.0 BOM minima -- 1 GB boot-bank, 32 GB system disk, updated vSAN HCL -- and by per-core licensing inflation on older high-core CPUs) vs refresh-cycle new hardware (greenfield-shaped landing, EOL-driven capex justification, but per-core licensing inflation on new high-core CPUs needs explicit modelling)
Path-1 minimal-landing vs path-2 full-private-cloud -- minimal landing to escape pre-EOS pressure on the incumbent (faster, smaller scope, often managed-services-led) vs full private cloud with VCF Operations, VCF Automation, NSX microsegmentation, vSAN ESA (multi-phase, consult-led, materially higher value if executed well)
VCF vs VVF -- VCF for the full stack with mandatory management suite (only path to vSphere 9, includes vSAN / NSX / VCF Operations / VCF Automation in the per-core cost) vs VVF for vSphere-only deployments where vSAN and NSX are not needed (lower per-core cost, but excludes the full management suite, has inconsistent geographic availability, and does not deliver vSphere 9)
vSAN architecture: OSA vs ESA vs non-vSAN principal storage -- vSAN OSA (mature, broader hardware compatibility) vs vSAN ESA (NVMe-optimized, requires updated HCL, better for new hardware) vs non-vSAN principal storage (new in VCF 9.0, external SAN/NAS as workload-domain primary storage, allows independent compute/storage scaling and re-use of existing array investments)
Licensing conversion timing -- convert perpetual to Broadcom subscription before the technical upgrade (forced by VCF 9 requirement, but exposed to the 20% late-renewal penalty if renewal date is missed) vs negotiate timing with renewal cycle to avoid penalty (may require staying on VCF 5.2 longer than technical readiness would suggest)
NSX Manager-to-Policy promotion strategy -- promote all Manager-API objects before upgrade (required, but the larger the legacy estate the longer the promotion campaign) vs clean up unused Manager objects first to reduce promotion scope vs use the NSX 4.2.1+ intermediate-step path for mixed-mode environments
Identity broker: VIDB greenfield vs continued vIDM -- deploy VCF Identity Broker as greenfield (required for VCF 9 native federation, but no migration tooling from vIDM) vs continue vIDM under Aria Suite Lifecycle 8.x during transition (operationally simpler in the short term, but accumulates technical debt as the rest of the platform moves to VIDB)

Reference Links¶

VMware Cloud Foundation 9.0 release notes -- VCF 9.0 release notes, BOM, and known issues
VMware Cloud Foundation 9.0 Bill of Materials -- exact component versions and build numbers for VCF 9.0
VCF 9.0 licensing -- subscription model, per-core pricing, unified license file
Broadcom Interoperability Matrix -- supported upgrade paths and compatibility (use this rather than older interoperability tools that have been retired post-acquisition)
VCF 9.0 Update Sequence (KB 390634) -- Broadcom KB with exact component ordering for the 5.x-to-9.0 motion
Broadcom Support Portal -- authoritative source for currently-supported VCF 9 minor releases, customer-specific entitlements, and KB content under post-acquisition naming