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

Take a 250-VM mid-market manufacturer on eight hosts, paying roughly $22K/year for vSphere Standard plus support. Price the Broadcom renewal on the cheapest VMware Cloud Foundation bundle that satisfies the 16-core-per-CPU minimum and the quote lands near $310,000 per year — an order-of-magnitude jump created almost entirely by core minimums on hardware that has not changed. That is the arithmetic that puts a 90-day exit on the table.

This post is a worked reference scenario, not an account of one customer — the configuration, the sequence and the arithmetic that recur in mid-market VMware exits, set out so you can check them against your own estate. It exists because the question CIOs actually ask is "is 90 days realistic?" The short answer is yes for a mid-market Microsoft-stack environment with senior engineering and a disciplined sequence. Here is what disciplined looks like.

The reference environment

Before any prescription, the shape of the environment. This is a modelled reference estate, not a specific customer — built from the configuration that recurs most often in mid-market VMware exits, so the phases and the arithmetic below have something concrete to attach to. Check each line against your own inventory; where yours differs, the plan differs.

• 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 split that works: the customer's IT director owns change control, the engineering partner owns the migration itself. A four-week cutover structures into 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 means reversing the network cutover and powering the source VM back on. Expect to use it once or twice across a four-wave cutover, and expect the causes to be mundane: a print server with an undocumented LPR queue dependency, or a SQL VM where a vendor service does not restart cleanly after migration. Both are same-week fixes and both re-cut on the following weekend — which is the entire argument for keeping the source VM resident rather than deleting it the moment the wave looks green.

Decommissioning

By week 14 the VMware datastores are empty, the ESXi hosts are drained, and the vCenter appliance is archived and powered off. Cancel the renewal in writing that same week — a decommission that is not confirmed in writing is how estates end up paying for a hypervisor they no longer run. The hosts are 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

Modelled figures for the reference estate above — not a quote, and not a record of a specific engagement. They are here so the shape of the decision is legible: which lines dominate, which are frequently zero, and which one people forget. Your renewal number is the only input that matters, and it is the one we cannot model for you.

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 Server 2019 EOL: your real migration deadline.
• Same fiscal year, same hardware refresh: if Server 2019 is aging out alongside the VMware exit, see Windows Server 2019 EOS: real upgrade options for 2026.
• 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 Local
• Broadcom — VMware Cloud Foundation

The 30-second version

For a 250-VM mid-market estate, a Broadcom renewal in the low six figures is displaced by a Hyper-V migration in the mid-five figures, with payback inside a couple of quarters. Two-week assess, two-week design, four-week pilot, four-week sequenced cutover, two-week hypercare. The surprises are predictable in shape: legacy Linux guests, custom NIC drivers, Veeam licence conversion, third-party backup integration. None of them need block the schedule, because the pilot is what finds them — which is why the pilot is not the phase to compress.

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.