The VCF 9 upgrade guide | Part 1 – Why companies are making the move

Part 1 of 3. Read Part 2: Aria vs CMP | Read Part 3: after the Aria upgrade

For most organizations running VMware Cloud Foundation, the VCF 9 upgrade stops being optional fairly quickly. Licensing changes, end-of-support dates, and a genuinely different management architecture combine to make this a platform transition rather than a feature release. What follows is what is driving the move, what the platform delivers once you are on it, and where teams get tripped up on the way.

Subscription-only	Oct 2025	Oct 2027
Perpetual licenses cannot upgrade directly to VCF 9	vSphere 7.x general support ended	vSphere 8.x general support ends

Why the VCF 9 upgrade is not really optional

The most immediate driver is licensing. Broadcom has moved VMware Cloud Foundation to a subscription-only model, and perpetual licenses cannot be upgraded directly to VCF 9, so organizations still holding them have to transition to a subscription first.

Support timelines compound it. General support for vSphere 7.x perpetual licenses ended in October 2025, and vSphere 8.x follows in October 2027. Once support lapses, organizations are running unsupported infrastructure, which is a hard sell to any security or compliance team.

For most companies the upgrade conversation therefore starts as a licensing and support conversation rather than a features conversation. Once that door opens, the platform changes underneath VCF 9 give teams reasons to move deliberately.

Licensing	Support clock	The risk
Subscription-only	vSphere 7.x: ended October 2025	Unsupported infrastructure
Perpetual licenses cannot upgrade directly to VCF 9	vSphere 8.x: ends October 2027	A hard sell to security and compliance teams once support lapses
Must convert to a subscription first	General support windows are closing

What VCF 9 delivers

Management plane consolidation

VCF 9 restructures how the private cloud stack is built and run. Management components, meaning SDDC Manager, Aria and VCF Operations, and related services, now deploy as containers inside a VCF Management Services appliance rather than as a sprawl of separate virtual appliances. That appliance can be replicated for fault tolerance, which simplifies both the footprint and the failure model of the management plane. For operations teams that have spent years patching and troubleshooting a dozen separate management VMs, that is a meaningful reduction in surface area.

Kubernetes headroom

The platform also leans into modern workload types. vSphere Kubernetes Service now includes a Local Consumption Interface as a native, default-enabled Supervisor service, along with a lighter container-as-a-service runtime mode. VCF 9.1 pushes this further, and Broadcom states that vSphere Kubernetes Service supports up to 500 clusters per control plane. For organizations consolidating Kubernetes sprawl onto their private cloud, that headroom is a direct operational win.

AI and GPU workloads

AI workloads get specific attention. VCF 9 supports live vMotion for GPU-heavy workloads with minimal downtime and includes tighter integration with NVIDIA hardware and software, which is relevant for any company standing up internal AI or ML infrastructure without wanting to build a separate silo for it.

What it actually costs

On cost, Broadcom has cut list pricing on VCF subscriptions and pointed to efficiency gains from the new architecture. The published figures are narrower than the headline framing suggests. Broadcom’s VCF 9.1 announcement cites up to 40% lower server costs through intelligent memory tiering, scoped to clusters running a mix of AI and non-AI workloads, and up to 39% lower storage TCO through vSAN deduplication and compression compared with external arrays. Both are real gains for the configurations they describe, and neither is an estate-wide number.

List pricing and realized renewal cost have also moved in different directions since the acquisition, and Part 2 covers what teams are actually seeing when contracts come up. Licensing administration has been simplified as well, with capacity tracking and compliance visibility now living inside VCF Operations, and subscription-based license files replacing the older scattered 25-character keys.

Taken together, the business case combines avoiding unsupported infrastructure, consolidating management overhead, and picking up capability for Kubernetes and AI workloads without a forklift replacement of the private cloud. If consolidating the management plane is the part that matters most to you, that layer doesn’t have to come from Broadcom — CloudBolt CMP is free for up to 100 resources.

How to prepare for the VCF 9 upgrade before opening the upgrade tooling

VCF upgrades are not a single component update. They involve mandatory sequencing across SDDC Manager, NSX, vCenter, ESX, and Aria or VCF Operations, with dependencies that make order matter as much as timing.

Broadcom’s own guidance starts with assessment: validating current component versions and configuration, reviewing the Planning and Preparation Workbook, checking hardware compatibility against the VMware Interoperability Matrix, and running SDDC Manager prechecks before committing to a maintenance window.

VMware has also released an Upgrade Planning Tool that takes in a current environment’s versions and produces a tailored, phase-by-phase upgrade plan, exportable to PDF for offline reference during the change window. Teams evaluating VCF 9 should use this rather than reconstructing a plan from scattered documentation.

Network readiness deserves early attention. VCF Management Services alone can require a dozen or more static IPs, each with a matching forward and reverse DNS entry, scaling toward thirty depending on planned scale-out. Getting IP allocation, DNS records, and naming conventions locked down well before the upgrade window avoids one of the most common last-minute scrambles.

Licensing needs its own workstream, covering confirmation of current license type, initiating any required perpetual-to-subscription conversion, and validating capacity and compliance visibility in VCF Operations ahead of the cutover rather than as an afterthought during the technical upgrade itself.

Finally, teams should treat fallback planning as a first-class requirement. That means defining rollback boundaries, communication plans, and go/no-go criteria before opening the upgrade tooling.

VCF upgrade readiness checklist

Each step builds on the previous one. Deviations increase risk.

Step	What it covers
1. Assessment	Validate component versions and configuration. Review the Planning and Preparation Workbook. Check hardware compatibility against the Interoperability Matrix. Run SDDC Manager prechecks before the maintenance window.
2. Plan	Input environment versions to the Upgrade Planning Tool. Produce a tailored, phase-by-phase plan. Export to PDF for offline reference during the change window.
3. Network preparation	VCF Management Services requires a dozen static IPs, up to around thirty depending on scale-out. Match forward and reverse DNS entries. Lock down naming conventions well before the window.
4. Licensing	Confirm current license type. Initiate perpetual-to-subscription conversion. Validate capacity and compliance visibility in VCF Operations. Complete ahead of cutover.
5. Fallback	Define rollback boundaries. Establish communication plans. Set clear go/no-go criteria. All of it before opening the upgrade tooling.

Where VCF 9 upgrades get tripped up

The single most common cause of failure is DNS hygiene. VCF 9.1 requires strictly lowercase FQDNs, and mismatches between DNS records and what is entered in SDDC Manager are a leading cause of certificate handshake failures during management services deployment. This sounds minor until it stalls a production upgrade at 2 a.m.

Sequencing errors are the second major trap. Because upgrade paths differ depending on the starting combination of vSphere, NSX, and Aria or VCF Operations versions, teams that assume a generic upgrade-everything-in-order approach can hit unsupported combinations, or find that upgrade binaries for one component simply do not appear where expected in another.

There have also been reports of SDDC Manager core services failing to start after a reboot mid-upgrade, resulting in prolonged downtime and an inaccessible UI, which is the kind of issue a tested rollback plan is meant to catch early rather than discover live.

Conversion scenarios add another layer of risk. Organizations converging an existing vCenter environment into VCF, where that vCenter was previously upgraded from 8.x to 9.x outside the VCF process, have run into management services deployment failures tied to FQDN resolution during bootstrap. And because only vSphere Lifecycle Manager image-based clusters are supported starting with VCF 9.0, any workload domains still running baseline-based cluster management need remediation before they are upgrade-eligible at all.

None of these pitfalls are exotic. They are the kind of environment hygiene and sequencing discipline that experienced infrastructure teams already practice. What changes with VCF 9 is that the platform’s tighter integration across components means small inconsistencies surface faster, and with less forgiveness, than they did in earlier and more loosely coupled versions.

Common failure points

Failure point	What goes wrong
DNS precision and certificates	Uppercase hostnames in DNS records. VCF 9.1 mandates lowercase FQDNs, and mismatches cause certificate handshake failures. The most common failure point overall.
Upgrade sequencing and path validation	Upgrade paths differ by starting version combination. Unsupported combinations block the upgrade, or binaries do not appear where expected.
Core services after reboot	SDDC Manager core services fail to start post-reboot, causing prolonged downtime and an inaccessible UI. A tested rollback procedure is essential.
Conversion scenarios	An existing vCenter upgraded 8.x to 9.x outside the VCF process, then converged into VCF, hits DNS resolution failures during bootstrap.
Baseline-based clusters	Only vSphere Lifecycle Manager image-based clusters are supported from VCF 9.0. Baseline-managed workload domains need remediation before they are upgrade-eligible.

The bottom line

Companies are moving to VCF 9 because staying still stops being a real option, and because the platform reduces management overhead and extends capability into Kubernetes and AI workloads. The organizations that get through the upgrade cleanly are the ones that treat it as a planning exercise first, with sequencing, DNS, IP allocation, licensing conversion, and fallback criteria settled well before anyone opens the upgrade tooling.

No credit card. No sales call.

Before you commit to the Aria path, try the alternative

The full CloudBolt CMP is free for up to 100 resources — self-service provisioning, governance, RBAC, and full lifecycle management, running in your environment today.

Start building for free

Download PDF