A hyper-converged refresh scheduled around the school year

The situation

A unified school district needed to refresh the virtualization platform behind its district operations and instructional systems. The technical scope was ordinary: a Hyper-V failover cluster build and a hyper-converged platform deployment, migrating existing workloads onto new hardware.

The constraint was the calendar. A school district has two realistic change windows in a year, and neither is negotiable. Anything that overruns does not slip by a week — it slips by a term.

What we did

Built the plan backwards from the calendar. Blackout periods were established before the project plan existed: testing windows, the opening weeks of each term, and the district’s own operational deadlines. Every phase was then scoped so it could either complete or fully roll back inside its window.

Cluster design with validated failure behavior. The Hyper-V failover cluster and hyper-converged platform were designed with explicit documentation of operational limits — how many nodes could be lost, what happened during maintenance, and what the actual failover behavior was under load. Districts lose IT staff regularly, and undocumented limits become outages two years later when nobody remembers them.

Migration in sequence, validated per workload. Workloads moved onto the new platform in a planned sequence, each validated for boot, connectivity, and application service state before the source was retired.

Handover as a deliverable. As-built documentation, operational runbooks, and training for district IT staff covering day-to-day operations, node maintenance, and storage management. This was written into the statement of work rather than offered informally at the end.

The outcome

The refresh completed inside its window with no instructional downtime. The district retained documentation and operational knowledge rather than a dependency on the vendor who built it.

The engagement was delivered entirely under the reseller partner’s brand. They had supplied the hardware, held the relationship, and needed engineering capacity for the cluster design and migration — capacity that would have been difficult to justify hiring permanently for two projects a year.