vCenter manual GUI upgrade (no Fleet Management)

The vCenter upgrade step in the core sequence (Phase 6) assumes the fleet-managed path: vCenter is upgraded from VCF Operations → Fleet Management, and the installer-UI path is deprecated for that case.

This doc covers the other case: a standalone / not-fleet-managed vCenter (see Fleet-managed VVF vs. standalone VVF) where there is no SDDC Manager or Fleet Management layer driving the upgrade. There, vCenter is upgraded the traditional way, from its own two-stage GUI installer or the CLI installer – see Not VAMI below for why the appliance’s own VAMI isn’t a third option here, despite looking like it should be. Same underlying two-stage migration mechanism as the fleet-driven path, just triggered manually.

Not VAMI – a common mix-up

VAMI (https://<vcenter>:5480, root login) does not drive a version upgrade of any kind – major or RDU. It’s easy to assume otherwise, since VAMI is also where routine patching happens and vSphere 9.1 added “vCenter quick patch” there too, but neither of those is a version upgrade:

A major upgrade (crossing a major version boundary, e.g. 8.x → 9.x) only has two supported paths per Broadcom TechDocs’ Upgrading the vCenter Appliance landing page: “The vCenter installer contains executable files for both GUI and CLI upgrades which you can use alternatively.” VAMI isn’t listed as a third option anywhere on that page or its sub-pages.
RDU (see Stage 1/2 below) is driven from the vSphere Client’s Update Planner – vCenter → Updates → vCenter Server → Update Planner – logged in with SSO credentials, not VAMI’s root login. Broadcom KB 313288 treats RDU and VAMI as two genuinely separate lifecycle mechanisms, warning explicitly against touching both at once: “Users should not use Reduced downtime upgrade and VAMI at the same time… This may interfere with already running lifecycle events and may lead to a corrupt vCenter Server” and “If the ISO is mounted from the Reduced downtime upgrade workflow, VAMI … should not be used to upgrade the vCenter Server.” That warning only makes sense because they’re different interfaces driving different processes – if VAMI itself performed RDU, there’d be nothing to warn against running “at the same time.”
vCenter quick patch (new in 9.1, run from VAMI) is scoped to security patches, not version upgrades – Broadcom’s own “what’s new” material for it is explicit that it “targets rapid deployment of important security fixes,” not major or minor version jumps.

VAMI’s legitimate role in an upgrade is limited to naming and first-boot config of the new appliance (Stage 1 below) and to routine within-major-version patching – not to starting or driving the upgrade itself.

Before you start: confirm the source is actually on a supported path

Do not assume “any 8.x can reach any 9.1.x” – the same back-in-time restriction called out in Confirm a supported upgrade path applies to vCenter itself, patch level by patch level.

Checked against the Broadcom Product Interoperability Matrix (Upgrade Path tool, vCenter, “Hide Patch Releases” unticked) and KB 448135 (“Back-in-Time Upgrade Restriction for vSphere 8.0 Update 3j and later, NSX 4.2.4 and later, VMware Cloud Foundation 9.1.0.x”):

vCenter 8.0 U3j and later → any 9.1.0.x build or 9.0.x build: blocked. The security patches in those U3j+ builds are chronologically newer than the 9.1.0.x / 9.0.x baseline, so upgrading would regress fixes – VCF refuses the path outright.
vCenter 8.0 U3j and later → 9.1.1.0: open. KB 448135, verbatim: “VMware Cloud Foundation 9.1.1.0 has been released with an updated Bill of Materials (BOM) that includes component build versions chronologically newer than the previous 9.1.0.0 restriction baseline. This effectively resolves the ‘Back-in-Time’ upgrade block for environments running vSphere 8.0 Update 3j and later, NSX 4.2.4 and later, VMware Cloud Foundation 9.1.0.x.”
Confirmed directly in the Upgrade Path tool: vCenter 8.0U3k shows green / Compatible against target 9.1.1.0, and red / Incompatible against every 9.1.0.x and 9.0.x build.

This is the same pattern as the VCF Operations 8.18.7 example already in the overview doc – a patch released after a given target build’s baseline can lose its path to that build entirely, and only a later point release (here, 9.1.1) reopens it. Re-run the Upgrade Path tool for the exact source build before committing to a target – do not extrapolate from a neighbouring patch level.

One open question this doc cannot resolve from documentation alone. The vSphere 9.1 TechDocs page for the GUI installer path is titled “Upgrade a vCenter Appliance 9.0 or later by Using the GUI” and states only that 9.0-or-later is a supported source for that installer flow – it does not mention 8.0 anywhere. That is inconsistent with the interoperability matrix and KB 448135 above, both of which say 8.0U3j+ is fine as a source once 9.1.1 is the target. Until this is confirmed with Broadcom support or observed on a real run, treat the matrix and the KB as the more current sources – but validate against a non-production vCenter, or open a support request, before doing this on a production appliance.

Prerequisites

From Prerequisites for Upgrading the vCenter Appliance, condensed:

Download and mount the vCenter 9.1.1 installer.
Sync clocks across the vSphere network.
Target ESX host (where the new appliance deploys): not in lockdown or maintenance mode. If it sits in a DRS cluster, set DRS to Manual or Partially Automated so nothing reboots mid-upgrade.
⚠ WARNING – never disable DRS. Only set it to Manual or Partially Automated. Turning DRS off on a cluster does more damage than it looks like:
- Resource pools are deleted. The entire hierarchy (pools, shares, reservations, limits) is removed, and per KB 339325 the resource pool hierarchy and affinity rules are not re-established when DRS is turned back on. The disable dialog offers to save a resource pool tree snapshot, but don’t rely on it as a safety net.
- Supervisor clusters are left unrecoverable. Per KB 323409, vSphere with Tanzu / Workload Management stores critical state in its resource pools; deleting them “will render the cluster in an unrecoverable state”.
- vApps block it. vApps need DRS, so vCenter refuses to disable DRS while any exist and tells you to delete them first (KB 410683). Don’t take that as a step to follow.
Manual or Partially Automated stops DRS from migrating the new appliance mid-upgrade while keeping all of the above intact. Set it back to its original automation level once the upgrade finishes.
Source appliance: port 22 open (the upgrade process opens an inbound SSH connection to export data) and port 443 open on the source ESX host.
Sufficient free disk space on the source appliance to stage the export.
No host profiles below version 8.0 on the source vCenter. The pre-upgrade check fails with “Source vCenter Server has unsupported version of host profiles” otherwise. Re-extract or delete them first: Host profiles below 8.0 block the vCenter 9 upgrade.
Static-IP path: forward and reverse DNS records ready for the temporary IP. DHCP path: the target ESX host must be on the same subnet as the source, on a port group that accepts MAC address changes.

Validate with VDT before you start

With no SDDC Manager here, there’s no fleet precheck to catch a bad source appliance before committing to the upgrade window – run the VCF Diagnostic Tool for vSphere (VDT) against the source appliance first. Full reference, download/setup, and what to do next if the Lookup Service / AD check flags something: VDT and lsdoctor: self-service diagnostic tools.

A FAIL here is cheaper to fix now than mid-migration – Stage 2’s own pre-upgrade check (below) re-verifies some of the same ground, but only after Stage 1 has already deployed the new appliance.

Backup, before touching anything

VM-level snapshot only – this is what Broadcom’s own prerequisites call for here, not the file-based/VAMI backup that other docs in this repo treat as mandatory. The two situations are structurally different: an in-place change on the only appliance (like IWA to AD-over-LDAPS) has nothing to fall back to except a file-based restore if it goes wrong. This upgrade deploys a brand-new appliance and leaves the old one fully intact, just powered off – the old appliance itself is the primary fallback, snapshot or not (see After cutover). The snapshot is Broadcom’s stated belt-and-braces precaution on top of that, in case something damages the source appliance mid-migration, before cutover: “Create an image-based backup (snapshot) of the vCenter appliance you are upgrading as a precaution in case there is a failure during the upgrade process.”

Offline/no-memory snapshot of the source appliance, per standard pre-change practice.
Enhanced Linked Mode: “To take a pre-upgrade image-based backup in an Enhanced Linked Mode environment, power off all the vCenter appliances in your environment, and back up each node” – then restart them all before proceeding. (This doc otherwise covers a single vCenter, not ELM – see After cutover – but take the snapshot correctly regardless if the source happens to be ELM-joined.)
What “restore from backup” actually means here, per TechDocs: “If the upgrade fails, delete the newly deployed vCenter appliance, and restore the vCenter appliance from backup” – i.e. delete the new appliance, revert the old one from this snapshot (or just power it back on if it was never touched – see the network-adapter caveat under After cutover either way).

Before Stage 1: rename the old vCenter appliance

Stage 1 step 5 names the new appliance – and by default that’s the only naming decision in the whole flow, since the new appliance takes over the old one’s IP and FQDN at cutover rather than its display name. Rename the old vCenter appliance (VM name in the inventory, and its own appliance name if surfaced in VAMI) to something clearly marking it as the outgoing instance – for example appending -old or the source build number – before starting Stage 1. Do this as normal procedure, not an afterthought:

It lets the new appliance be named correctly – the actual destination name – from the moment it’s deployed in Stage 1 step 5, instead of deploying it under a throwaway name and renaming it after cutover.
It avoids two identically-named vCenter objects existing side by side once the new appliance is up (the old one stays powered off but undeleted per After cutover, so the name collision would otherwise persist until it’s cleaned up).

Stage 1 – deploy the new 9.1.1 appliance

From Stage 1 – Deploy the OVA File of the New vCenter Appliance:

From the mounted installer, run vcsa-ui-installer/<your-OS>/installer (win32\installer.exe, lin64\installer, or mac/Installer.app).
Home page → Upgrade. Read the Introduction, Next. Accept the EULA, Next.
Connect to source appliance: source FQDN or IP, HTTPS port (443 unless custom), the SSO administrator username (administrator@your_domain) and password, and the source appliance’s root password. Accept the SSL thumbprint prompt.
Connect to target: where the new appliance deploys – either an ESX host directly, or a vCenter instance (browse to a datacenter, then an ESX host or DRS cluster). This target must be a different vCenter than the one being upgraded – use the ESX host directly if there is only one vCenter in the environment.
Name the new appliance and set its root password. Note: the old appliance’s root password is not carried over to the new one.
Pick a deployment size (Tiny / Small / Medium / Large / X-Large) to match the environment, then a storage size (Default / Large / X-Large).
Pick the datastore, optionally enabling thin provisioning.
Configure the temporary network – a network reachable from both appliances, static or DHCP, IPv4 or IPv6. This is throwaway; the new appliance takes over the old one’s real IP and FQDN at the end of Stage 2.
Review, Finish to start the OVA deployment, then Continue into Stage 2. (Clicking Close instead leaves the new appliance deployed but unconfigured – no data transferred, no services started – and Stage 2 has to be resumed from the new appliance’s own VAMI.)

Troubleshooting: “invalid single sign-on credentials” at step 3

Step 3 (“Connect to source appliance”) can reject correct credentials with a generic invalid-SSO-credentials error. Work through these in order – each rules out a distinct failure mode, and the error text is identical for all of them, so don’t stop at the first plausible-sounding cause without actually checking it:

Confirm the credentials really are correct, outside the installer. Log in to the source vCenter’s own UI with the same root and SSO admin credentials being entered in the wizard.
Clock skew between the machine running the installer and the source appliance. SSO token validation is time-sensitive – a few minutes of drift produces this exact error even with a correct password. Compare date output on both.
IP vs FQDN against the Machine SSL certificate’s SAN. If the source is entered as an IP address but the cert’s SAN only covers the FQDN (or vice versa), SSO auth fails on the mismatched form even though connectivity and the thumbprint-acceptance step both pass. Try the other form.
Custom SSO domain suffix. Do not assume vsphere.local – confirm the actual domain under Administration → Single Sign-On → Configuration on the source vCenter and use administrator@<that domain> exactly. This was the confirmed cause in a field-verified case – a customized domain suffix typed incorrectly, with reachability, the cert thumbprint, root, and the SSO password all independently correct and no clock skew present.
Account lockout. Check Administration → Single Sign-On → Configuration → Lockout Policy – prior failed attempts (including the installer’s own retries) can lock the account even though the password being tested now is correct.
Credential entry artifacts. Retype the password by hand instead of pasting, in case of trailing whitespace or a hidden character from a password manager.
Read the actual rejection reason from the source appliance’s own logs, rather than continuing to guess from outside it:
```
ssh root@<source-appliance>
grep -i "invalid credential\|authentication fail\|lockout" /var/log/vmware/sso/vmware-identity-sts.log
```
Also check /var/log/vmware/vmdird/vmdird-syslog.log for the same timestamp. The STS log records the real reason (locked account, wrong domain, genuine bad password, etc.) behind the wizard’s generic message.

Stage 2 – migrate data and cut over

From Stage 2 – Transfer the Data and Set up the Newly Deployed vCenter Appliance:

Reconnect to the source appliance (same credentials as Stage 1).
Reconnect to the source ESX host or vCenter (same admin credentials).
Wait for the pre-upgrade check – it runs only after both reconnections above complete. This is where a back-in-time or interoperability block, if there is one, is most likely to surface – fix any reported errors before continuing. If the SSO credentials entered in Stage 1 were wrong, this is also where that authentication error shows up.
Select migration data – configuration only (fastest, least storage) versus configuration plus historical and performance data (slower). With an external Oracle database, historical/performance data can instead be migrated in the background after the new appliance starts.
CEIP opt-in choice.
Ready to complete – review the settings, accept the backup acknowledgment, Finish.
Acknowledge the shutdown warning – the source appliance is powered off at this point.
Wait for the data transfer and service startup to finish, then OK to reach the new vCenter’s Getting Started page.

Alternative: CLI-driven upgrade using the OVA directly (vcsa-deploy)

Stages 1 and 2 above are the interactive vcsa-ui-installer GUI wizard. The same mounted ISO also ships a CLI installer that drives the identical two-stage deploy-then-migrate process unattended, from a JSON template that points straight at the appliance’s OVA file – useful for scripting or repeating the same upgrade across several vCenter instances.

This is not the same thing as manually running “Deploy OVF Template” in the vSphere Client. Broadcom’s upgrade TechDocs for 9.1 document only the GUI wizard and this CLI installer as supported upgrade methods – there is no documented upgrade path that has you drive the vSphere Client’s own OVF deployment wizard against the ISO’s OVA yourself. (Deploying that OVA straight through the vSphere Client is a real, supported procedure, but it’s the fresh-install flow – a brand-new, empty appliance configured through its own first-boot VAMI wizard – not an upgrade that migrates an existing vCenter’s inventory and config across.) The CLI installer covered here is the closest supported “point it at the OVA file” alternative to the GUI wizard.

From the mounted installer, the JSON templates live in vcsa-cli-installer/templates/upgrade/. Copy the template matching the source topology (embedded SSO, external PSC, HA cluster, etc.) and edit it in a JSON-aware editor.
Point the template’s image field at the appliance OVA shipped in the ISO’s vcsa/ folder, for example:
```
"image": "G:\\vcsa\\VMware-vCenter-Server-Appliance-9.1.1.XXXX-YYYYYYY_OVF10.ova"
```
The CLI installer reads this JSON and generates an ovftool command internally to deploy that exact OVA – there’s no separate manual OVF step to perform.
Fill in the same information Stage 1/Stage 2 ask for interactively: source appliance and SSO credentials, target ESX host or vCenter, temporary network, new appliance name/root password, deployment and storage size, and migration-data scope.
All values ASCII-only – the CLI machine’s own username, the path to the installer, the path to the JSON file, and every string value inside it (passwords included). Extended ASCII / non-ASCII characters are unsupported and fail the run.
Run the CLI machine (Windows, Linux, or Mac) from the same network as the appliance being upgraded:
```
vcsa-deploy upgrade --verify-template-only path_to_the_json_file
vcsa-deploy upgrade --precheck-only path_to_the_json_file
vcsa-deploy upgrade --accept-eula --acknowledge-ceip --log-dir=path_to_the_location path_to_the_json_file
```
--verify-template-only validates the JSON without deploying anything; --precheck-only runs the same pre-upgrade check Stage 2 waits on interactively, without proceeding to migration – useful to catch a back-in-time or interoperability block before committing.
Same outcome as the GUI path: the old appliance is powered off once migration starts, the new one takes over its IP/FQDN, and the same After cutover steps below apply.

Broadcom reference: Upgrade a vCenter Appliance by Using the CLI.

After cutover

The new 9.1.1 appliance now holds the old appliance’s IP and FQDN; the old appliance is powered off but not deleted – keep it as the rollback position until the upgrade is verified. This rollback path only exists because this upgrade method deploys a brand-new appliance – it’s not available for an in-place, single-appliance mechanism with no separate “old” VM left behind to power back on.
Don’t power the old appliance back on without disconnecting its network adapter first. For the fleet-managed RDU path specifically, Broadcom KB 313288 documents this as destructive, not just risky: “if powered on, deletes the target VM” – i.e. powering the old appliance back on while still network-connected deletes the new one, the opposite of what a rollback is for. This doc’s plain GUI/CLI two-stage upgrade isn’t explicitly covered by that KB (it only discusses RDU), but since this doc’s own intro describes it as “the same underlying two-stage migration mechanism” – treat the same precaution as the safe default here too, rather than assuming it doesn’t apply: disconnect the old appliance’s network adapter before powering it back on for any reason, roll back or otherwise. If a rollback is actually being executed (not just testing), power off the new appliance first as well, so both aren’t live on the network with the same IP/FQDN at once.
If the old appliance used a non-ephemeral distributed virtual port group, reconnect the new appliance to it manually – that setting is not carried over automatically when deploying straight to an ESX host (not a limitation when deploying through a vCenter instance instead).
Set DRS back. If the cluster’s DRS automation level was lowered to Manual or Partially Automated for the upgrade (see Prerequisites), decide now whether to restore it. Per Broadcom: “you can either continue to use the modified settings or revert the automation level to fully automated.” It does not revert on its own.
License the vCenter and activate it in VCF Operations. Broadcom’s first two post-upgrade items: assign the vCenter a license in VCF Operations, and “Activate your vCenter instance for management by the VCF Operations cluster”. Per KB 424630: in VCF Operations go to Administration → Integrations → VCF, select the vCenter entry, and click Activate Management. Until that is done the vCenter is missing from License Management and can show expired-license warnings. If the license then shows Assignable: No, hover over the No: it is usually a core-capacity shortfall, with ESX 8 hosts counted too (field note). Background: Registering vCenter as a data source.
Verify the upgrade. Broadcom’s verification list: IP address, Active Directory registration, network registration, domain, valid certificates, inventory data migrated, events history, performance charts, and users, permissions, and roles. Compare that last one against the export taken in IWA to AD-over-LDAPS migration, if that was part of the preparation.
Re-register plug-ins. Third-party plug-ins (backup, storage, monitoring) may need registering again, because the SSL certificate is refreshed during the upgrade. Per Broadcom’s Reregister Plug-In Solution page, use the vendor’s own re-registration procedure first. Only if that fails, remove the registration through the Managed Object Browser and register again:
1. Browse to https://<vcenter-fqdn>/mob/?moid=ExtensionManager and log in with vCenter credentials.
2. Under Methods, click UnregisterExtension.
3. Enter the extension’s key value and click Invoke Method.
4. Register the plug-in again from the vendor’s solution registration page.
Verify it in the vSphere Client under Administration → Solutions → Client Plug-Ins → Check for New Plug-Ins, or log out and back in (the client checks for new plug-ins on each new session). To remove plug-ins you no longer need, Broadcom points to KB 344648.
Historical data migrating in the background. If Stage 2 imported historical data in the background, follow the progress in the vCenter Management Interface (https://<vcenter-fqdn>:5480, as root): a status bar shows the percentage copied, and Manage offers Pause and Resume, to keep performance up during business hours. Do not pick Cancel: per Broadcom, “You cannot recover the data once you cancel the operation”, and importing it later means restarting the upgrade from Stage 1. A success message in the status bar marks the end.
Re-check the known 8 → 9 side effects and carry-overs, none of which the installer flags:
- the Lifecycle Manager depot token (field notes);
- the outbound proxy configuration, which moved to a different file on 9.x (vCenter proxy configuration);
- custom /etc/hosts entries, which do carry over (field-verified 8.0.x → 9.1.1); compare against a copy of the old file (field notes).
Continue with the rest of the Standalone VVF manual upgrade steps (ESX hosts, vSAN on-disk format, vSAN File Service) as applicable, and its Post-upgrade validation checklist.
When the vDS version is upgraded later (after the ESX hosts), a vDS with no host members can keep a stale “upgrade in progress” banner in All Issues – see the field notes for the fix.
This is a single vCenter, not Enhanced Linked Mode – the multi-node backup/restart sequencing called out for ELM environments in the prerequisites does not apply here.

Broadcom reference: About the Upgrade Process of the vCenter appliance; KB 448135; KB 313288 (old-appliance network-disconnect warning, documented for RDU); KB 344917 (VDT); KB 339325, KB 323409 and KB 410683 (what disabling DRS breaks); the Broadcom Product Interoperability Matrix, Upgrade Path tool.