A client planning their vSAN move into VCF 9 assumed the ESX upgrade would slot into the same maintenance window as everything else. It didn't. Their cluster was still running on VUM baselines, and the ESX upgrade step in a VCF 5.2 to 9.x migration requires converting from VUM to image-based lifecycle management first. That conversion is its own project. It's not a checkbox on the way through to something else.
The bigger surprise usually shows up right after that gets sorted.
The vLCM Requirement Isn't Optional Anymore
VCF 9.0 requires vLCM images for every new vSAN cluster, OSA or ESA, no exceptions. There's no path where a cluster stays on baselines and just happens to run vSAN fine underneath VCF 9 — the platform expects image-based lifecycle management as a precondition, not a nice-to-have. For an environment coming from an older VCF or standalone vSphere deployment that never moved off VUM, that conversion has to happen before the ESX upgrade step, which means it has to be planned as its own phase with its own risk, not folded silently into "the upgrade."
There's No In-Place Path From OSA to ESA
If the target architecture is ESA specifically, the constraint gets sharper. In-place conversion from OSA to ESA isn't supported at all. There's no upgrade wizard that walks an existing OSA cluster into ESA the way a version bump walks ESXi from one build to the next. The actual move is building a new ESA cluster alongside the old one, migrating workloads across, then decommissioning what's left once everything's confirmed running.
That's capacity planning and a migration wave, not a maintenance window. Anyone scoping "upgrade to ESA" as a weekend task is scoping the wrong project.
Version Staging Has Its Own Rules
An environment still on VCF 4.x can't jump straight to 9.1 — it has to stage through 5.2 first, no skipping the intermediate release. The 5.2-to-9.x path itself runs Aria Suite components up to a minimum version before the VCF Operations and Automation upgrade even begins: Aria Suite Lifecycle to 8.18 Patch 2, Aria Operations to 8.14 or 8.18, Aria Automation to 8.18. Only after that does the core component sequence run — SDDC Manager, then NSX, then vCenter, then ESX, then vSAN, then the vSphere Distributed Switch. Skipping ahead in that order isn't really an option the tooling gives you; it's a sequence, not a menu.
Hardware Compatibility Gets Stricter, Not Just Different
ESA leans harder on specific hardware assumptions than OSA ever did, and a few of the rules genuinely surprise people the first time they hit them. NVMe devices sitting behind a Tri-Mode RAID controller aren't supported for vSAN diskgroups at all — direct PCIe attachment is required, full stop. Storage controllers need to run pass-through (IT or JBOD mode) or single-disk RAID-0; controller-level RAID-5 or RAID-6 simply doesn't work with vSAN underneath it. And running 10GbE on an ESA cluster will trigger a compliance-check warning even though it's the documented minimum for the smallest ReadyNode profile — which catches people off guard, because the warning reads like a real problem and technically isn't one at that tier.
- NVMe behind Tri-Mode RAID controllers isn't supported for vSAN diskgroups — direct PCIe attachment only.
- Controller-level RAID-5/6 is incompatible with vSAN. Pass-through or single-disk RAID-0 only.
- 3-node vSAN HCI clusters won't auto-rebuild components after a failure — plan for 4+ nodes if that matters to the design.
- vSAN Reserved Capacity is incompatible with 3-node clusters, stretched clusters, and clusters using fault domains.
- Key Management Service placement — never put the vSAN KMS on the vSAN datastore it's meant to protect. Chicken-and-egg dependency if that datastore ever needs recovery.
Confirming which architecture is actually running post-migration is simpler than it sounds, and worth doing rather than assuming: esxcli vsan storage list returns results on OSA and comes back empty on ESA; esxcli vsan storagepool list is the reverse. One command, and there's no ambiguity left about what's actually deployed underneath.
Confirm whether the current cluster is on VUM baselines or vLCM images — the conversion, if needed, is its own phase, not a line item inside the ESX upgrade.
If the target is ESA, plan for a parallel build and workload migration, not an in-place conversion. There isn't one.
Check the version staging path explicitly — VCF 4.x has to pass through 5.2 before reaching 9.1, and the Aria Suite components have their own minimum versions ahead of the core upgrade sequence.
Audit storage controller mode and NVMe attachment method against ESA's hardware requirements before assuming existing hardware qualifies.
None of this makes the move to ESA the wrong call — for most environments planning ahead, it's the right one. It's just a genuinely different scope of work than a routine platform upgrade, and the gap between those two scopes is exactly where a migration plan built on assumptions instead of verification runs into trouble.