Upgrade vCenter 8 to 9: Safe Migration Assistant Steps

vCenter 9.1.1.0 is the current release, and upgrading from 8.0 U3 is the first step in any move to ESXi 9, because vCenter must always be at or above the version of the hosts it manages. The upgrade is a migration rather than an in-place update: the installer deploys a brand-new 9.x appliance alongside the old one, copies configuration and data across, then shuts the old appliance down and takes over its network identity. That design makes rollback simple but demands careful preparation. This guide covers VCSA 8.0 U3 (any patch level) to vCenter 9.1 with an embedded Platform Services Controller, which is the only topology 8.0 supports.

Applies to VCSA 8.0 U3 to vCenter 9.1

Short answer: Take a file-based backup of the 8.0 appliance and a VM snapshot, then run the vCenter 9.1 installer from a workstation, choose Upgrade, and complete stage one by pointing it at the source appliance and its ESXi host and deploying a temporary new appliance with a temporary IP. In stage two, pick the data to migrate (configuration only, or with events and performance data), run the pre-upgrade check, and let the installer copy the data and switch the network identity. Verify with the VAMI at https://vcenter:5480, service-control --status, and by logging in to the vSphere Client.

Before you start

• Confirm the source is 8.0 U3 or later; older 8.0 builds should be patched first through the VAMI.
• Check the ESXi hosts: vCenter 9 can manage ESXi 7.0 U3 and 8.0 hosts, so hosts do not need upgrading first, but the host that runs the source and target appliances must be reachable directly by the installer workstation.
• Note the SSO administrator password, the root password, and confirm the root password has not expired (see Fix vCenter root password expired and VCSA disk full).
• Time sync: the source appliance and the target host must agree on time; NTP drift is the most common pre-check failure.
• Remove expired certificates and stale extensions. In the vSphere Client » Administration » Client Plugins, unregister anything for products no longer in use; the pre-check flags plugins that are incompatible with 9.x.
• Check disk space on the source, particularly /storage/log and /storage/seat; a full partition breaks the export.
• Take a file-based backup from VAMI » Backup and a cold snapshot of the appliance VM.

Run the pre-upgrade checker from the appliance shell to catch issues early:

service-control --status --all
df -h

Stage one: deploy the new appliance

Mount the vCenter 9.1 ISO on a management workstation and run vcsa-ui-installer\win32\installer.exe (or the Linux and macOS equivalents). Choose Upgrade. Supply the source appliance FQDN, its SSO administrator credentials and root password, then the ESXi host or vCenter that manages it. Next, choose the target host or cluster, folder and datastore for the new appliance, set the deployment size (the installer recommends a size based on the source inventory and will not allow a smaller one), and give the new appliance a temporary IP on the same subnet. Stage one deploys the OVA and boots the new appliance; wait for it to finish and click Continue.

Stage two: migrate the data

Stage two connects to the temporary appliance and runs the pre-upgrade check against the source. Resolve every error; warnings about deprecated features can generally be accepted. Choose the migration data set:

• Configuration and inventory only: fastest, loses historical events and stats.
• Configuration, inventory, tasks and events.
• Everything including performance metrics: slowest, can take hours for large inventories.

Confirm, and the installer exports from the source, shuts it down, assigns its IP and hostname to the new appliance, and imports. Do not power the old appliance back on while the new one is running with the same identity.

Validate the result

From the new appliance shell:

service-control --status --all
/usr/lib/vmware-vmon/vmon-cli --list
df -h

Every service should be running and no partition should be near full. In the vSphere Client, check the inventory, host connection states, DRS and HA settings, distributed switches, and that licences carried over (vCenter 9 uses the new licensing model; check Administration » Licensing). Log in to https://vcenter:5480, confirm the version, and set up the backup schedule again if it did not migrate. Then re-register third-party products that use the vCenter API: backup software, monitoring, Horizon and NSX all need a re-authentication at minimum.

Common pitfall

Leaving the old appliance’s VM in the inventory with its network adapter connected invites someone to power it back on, which immediately creates an IP and hostname conflict. Rename the old VM, disconnect its NIC, and keep it powered off for a week before deleting it. The second frequent issue is a distributed switch on an older version that the pre-check ignores; upgrade the VDS version after the vCenter upgrade completes, not before.

Upgrade vCenter 8 to 9 at a glance

Official documentation: Broadcom TechDocs (VMware), Linux man pages.

Related guides: Migrate VMs from VMware to Proxmox VE 9 after the Broadcom licensing changes · Convert a physical Windows Server to a VMware VM (P2V) in 2026 · Upgrade ESXi 8.0 U3 to ESXi 9.1 with esxcli and Lifecycle Manager.

Frequently asked questions

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by

srvScripts editorial team

Supported versions

VCSA 8.0 U3 to vCenter 9.1

Last full review

3 Oct 2026

Next review

1 Apr 2027

Sources

techdocs.broadcom.com