The situation
The brief looked conventional: replace a three-host VMware estate, move production workloads, upgrade from vSphere 7 to 8 and retire the old hardware. In practice, the risk sat in the transition. Host networking, storage presentation, switching, licensing and live workloads all had to remain understandable and reversible while the estate changed underneath them.
What I found
Detailed discovery separated configuration that still mattered from configuration that had simply survived. It also exposed a less obvious resilience problem: the wireless-controller VM was effectively tied to one legacy host and network path. The storage assessment showed limited comfortable headroom, while the emerging VMware licensing changes made the commercial timing part of the technical decision.
What I changed
I built the new hosts on a version compatible with the live estate, joined them to the cluster, presented storage and validated network paths before moving production VMs with vMotion. Only after the workloads were running on the new hardware did I upgrade the platform to vSphere 8 and raise VM compatibility. I also recreated the required wireless-controller connectivity across the new estate and refined the connectivity design to meet resilience needs without unnecessary cost.
What happened
Production workloads moved onto the new three-host platform, the estate was upgraded and the previous hosts retired. The hidden wireless-controller dependency was removed, storage performance and headroom improved, and the implementation was completed in-house with the platform and licensing decisions documented for support.
What I’d carry forward
Migration and upgrade are different risks. Keeping them as separate stages made each change easier to validate, easier to reverse and considerably less dramatic than combining both because the maintenance window happened to be available.