Broadcom's current vSAN refresh guidance presents two fundamental paths: replace hosts inside the existing cluster or build a new cluster and migrate workloads. Both can reach newer hardware, but they create different failure exposure. Treating the purchase list as the migration plan hides the real decision about how much data movement, reduced resilience, and rollback difficulty the production estate can tolerate.
Why it matters in production
An in-place refresh preserves the cluster identity and can reduce temporary hardware needs. It also forces repeated evacuation, rebuild, maintenance-mode, and compatibility cycles while the same production cluster changes underneath its workloads. Free capacity, resynchronization traffic, object compliance, fault-domain layout, and time at reduced redundancy must be measured for every replacement step.
A new cluster needs additional capacity and migration connectivity, but it creates a cleaner rollback boundary. Hardware, firmware, network, storage policy, monitoring, backup, and operational procedures can be validated before workloads move. The design can also change RAID layout or architecture deliberately instead of carrying every old assumption forward because the cluster name remains the same.
The choice should follow evidence: current utilization, rebuild duration, failure tolerance during maintenance, workload mobility, network capacity, license and support constraints, and the recovery path if a host or disk group fails mid-change. Run a representative evacuation and migration test. Measure application effects rather than accepting only a completed vSAN task.
Practical takeaway
The practical takeaway is that hardware refresh is a data migration project. Choose the path that gives the estate enough resilience and a credible rollback, then size temporary capacity and maintenance windows from measured movement. Replacing servers is the visible action; controlling where data lives and how it remains protected is the actual change.