Over about five years I ran multiple rounds of VMware host replacement and vSphere upgrades across our multi-site environment, and I did all of it during normal business hours with zero impact to the workloads running on top. Each round covered roughly 10 to 25 hosts at a time, full hardware refreshes, major-version ESXi and vCenter upgrades, and SAN refreshes running in parallel.
Everything aging at once
The reason this was a program and not a one-off is that three clocks were running down together. The hosts were aging out of vendor support, the vSphere versions were falling behind, and the storage was reaching end of life on the same timeline. Any one of those is a routine refresh. All three at once, on a platform that could not go down, is where it gets interesting.
And it could not go down. A lot of those guests ran plant-floor and quality systems, where an outage means lost production on a line that is supposed to run around the clock. There were also no after-hours change windows to hide in. The maintenance had to happen in the middle of the business day without anyone on the floor or in the office noticing, and hardware, hypervisor, and storage all had to move on overlapping schedules without stacking risk on top of risk.
A rolling program, not a project
So I built it as a rolling program, sized so each refresh cycle could absorb the next one without a forklift moment. I planned every cycle against current workloads, growth headroom, and the next two refresh horizons, and sized the new hosts so the cluster could lose a node and still run hot. Replacement hosts were pre-built and pre-configured on the bench, so by the time a new server joined the cluster it was fully ready and the production change was just a vMotion sweep and a host evacuation.
From there the pattern repeated. vMotion and Storage vMotion moved live VMs onto new hardware and new storage with no guest downtime, in waves, while people kept working. SAN refreshes happened inside the same windows, storage migrated under running VMs and the old arrays decommissioned once everything was clear. ESXi and vCenter upgrades followed the same one-host-at-a-time rhythm: evacuate, upgrade, return to the cluster, move to the next. Every phase was validated against a checklist of guest health, performance baselines, backup success, and DR replication before the next host moved.
Nobody noticed, which was the point
Across every cycle, production downtime was zero. Plant operations and office users were unaffected, and all of it happened during the business day with no weekend maintenance and no after-hours pages. That is the part that matters to the business: the platform underneath a 24/7 operation got modernized repeatedly, and the operation never had to stop, and never paid overtime, for the privilege.
The refreshes also paid for part of themselves. As newer hardware absorbed more workload per node, the host count and the vSphere licensing footprint consolidated, which pulled down power draw, rack space, and licensing cost at the same time.
The foundation it left
The quieter return was what the modernized platform made possible next. Isolated backup infrastructure, the EDR/XDR rollout, and next-gen firewall segmentation all rode on top of the refreshed cluster, and the team came out of it with a repeatable refresh pattern it could run every cycle after.
The win was never vMotion itself, which is only a tool. It was treating refresh as a continuous program, sizing each cycle to make the next one easy, and doing the boring preparation so the cutover looked uneventful. The quiet upgrades are the ones that worked.