vSphere 8 to VCF 9 upgrade: converge, import or a new deployment, and the steps in order

vSphere 8 to VCF 9 upgrade: the routes Broadcom documents

An existing vSphere 8 estate reaches VMware Cloud Foundation (VCF) 9.1 by one of three routes in Broadcom’s 9.1 documentation: converge the existing vCenter and its ESX hosts with the VCF Installer into the management domain of a new VCF instance, import a vCenter into an existing VCF instance as a workload domain, or deploy a new VCF 9.1 environment and migrate the workloads. For estates with only vSphere, vSAN and Aria Operations, Broadcom also documents a component upgrade that brings vCenter and ESX 8 Update 3 to 9.1 and can be extended to vSphere Foundation (VVF) or VCF later. The choice depends on NSX, SDDC Manager and Aria, on the exact builds and on the licences.

Broadcom’s overview “Paths to Building 9.1.x Environments” (8 October 2026) sorts them into deploying new, converging and upgrading, with import for workload domains; estates on VCF 5.2.x with SDDC Manager upgrade their VCF instance instead. Broadcom gives October 2027 for the end of vSphere 8 support, as our vSphere 8 end of general support guide sets out.

Converge, import or a new deployment: which route fits

Broadcom TechDocs VCF 9.1: Paths to Building 9.1.x Environments, Upgrading vSphere 8 to 9.1.x and Supported Components and Scenarios to Converge to VCF (all 8 October 2026); VCF 9.1 FAQ, Q59 to Q68 (3 September 2026); KB 450972.

Converge and import work on whole vCenter instances: the VCF 9.1 FAQ says “Infrastructure is added at the vCenter level”, and that both operations “do not require downtime or a migration of applications or data”. For clusters without NSX, “NSX will automatically be deployed as part of the convert/import operation.” The FAQ gives 8.0 Update 1 as the import minimum in Q59 but 8.0 Update 3 in Q63, as KB 450972 does; plan on Update 3.

With several vCenter instances, the VCF Installer converges one into a management domain and VCF Operations imports the others as workload domains. Where NSX already runs, Broadcom’s KB 440630 leaves no component by component option and sends the estate through the VCF Installer workflows. Broadcom also documents a converge to vSphere Foundation 9.1; what that means for a later move to VCF is in our VVF vs VCF comparison.

A new deployment on new servers suits estates whose hosts cannot run ESX 9, or a vCenter configuration that converge does not support. Workloads move across by cross vCenter vMotion or, within VCF, HCX.

vCenter and ESX builds: the back-in-time rule

Broadcom does not support an upgrade from a source that “contains code fixes, security patches, or driver updates that are not yet present in the target release” (KB 450972). For VCF 9.1.0, the KB supports upgrade, converge and import from vSphere 8.0 U3 to 8.0 U3i, and only import from 8.0 U3j and U3k.

KB 448135 adds that VCF 9.1.1.0 “has been released with an updated Bill of Materials (BOM)”, which resolves the block for vSphere 8.0 U3j and later and for NSX 4.2.4 and later. The VCF 9.1.1 release notes (GA 3 September 2026) allow converging existing infrastructure, or deploying new, directly at 9.1.1. For an estate patched to U3j or U3k, the target is therefore 9.1.1, not 9.1.0. KB 448135 also asks you to confirm each path in the VMware Interoperability Matrix with “Hide Patch Releases” unchecked.

Import is outside the rule because KB 450972 calls it “an onboarding operation rather than an upgrade operation”. It brings the vCenter under “an existing VCF 9.1 Fleet” while its hosts stay on their 8.0 Update 3 patches, so a U3j or U3k estate without a VCF instance needs a management domain on other hosts first, or the 9.1.1 route.

Licences before the first maintenance window

The VCF 9.1 FAQ of 3 September 2026 says that customers with perpetual licences “will need to switch to subscription licenses prior to upgrading”. Broadcom’s KB 437250 adds that “The license key cannot be upgraded from version 8.x to 9.x”: the Broadcom Site ID needs a subscription entitled to VCF 9 or VVF 9. In 9.1, “VCF Operations and the license server components are required to license all 9.1.x environments”, so both come before vCenter.

The licence server is deployed from an OVA, with a registration key from VCF Operations, into a vCenter instance connected to it, not on a standalone ESX host. It needs an FQDN with A and PTR records that every vCenter using it can resolve, and it does not support IPv6.

An upgraded vCenter 9.1 runs in evaluation mode for up to 90 days until it receives a primary licence. Broadcom’s 9.1 licensing guide accepts ESXi 8.x hosts with 8.x keys under a 9.1 vCenter, drawing capacity from the 9.x subscription as well.

Prerequisites for a 10 to 60 host estate

Start with an inventory per vCenter instance: hosts with ESX builds and CPU models, the lifecycle method of each cluster, the switch type, NSX and Aria components, Enhanced Linked Mode and vCenter High Availability. Three results of it decide the route. Clusters still on baselines move to vLCM images first, as in our guide to converting vLCM baselines to images. Hosts with discontinued CPUs or end of life devices cannot run ESX 9; the checks are in our ESX 9 hardware requirements guide.

The third is Broadcom’s list of configurations not supported for converging to VCF 9.1: vCenter instances with Enhanced Linked Mode or without a distributed switch, a vCenter VM hosted on a cluster that another vCenter manages, Cisco virtual switches, dynamically allocated VMkernel IP addresses, clusters on baselines, clusters with manual or partially automated DRS, clusters using vCenter High Availability, and partial imports of clusters. A converged management domain needs at least 3 ESX hosts with vSAN or 2 with external storage in the simple model, and 4 hosts in the high availability model.

For the vCenter upgrade, Broadcom’s 9.1 prerequisites (5 October 2026) ask for synchronised clocks, DRS set to manual or partially automated (converge later needs fully automated DRS), ports 22 and 443 open, and forward and reverse DNS records for a static temporary address. They ask for an image-based backup (snapshot) of the appliance “as a precaution”. Take a file-based backup just before the window as well, as in our guide to vCenter file-based backup and restore.

The same 9.1 guide sets where the new appliance runs: “You can deploy the new appliance on an ESX host 9.0 or later, or on the inventory of a vCenter instance 9.0 or later.” Its system requirements page names ESX 9.1 in one place. Where every host still runs ESXi 8, plan one ESX 9.1 host for the appliance before the vCenter window, such as a spare or new server, and confirm the placement with Broadcom support.

vSphere 8 to 9.1 upgrade steps in order

Broadcom’s 9.1 scenario for vSphere 8 estates sets six steps. KB 440630 says “A mandatory component upgrade sequence must be followed” without listing every product, so the backup product, replication and the vSAN witness take their places from Broadcom’s VCF 9.0 sequence, KB 390634.

1. Upgrade Aria Operations 8.18 or later to VCF Operations 9.1 after a snapshot of each node, or deploy VCF Operations 9.1 from its OVA on the vCenter that hosts the core components.
2. Deploy the licence server, confirm that VCF Operations shows it as Connected, and check that the 9.x subscription appears.
3. Upgrade the VADP-based backup product, vSphere Replication and Site Recovery Manager to releases supported with the target vCenter.
4. Upgrade vCenter to 9.1 with the installer’s two-stage GUI or its CLI, the new appliance on an ESX 9.x host, then assign the primary licence in VCF Operations.
5. Upgrade the vSAN witness hosts of stretched or two-node clusters.
6. Upgrade the ESX hosts cluster by cluster: a 9.1 base image with the server maker’s add-on, a compliance check, the remediation pre-check, one host, then the rest.
7. Upgrade VMware Tools and, where a workload needs it, the virtual hardware.
8. Upgrade the vSAN on-disk format of each vSAN cluster, then vSAN File Service where it runs.

KB 390634 adds: “Patches can be applied in any order. The upgrade order only matters for major/minor releases.” The vSAN on-disk format upgrade expects completed ESX and vCenter upgrades, healthy disks, no host in maintenance mode and no rebuild in progress, and it “might cause temporary resynchronization traffic and use additional space”.

Our VMware optimisation service runs these steps in agreed maintenance windows with a rollback plan. Send us your vCenter and ESX builds through the form below, with the clusters each vCenter manages.

Worked example: 40 hosts in four clusters

Take one vCenter 8.0 U3 that manages 40 hosts: a 4-host management cluster and a 16-host production cluster on vSAN, a 12-host production cluster and an 8-host database cluster on Fibre Channel VMFS, with Aria Operations 8.18 and no NSX. The component upgrade scenario applies. Broadcom’s vSphere 9.0 lifecycle guide notes that “you cannot downgrade ESX”, so each window ends at a point that is either restorable or checked before the next starts.

Our example and planning order; steps from Broadcom TechDocs VCF 9.1 (upgrade scenario, VCF Operations upgrade and vSAN on-disk format, 8 October 2026), the vCenter 9.1 upgrade prerequisites (5 October 2026), the vSphere 9.0 lifecycle guide and KB 390634.

A window may cover part of a cluster: Broadcom’s KB 424129 states that vCenter 9.0 can manage ESX 8.0 hosts in the same cluster as ESX 9.0 hosts. A cluster sized for one host failure loses that reserve while a host is in maintenance mode, so schedule the database cluster when its load is lowest.

Converging to VCF after the upgrade or straight from 8.0 U3

To run VCF, the estate in the example can converge from 8.0 U3 with the VCF Installer, or finish the component upgrade first, which Broadcom describes as a stable environment that can later be extended to VVF or VCF 9.1.x. With one vCenter, converge puts all four clusters into the management domain, since “All clusters managed by the instance are imported together into the management domain”.

Broadcom’s converge overview (8 October 2026) describes prerequisites, manual upgrades of existing components, then deployments by the VCF Installer, which “uses your vCenter instance and ESX hosts to create the management domain for the new instance” and “deploys all required components that you do not have in your existing environment”. The scenario page that matches what runs today sets which components you upgrade by hand first.

NSX 4.2.1 or later, registered with a vCenter without Enhanced Linked Mode, is converged at its current version and upgraded to 9.1 afterwards. VMware Aria Suite Lifecycle “is not part of VCF 9.1.x”.

Our estate and licence audit takes a full inventory of your VMware estate. Describe your vCenter instances, NSX and Aria components in the form below, with the builds each one runs.

What we do

Eurokommerz holds the contract; engineering is by our partner Vixen.UNO. Under VMware optimisation, the audit of your estate and licences ends in an action plan ahead of renewal and end of support, with dates. The upgrade to 9.x, part of the modernisation of vSphere, vSAN, NSX and VCF, runs in agreed maintenance windows, step by step, with a rollback plan at every stage. The first call is free of charge, the price of the technical assessment is fixed before work begins, and support continues under an agreed SLA.

FAQ