I've quoted this project at least twice a month for the last several months, which tells me something. The VMware-to-Hyper-V conversation has moved from "worth exploring someday" to "we need a plan before the next renewal invoice." Broadcom made that decision for a lot of SMBs.
This is not a technical migration problem. It's a renewal deadline problem.
Here's what actually happens on these projects, and what you should know before starting one.
What happened to VMware
Broadcom acquired VMware in late 2023 and has been repricing it ever since. Perpetual licensing is gone. The familiar Standard and Enterprise Plus SKUs are gone for new contracts. If you only need the hypervisor, you're buying a bundle and paying for shelfware.
The 72-core minimum purchase attempt in early 2025 was the clearest signal yet, even after Broadcom walked it back. If you run a 2- or 3-node cluster, you're not their target customer anymore. You're long-tail revenue they're willing to squeeze or lose. I've personally seen massive increases in renewal quotes, and the number varies widely by environment and contract history.
For most SMB environments, the math no longer works.
Why Hyper-V, and why Azure Arc seals it
For the SMB clients I work with — law firms, accounting practices, financial services, consultancies running Microsoft 365 and Entra ID — Hyper-V is almost always the right answer. It's already included in Windows Server (assuming properly licensed Datacenter or appropriately licensed Standard cores for your VM density). The management story is Windows Admin Center, which is browser-based and clean. Azure Site Recovery handles DR. The operational surface is familiar to any Windows admin. If something breaks at 2am, finding someone who can troubleshoot it is not a problem.
There are situations where other platforms make sense. An environment with strong Linux expertise in-house and no Azure footprint, for example, might have good reasons to look at other options. If you're heavily invested in VMware-specific tooling or NSX, this becomes a different conversation. But for Microsoft shops, those situations are the exception. And the real reason I keep recommending Hyper-V over the alternatives has nothing to do with familiarity. It's Azure Arc.
Azure Arc changes the calculus
Most people frame this as a hypervisor replacement decision. I think of it as an on-premises positioning decision, and that framing changes everything.
Azure Arc lets you extend Azure's management plane to your on-premises Hyper-V infrastructure. Your on-prem VMs show up in the Azure portal. You can apply Azure Policy to them, manage them through Defender for Cloud, enforce governance at the same level as your cloud resources, and use the same tooling your team already knows. It turns your Hyper-V cluster into a first-class node in your broader Azure estate rather than an isolated island managed through a separate workflow. (Some feature differences apply compared to native Azure VMs, depending on workload and agent coverage, but for the governance and visibility use cases that matter most to SMBs, it delivers.)
For the professional services firms I work with, this shows up in three ways.
Workload placement becomes an intentional decision. With Arc in the picture, you're not locked into on-prem or cloud as a binary. You can run sensitive client data workloads on your own hardware — where you control the physical location and can speak to that clearly from a compliance standpoint — while spinning up burst compute or dev environments in Azure when it makes more sense economically. The management experience is unified either way.
Security posture stays consistent. Defender for Cloud covers Arc-enrolled machines the same way it covers Azure VMs. Your server security posture, patch compliance, and vulnerability findings are all visible in one place across both environments. For a 30-person law firm with a hybrid footprint, that's a meaningful operational improvement over running two separate monitoring and compliance stories.
It gives you an honest migration path. If some workloads genuinely belong in the cloud — and some of them probably do — Arc gives you the tools to evaluate that clearly and move them on your timeline. You make deliberate decisions about where each workload lives instead of defaulting to wherever it already is.
Azure Backup rounds out the story. When you enroll your Hyper-V hosts into Arc and use Microsoft Azure Backup Server (MABS) or newer Azure Backup approaches depending on environment design, you can vault backups offsite directly to an Azure Recovery Services vault. Short-term retention stays local for fast operational recovery; long-term retention lives in Azure without needing a separate backup cloud provider. For clients already invested in Azure, it's a clean fit.
None of this is available to you if you leave VMware for a platform with no Azure integration. An alternative hypervisor might be a solid piece of software. It is not connected to Azure, and for a firm where the rest of the stack is Microsoft-shaped, that gap is real.
If you're evaluating this, you're in one of three buckets:
- Stay on VMware and absorb the cost
- Migrate to another hypervisor (Hyper-V, Proxmox, others)
- Exit on-prem entirely and move to Azure
This post is about option 2, and why for Microsoft-centric SMBs, Hyper-V combined with Azure Arc is usually the cleanest path.
What the migration actually looks like
I'll be direct: this isn't a weekend project, and anyone who says otherwise hasn't done enough of them. Do not try to move everything in one sprint. That's how outages happen.
Start with inventory. Every VM needs to be documented before anything moves — OS, RAM, vCPU, disk size, network config, application dependencies. Migrations go wrong when people skip this step and find out midway through that one of their VMs has an application that doesn't tolerate the new virtual hardware profile.
Assess the hardware. Most servers running ESXi will run Hyper-V without issues. Confirm CPU virtualization is enabled in BIOS and review your storage configuration. If you're running vSAN, you'll need a plan for shared storage. Windows Storage Spaces Direct is Microsoft's native option for hyperconverged storage, but it requires careful design and isn't always the right fit for smaller environments.
Convert the VMs. Microsoft's MVMC has been deprecated, which still catches people off guard. The current workflow depends on your situation. One important caveat first: if your VMs are running on vSAN, this step gets harder. vSAN's tight coupling between storage and compute means most standard conversion tools don't work against it directly. You'll typically need to storage vMotion the VMs off vSAN onto a traditional VMFS datastore first, then convert from there. Skipping this step is one of the most common reasons VMware-to-Hyper-V migrations stall. Plan for it before you start.
- StarWind V2V Converter for VMDK-to-VHDX conversion, free, reliable, and the tool I reach for first
- Disk2vhd for any physical-to-virtual scenarios that still exist in the environment
- Manual export/import for anything application-sensitive that needs careful handling
General sequence: clean shutdown of the source VM, convert the disk, create a Generation 2 VM in Hyper-V, attach the converted disk, ensure Integration Services are current, validate network and storage, test the application. In that order, every time.
On Integration Services. For modern guest operating systems (Windows Server 2016 and later), Integration Services are built in and kept current via Windows Update. For legacy guests, you'll need to handle it manually. Either way, don't assume it's done — verify it. VMs without current Integration Services will have degraded performance and inconsistent backup behavior, and it's the most common thing I find left undone on migrations that someone else touched.
Plan your networking. VMware's port group and vSwitch model maps conceptually to Hyper-V's virtual switch model, but they don't translate directly. Plan your external, internal, and private switch topology before the first VM moves.
BCDR: get this right before cutover, not after
The first question to answer isn't which backup tool, it's where your environment is going. That determines everything else.
If you're moving to Hyper-V and staying on-prem, Slide is our default BCDR recommendation. It's purpose-built for MSPs, runs on all-NVMe hardware, encrypts everything by default, and was founded by the team that built Datto. It protects physical and virtual workloads via its appliance regardless of the underlying hypervisor, so the migration to Hyper-V doesn't change your protection story.
If you're building a true hybrid environment with Azure Arc in the picture, the calculus shifts. You want a solution that lives in the same management plane as the rest of your infrastructure. Azure Backup via MABS vaults directly to an Azure Recovery Services vault and sits inside the same operational home base as everything else Arc-connected, and for clients already invested in Azure, it removes a vendor from the stack entirely. Zerto is the right answer when you need continuous data protection and near-zero RPO; it's more operationally complex, but for environments where a few hours of data loss is genuinely unacceptable — certain financial services clients, for example — it delivers. It can also replicate VMware VMs to Hyper-V while both environments are live, which compresses the cutover window considerably on larger migrations. Veeam handles Hyper-V natively and integrates cleanly with Azure Local and Arc environments if you're already running it.
The important thing regardless of which tool you land on: reconfigure your backup jobs as part of the migration plan, not after. Backup agents registered to VMware-aware jobs will break at cutover.
What tends to go wrong
A few things I see consistently.
Legacy VMware drivers. Windows Server 2012 VMs converted from VMware sometimes have VMware-specific drivers baked in that cause problems on Hyper-V. Remove VMware Tools before conversion, or immediately after first boot on the new host.
Generation 1 vs. Generation 2. Generation 2 is the right choice for modern workloads — UEFI, secure boot, better performance. VMs with older Windows Server versions or certain Linux kernels may need to stay on Gen 1. Know which is which before you build the target VMs.
Windows activation. VMs activated under a VMware-based deployment may need reactivation against the new virtual hardware profile. Volume licensing via KMS handles this automatically most of the time. Retail or OEM activations sometimes need manual attention.
Backup agent confusion. Already mentioned this, but worth repeating because it causes more post-migration headaches than anything else on this list.
Realistic timeline
For a small environment — 10 to 20 VMs on a 2-node ESXi cluster — expect 4 to 8 weeks from scoping to production cutover. That includes hardware prep, test conversions, a validation window, and the actual go-live. The temptation is always to compress this. Resist it.
Larger environments, or anything with SQL Always On clusters, Exchange remnants, or tightly coupled application dependencies, will take longer. Not because the tools are hard, but because the testing needs to be thorough and you can't rush that part.
Is it worth it?
For most of the clients I'm quoting right now, yes. The migration cost is typically recovered within the first or second year of avoided VMware subscription fees. After that, you're running a hypervisor that's already inside your Windows Server licensing with no separate renewal clock. With Azure Arc, you're positioned to make deliberate decisions about your hybrid footprint going forward rather than just surviving the next Broadcom price increase.
The one situation where I tell people to reconsider: if you have fewer than five VMs and the workloads could realistically move to Azure IaaS or M365-native services, virtualization infrastructure might not be the right answer at that scale anyway.
For everyone else with a real on-prem VM estate and a VMware renewal coming up: if your renewal is within six months, you should already be modeling your exit. Get the quote. Run the numbers. The exit is well-understood at this point and we've done it enough times to do it cleanly.
Want help planning one of these?
If you're looking at a VMware renewal and want a second opinion before you sign anything, or you're ready to start scoping a migration, that's exactly the kind of project we handle. Take a look at Athencia's Professional Services — or if you just want to have a conversation first, a free IT Health Check is a good place to start.
Jeremy Phillips is the founder of Athencia, a Pacific Northwest-rooted managed IT and cybersecurity firm serving SMBs nationwide.
