A client called mid-upgrade this summer, confused because the NSX bundle they needed simply wasn't showing up in Binary Management. Not failing. Not throwing an error. Not there. Nothing was actually broken. SDDC Manager has to upgrade before any other bundle becomes selectable at all — the UI doesn't offer the next step until the first one clears, and there's no setting to unlock it early.
That distinction matters more than it sounds like it should. A missing bundle reads as a problem. It's actually the tooling doing exactly what it's supposed to do, which is refuse to let anyone get ahead of the sequence.
The Order Is Enforced, Not Suggested
The full flow for an in-place VCF upgrade runs a specific sequence: precheck, resolve whatever it flags, upgrade SDDC Manager itself — binaries and configuration — then NSX, Global Managers before Local Managers, then licensing, then the vSphere Distributed Switch, then the vSAN disk format, then ESXi hosts, then vCenter Server, then the Workload Domains, then post-upgrade tasks. Ten stages, in that order, every time. Trying to work ahead of it mentally doesn't change what the tooling will actually let happen.
At a higher level, that same flow groups into precheck, then Management Domain core components (SDDC Manager, NSX Manager, vCenter, ESXi), then the management components layer (VCF Operations), then the Workload Domain core components, with operational verification built in at each stage before the next one starts. The granular order and the grouped order describe the same thing at different resolutions, and both explain why a bundle that looks "missing" is really just waiting its turn.
Version Floors Aren't Negotiable Either
Sequencing within a single upgrade run is one constraint. The minimum source version for the target you're aiming at is a separate one, and it moves as the platform matures. A VCF 9.1.x target requires a minimum source of VCF 5.0.x and vSphere 8.0.x. Older environments than that don't get a workaround — the precheck simply fails, and the actual fix is an intermediate hop to a supported source version first, not a flag to override.
A bundle that isn't visible yet and a version that's too old to target directly produce the same feeling — something's obviously wrong — for two completely different reasons, and only one of them has a quick fix.
What Actually Fails at the Management Domain Precheck Stage
Once you've watched enough of these run, the failures cluster around a short list of repeat offenders. A VM-host affinity rule can block a host from entering maintenance mode during the upgrade — nothing wrong with the upgrade itself, just a rule that needs clearing under Configure > VM/Host Rules before the precheck will pass. Two VMs sharing a disk with the multiwriter flag set will block the maintenance mode dry run outright; both need to be powered off, gracefully in production, before that specific check clears. A missing vCenter backup usually surfaces as a soft, acceptable warning rather than a hard blocker — worth confirming in vCenter's VAMI backup screen before anyone treats it like an emergency it isn't.
- Depot connection error ("Depot Invalid User Credential"). Fix under Administration > Depot Settings. The target bundle has to be downloaded through Lifecycle Management > Binary Management first — and again, SDDC Manager has to upgrade before later bundles become visible there at all.
- VM-host affinity rule blocking maintenance mode. Clear or disable it under Configure > VM/Host Rules.
- Multiwriter disk conflict. Two VMs sharing a disk on the multiwriter flag block the maintenance mode dry run. Power off both before re-running the check.
- Missing vCenter backup warning. Usually soft, not a hard blocker — verify via vCenter VAMI > Backup rather than assuming it's stopping the upgrade.
When It's Actually Broken vs. When It's Just Waiting
If a precheck run does throw a genuine failure rather than a bundle simply not being visible yet, RETRY ALL FAILED RESOURCES re-runs only the items that failed instead of restarting the entire precheck from the top — a small feature, but a meaningful one on a check that can take a while against a large environment. If the upgrade gets stuck mid-execution rather than failing at precheck, lcm-activity.log carries the high-level flow and is usually the first place to look; lcm-debug.log is where the actual root cause tends to live once activity-level logging doesn't say enough.
Confirm the source version actually meets the minimum floor for the target — don't assume "recent enough" is the same as "supported."
Check for VM-host affinity rules and multiwriter disk configurations in the Management Domain before the maintenance mode dry run finds them for you.
Expect later-stage bundles to stay hidden in Binary Management until SDDC Manager itself has upgraded — that's normal, not a fault.
Have the depot credentials and target bundle download confirmed before the maintenance window starts, not during it.
None of this is complicated once it's been seen once. The problem is that most of it only gets seen once, mid-upgrade, under time pressure, by whoever happened to be running the window that week — which is exactly the kind of thing a bundle sequencing trap is built to catch you on.