After Broadcom: 250-VM Hyper-V Migration in 90 Days

A 250-VM mid-market manufacturer in the Pacific Northwest opened their VMware renewal quote in February 2026. Three years prior, they had paid roughly $22K/year for vSphere Standard plus support across eight hosts. The Broadcom renewal, on the cheapest VMware Cloud Foundation bundle that met the 16-core-per-CPU minimum, came in at $310,000 per year. Their CFO called us the same week. Ninety days later, every production VM was running on Hyper-V, the VMware contract was unsigned, and the project had cost about $35K in labor.

This post is the anonymized timeline of that engagement. It's the version we wish we'd had to share with the last three CIOs who asked us "is 90 days actually realistic?" The short answer is yes — for a mid-market Microsoft-stack environment, with senior engineering and a disciplined sequence. Here's what disciplined looks like.

The 250-VM environment we walked into

Before any prescription, the shape of the environment. Anonymized but representative:

• 250 VMs across 8 ESXi hosts in two clusters (one production, one mixed test/dev/DR)
• ~85% Windows Server (2016, 2019, with a small 2012 R2 tail), ~15% Linux (RHEL 7, Ubuntu 18.04 LTS, two CentOS 6 holdovers running plant-floor software)
• Hybrid identity — on-prem AD with Entra Connect sync, Exchange Online, mailbox migration completed in 2022
• On-prem storage tier — Pure FlashArray //X20 over 16Gb fibre channel; VMFS datastores; ~180 TB allocated, ~95 TB used
• Networking — Cisco Nexus core, vSphere Distributed Switch, NSX-V deployed but only used for microsegmentation on a single PCI-scope app cluster
• Backup — Veeam Backup & Replication v12, VMware-licensed, replicating to a secondary site over a 1Gb private link
• DR — vSphere Replication with manual runbook; tested annually
• IT staff — 4 full-time, 1 dedicated infra lead, mature Microsoft skills, intermediate VMware skills, light Linux skills

This is a textbook mid-market Microsoft-stack environment. The team had Windows Server Datacenter licensing already in place across the host fleet — meaning the hypervisor itself was effectively free once they walked away from VMware. That's the precondition that makes Hyper-V the natural destination here. If the customer had been Linux-heavy or running heavy vSAN with NSX-T everywhere, this would be a different post.

Phase 1 — Assess (weeks 1–2)

The discovery phase is where mid-market migrations are won or lost. Teams that skip it because "we already know our environment" are the ones that hit Week 9 with a surprise that resets the schedule. Two weeks is the floor; in this engagement we used the full two weeks.

What we cataloged

1. Per-VM inventory — vCPU, RAM, allocated storage, actually-used storage, disk I/O profile, network footprint, OS, application owner, dependency map. Pulled from RVTools, refined by interviews.
2. Hardware compatibility — every host's CPU, NIC, HBA, and BMC firmware against the Windows Server 2022 Hyper-V hardware compatibility list. Two NICs flagged for replacement.
3. Storage compatibility — Pure FlashArray firmware, multipathing, and Windows Server in-box driver coverage. Pure publishes a current Windows Server compatibility matrix; the customer's array firmware was within scope.
4. Application dependency map — every service account, every fixed IP, every license dongle, every "we don't know what this VM does but it's been running since 2014" candidate.
5. Backup and DR posture — Veeam licensing model, replica targets, retention policy, and the math on converting Veeam VMware sockets to Hyper-V sockets.

Where the surprises lived

Four of them, in order of impact:

• Legacy Linux guests. The two CentOS 6 plant-floor VMs ran a vendor-locked HMI that depended on an older VMware Tools userspace daemon for time sync. Hyper-V Integration Services covers most of this, but the vendor's support matrix didn't list Hyper-V. Decision: rebuild on Ubuntu 22.04 with the vendor's newer agent in parallel rather than lift-and-shift. Two weeks added to the affected workload, but isolated to a single production line.
• Custom NIC drivers. Two of the eight hosts had Mellanox ConnectX-4 NICs running an out-of-tree VMware-specific driver. Replacing with in-box Windows Server drivers required an offline firmware flash. Done during the host repurposing window — not a blocker, but a step that has to be sequenced before the host can join the Hyper-V cluster.
• Veeam license conversion. Veeam licensing converts cleanly from VMware sockets to Hyper-V sockets at no additional list cost on the same Universal License version, but the customer was on a legacy per-VM license that needed a Veeam-side migration to the current model. Net cost change: zero, but a 10-day procurement cycle on the paperwork.
• Third-party backup tools. Beyond Veeam, the customer ran Commvault for one regulated workload. The Commvault VMware proxy pattern doesn't translate cleanly; Commvault's Hyper-V integration uses a different agent model. Resolved by adding a Hyper-V-side proxy and re-pointing the policy.

Phase 2 — Design (weeks 3–4)

With inventory in hand, the design phase converts "what we have" into "what we'll build." For Hyper-V at 250-VM scale, the architectural decisions are mostly settled — but they have to be made deliberately.

Cluster sizing

Two Failover Clustering clusters, four hosts each, mirroring the existing vSphere topology. N+1 redundancy per cluster. Cluster Shared Volumes (CSV) on top of the existing Pure FlashArray, presenting block storage over iSCSI to keep the migration path simple (the option to revisit fibre channel after the cutover stayed open).

Storage strategy

Two valid paths. The customer ran the math on both:

• Keep the FlashArray as Hyper-V CSV via iSCSI — preserves the storage investment, no data migration, fastest cutover.
• Move to Storage Spaces Direct (S2D) on the same hosts — eliminates the SAN, modernizes, but adds hardware spend and risk.

They picked Path 1 for this engagement — keep the FlashArray, revisit S2D in 18 months when the array hits its refresh cycle. This is the right answer when the existing storage is healthy and depreciated. Don't over-modernize during a renewal-driven exit.

Networking

Hyper-V Virtual Switch with SET (Switch Embedded Teaming) on each host. VLANs mapped 1:1 from the existing vSphere Distributed Switch. The NSX-V microsegmentation use case (one PCI-scope app cluster) was rebuilt with Windows Defender Firewall plus Group Policy — adequate for the scope, eliminates the NSX renewal entirely.

Identity integration

Hyper-V hosts joined to the existing AD domain. Live Migration authentication via Kerberos constrained delegation. Cluster Aware Updating (CAU) wired to the customer's existing patching workflow. Entra Connect untouched — nothing about the Hyper-V layer should disturb the hybrid identity plumbing.

Phase 3 — Pilot (weeks 5–8)

Pilot is non-negotiable. The pilot environment was the existing test/dev cluster's repurposed hosts. Twenty-five representative VMs migrated first — a mix of Windows file servers, two SQL Server VMs, three Linux web nodes, one plant-floor HMI, and a Domain Controller (added late, deliberately).

What broke

• VMware Tools removal sequence. Some Windows guests held onto VMware Tools services after uninstall, blocking Hyper-V Integration Services registration. Resolved with a documented pre-cutover script that staged the removal and reboot before the migration job ran.
• Disk2VHD on encrypted volumes. One pilot SQL VM had BitLocker enabled at the volume level. Disk2VHD doesn't handle that cleanly. Used Veeam's instant recovery to Hyper-V instead — slower, but reliable.
• Static MAC dependencies. A vendor licensing tool keyed to a vNIC MAC address. Forced static MAC preservation through the migration. Documented for the rest of the cutover wave.
• Time drift on the rebuilt CentOS replacement. Even with chrony configured, initial NTP sync against the domain controllers was inconsistent. Fixed by adding the AD domain controllers as explicit NTP peers rather than relying on the default DHCP-provided pool.

What we learned

The pilot's job is to surface the things you didn't write down. By the end of week 8, the runbook had 17 documented edge cases with named owners and tested fixes. Every one of those 17 would have cost a day or more if discovered during production cutover. Pilot is the cheapest week of the project.

Phase 4 — Cutover (weeks 9–12)

Sequenced by department, weekend cutovers, with a formal rollback plan for every wave. The customer's IT director led the change-control process; we ran the engineering. The four-week cutover was structured as four waves:

Rollback plan

Every wave kept the source ESXi VM powered off but resident on the original VMFS datastore for 14 days post-cutover. Rollback meant reversing the network cutover and powering the source VM back on. We rolled back exactly twice across the four-wave cutover — once for a print server with an undocumented LPR queue dependency (resolved in 30 minutes, re-cut the next weekend), and once for a SQL VM where a vendor service didn't restart cleanly post-migration (resolved by Wednesday, re-cut the same weekend).

Decommissioning

By week 14, all VMware datastores were emptied, ESXi hosts were drained, and the vCenter appliance was archived and powered off. The customer formally cancelled the VMware renewal in writing the same week. The eight ESXi hosts were repurposed as Hyper-V cluster nodes — same hardware, new role, same maintenance contract on the server vendor side.

The decision factors that flip Hyper-V to Azure or Nutanix

Hyper-V was the right answer for this customer. It's not always the right answer. Three signals that shift the destination:

Hyper-V flips to Azure IaaS when

• Hardware refresh and VMware renewal coincide in the same fiscal year
• A meaningful share of workloads (>25%) have variable demand that benefits from auto-scaling
• DR is the actual driver and the secondary datacenter lease is up for renewal
• The customer is already running material Azure workloads with mature governance

Hyper-V flips to Nutanix when

• The environment was already on vSAN-class HCI hardware with no easy path to Storage Spaces Direct
• VDI is a major workload (Citrix or Horizon) and Nutanix's tooling pulls its weight
• The IT team's skills lean more vSphere than Windows Server, and operational continuity beats license savings

Hyper-V stays as the answer when

• The shop is Microsoft-stack with Windows Server Datacenter licensing already in place
• Storage is healthy, depreciated, and not due for refresh
• Workloads are steady-state and on-prem latency-sensitive
• The IT team already runs Failover Clustering, Storage Spaces, or Hyper-V somewhere in the environment

The math, in one table

Common mistakes we see at this size

Skipping the pilot

The customer asked us, twice, whether the four-week pilot was really necessary. The answer is yes. The pilot's cost is a fraction of the cost of a stalled cutover where the IT director is explaining to operations leadership why the plant floor went down on a Tuesday. Every mid-market migration we've ever shortened by skipping the pilot has run long overall.

Over-modernizing during the exit

The temptation to "fix everything" while you're touching the environment is real. Resist it. The renewal-driven exit's job is to get off the burning license. Storage modernization, network re-architecture, AD tier-0 work, Conditional Access — all valid, all important, and all separate projects. Bundle them and the timeline doubles.

Underestimating the Veeam conversation

Backup is the most commonly mis-sequenced piece of mid-market virtualization migrations. The Veeam license conversion math is usually fine, but the procurement cycle is not — start that paperwork in week 1, not week 9.

Forgetting the decom

Three years from now, the customer's documentation should not say "we still have a vCenter appliance running somewhere because nobody was sure what depended on it." Decommissioning is the last 5% of the project, and it's the part that protects the business case. Bake it into the scope from day one.

Related reading

• For the broader vendor landscape, see VMware after Broadcom: Hyper-V, Nutanix, Azure — the destination comparison this engagement was scoped against.
• For the cornerstone Hyper-V vs Azure decision at 500-VM scale, see VMware to Azure vs Hyper-V: 500-VM decision guide.
• If Exchange 2019 EOL is also in your fiscal year, the parallel decision tree is in Exchange 2019 EOL: your last six months.
• Service detail: VMware Exit & Server Modernization.

Sources and further reading

• Microsoft Learn — Hyper-V on Windows Server
• Microsoft Learn — Failover Clustering overview
• Microsoft Learn — Azure Stack HCI
• Broadcom — VMware Cloud Foundation

The 30-second version

A 250-VM mid-market manufacturer turned a $310K Broadcom renewal into a $35K Hyper-V migration with a four-month payback. Two-week assess, two-week design, four-week pilot, four-week sequenced cutover, two-week hypercare. The surprises were predictable in shape: legacy Linux guests, custom NIC drivers, Veeam license conversion, third-party backup integration. None of them blocked the schedule because the pilot found them first.

If your renewal is in the next 12 months and you'd like a senior engineer to scope this for your environment, the project intake form takes about three minutes.

Pro IT NW does not resell VMware, Microsoft, Veeam, or any virtualization platform. The recommendation in any specific engagement is what fits the workloads, not what pays us a margin. Senior-led, labor-only, fixed fee.