Standalone VVF upgrade

A companion to the Overview, expanding the standalone VVF track: VMware vSphere Foundation with no VCF Management Services layer – compute, storage, networking and admin run through native vSphere management interfaces, patched with standard vSphere lifecycle mechanisms instead of SDDC-Manager-driven phases. If SDDC Manager / Fleet Management is driving the upgrade, see the Full VCF upgrade sequence instead.

Fleet-managed VVF vs. standalone VVF

This whole doc assumes no VCF Management Services / Fleet Management layer – SDDC Manager, VCF Operations Fleet Management, and the License Server all sit on that layer, and it is mandatory for full VCF but optional for VMware vSphere Foundation (VVF) (verified against Broadcom TechDocs, “Deploying VMware vSphere Foundation 9.1 Without VCF Management Services”, 2026-09-08):

Fleet-managed VVF (deployed/upgraded through the VCF Installer, VCF Management Services present) – use the Full VCF upgrade sequence instead; it applies unmodified.
Standalone VVF (no VCF Management Services layer) – “deploying and running vSphere Foundation 9.1 without VCF management services is a supported deployment model.” Giving up VCF Management Services also gives up log management, binary management (the software depot component), and integrated lifecycle management of VCF Operations – if any of those are required, VCF Management Services has to be deployed after all (see Full VCF upgrade sequence).

Confirm which model an engagement is actually on before running the planner or committing to a phase count – it changes whether Phases 2 and 3 of the full-VCF sequence (SDDC Manager, VCF Management Services + License Server) exist at all for that engagement.

Confirm a supported path and pin a target build

Same general approach as the Overview: check the Broadcom Product Interoperability Matrix and resolve a target build to a concrete number, not a loose “9.1.1”. One VVF-specific wrinkle – vCenter’s own back-in-time restriction applies identically here: see vCenter manual GUI upgrade for the exact build-level detail and the standalone-path procedure.

Prerequisites for this scenario: vCenter 8 U3+, ESX 8 U3+, optionally vSAN 8 U3+ and Aria Operations 8.18.x.

Standalone VVF manual upgrade – exact steps

Broadcom’s dedicated scenario for this path – “Upgrading vSphere 8 and Optionally vSAN and Aria Operations 8 to 9.1” (applies only when there is no SDDC Manager, NSX, or other Aria components – plain vSphere, optionally vSAN and Aria Operations) – runs 6 phases, no SDDC Manager involved at any point:

Aria Operations / VCF Operations. Upgrade Aria Operations 8.18.x in place, or deploy VCF Operations 9.1 fresh if there is no existing Aria Operations to upgrade from.
License Server. Add a License Server manually to VCF Operations – required even in this manual scenario: “VCF Operations and the license server components are required to license all 9.1.x environments.” This is the one piece of the VCF Management Services layer you cannot skip, even on the fully standalone path.
vCenter. Upgrade the vCenter instance – choose in-place (the two-stage GUI/CLI installer) or reduced-downtime upgrade (RDU) (the vSphere Client’s Update Planner) the same as on the fleet-managed path (see RDU detail); driven from vCenter’s own installer or Update Planner, not Fleet Management, and not VAMI – see Not VAMI for why. Full manual GUI walkthrough, including the vCenter-specific back-in-time compatibility check: vCenter manual GUI upgrade.
ESX hosts. Upgrade the ESX hosts (vLCM images) – same host-by-host rolling approach as the full-VCF sequence’s Phase 7, just triggered from vCenter directly. Any cluster still on vLCM baselines needs converting first – there’s no SDDC Manager here, so use the vSphere Client path in VUM to vLCM images migration.
vSAN on-disk format. Upgrade the vSAN on-disk format version, if vSAN is in use.
vSAN File Service. Upgrade File Service agents, if enabled – same procedure as vSAN File Service in detail.

Landing here is explicitly a stable intermediate state – you can extend to full VVF or VCF later (deploying VCF Management Services as a Day-N operation) rather than needing to decide everything up front.

Extending to full VCF needs a VDS migration first

Extending standalone/VSS-based VVF to full VCF needs a VDS migration first – it is not handled by any VCF workflow. VVF itself has no distributed-switch requirement (a VVF cluster can run on the Virtual Standard Switch indefinitely, same as plain vSphere always could). Full VCF does, for two independent reasons that both land on the same prerequisite:

NSX only integrates with vSphere Distributed Switch (VDS) on ESXi. Per Broadcom TechDocs, “Managing NSX on a vSphere Distributed Switch”: “In NSX 4.0, you can only use a VDS switch to prepare ESXi host nodes as transport nodes” – N-VDS “is not supported” for that purpose (N-VDS remains valid only for NSX Edge VMs, not ESXi hosts). NSX 4.0+ ships in VCF 9, and NSX is mandatory in full VCF, at minimum for the management domain.
SDDC Manager / VCF Operations Fleet Management’s own workload-domain automation only creates and manages clusters on VDS – there is no VSS option anywhere in that create/add-cluster flow, independent of the NSX requirement above.

If an engagement is on standalone VVF with VSS today and the fleet is heading toward full VCF (not just adding VCF Management Services), confirm the VSS→VDS migration is scoped as its own prerequisite step before committing to a phase count – it is a manual, per-cluster migration on the vSphere side, not something the VCF Installer or NSX deployment does for you. Full walkthrough: VSS to VDS migration.

Pre-upgrade precheck

With no SDDC Manager on this path, there’s no fleet precheck to run. VDT is the self-service equivalent – run it against every vCenter before the window opens: VDT and lsdoctor: self-service diagnostic tools.

Post-upgrade validation

A trimmed version of the full-VCF checklist – most of that list assumes components (SDDC Manager, NSX, Identity Broker, VCF Automation) that don’t exist on this path:

Component builds – vCenter, ESX, and Aria/VCF Operations on their expected builds.
VMware Tools – upgrade guests to 13.1. Also re-verify the ProductLocker shared-repository location on every host, see VMware Tools ProductLocker.
vSAN on-disk format – upgrade the on-disk format version, if vSAN is in use.
vSAN File Service – upgrade if in use, after the on-disk format upgrade.
Licensing – vCenter and ESX licenses assigned from the License Server; no connectivity errors between vCenter and the License Server.
Aria/VCF Operations – reachable and healthy, metrics still flowing.

Same PowerCLI spot-check as the full-VCF checklist covers builds, VMware Tools, and vSAN on-disk format in one pass – see Full VCF upgrade sequence → Post-upgrade validation.

Cleanup

Pre-upgrade snapshots – delete once the upgrade is confirmed successful; leaving them attached causes performance degradation.
Legacy Aria Operations appliances – retire once the transition to VCF Operations 9.1 is confirmed, if applicable.