Migration Paths and Ecosystems: What Moves You Off VMware

If you’re leaving VMware, the hypervisor is the easy part. The hard part is everything wired around it: backup, monitoring, replication, ITSM tickets, storage. On episode 4 of VMware to Microsoft, I talked with Ben Thomas, a Microsoft MVP and Veeam Vanguard based in New Zealand, about the migration paths off VMware and the tool ecosystem that has to come with each one.

Ben works for Datacom, a service provider across Australia and New Zealand, and he’s spent 12 years touching pretty much every hypervisor platform there is. He sees this from both sides: customers running their own infrastructure and customers sitting on his platforms.

The paths people are taking

Ben laid out the realistic destinations for organizations leaving VMware:

Proxmox. Getting a surge of interest it never had before, mostly outside its old home turf of home labs and niche shops. Ben’s advice: judge it on the maturity of the ecosystem around it, not just the hypervisor itself. Can you back it up? Replicate it? Monitor it? That’s the real question, not “can it run a VM.”
Azure Stack HCI. The packaged, opinionated option if you liked what VMware Cloud Foundation or VxRail gave you. Similar idea: Microsoft bundles the moving parts for you.
Windows Server with Hyper-V. Good if you’re keeping existing SAN hardware. Ben’s specific caution here: check the hardware compatibility list before you jump to a new Windows Server version on old hardware. Windows Server 2019 is still a fine, supported choice if your gear is aging.
Azure VMware Solution (AVS). The one Ben says gets skipped over. It runs your existing VMware stack on Azure, so your team keeps using the tools and skills they already have. There was a limited-time offer at recording: 20% off for five years plus up to $120,000 in Azure credit. AVS buys you time to decide the next step without a forced re-skill.

None of these is universally right. If you need to stay on premises for latency, performance, or data residency, AVS is off the table. That’s fine. The point is knowing which lane you’re in before you pick a tool.

How the VMs move

We also got into the mechanics, because “migrate to a new hypervisor” hides a lot of real work. Ben walked through the options in order of effort:

Rebuild on the new platform. Stand up net-new VMs and move the app and data over instead of the VM itself. Best outcome, no legacy VMware tools or drivers riding along. Also the most work. Ben said he’s never seen a customer pull it off in full.

Native migration tooling. Going to Hyper-V and already run System Center Virtual Machine Manager? It connects directly to vCenter and migrates VMs for you, no extra tool to buy. Azure Migrate is also adding a preview capability for VMware-to-Azure-Stack-HCI moves on premises, building on the VMware-to-Azure path that already exists.

Backup-based cutover. Most backup vendors, Veeam included, can do hypervisor-independent restores. Run your normal backup jobs, take a final backup, shut down the source, instant-recover onto Hyper-V, then live-migrate off backup storage onto production storage. The source VM never gets touched until you’re ready, and if you’re already testing backups regularly, this doubles as that test.

Agent-based replication. Tools like Carbonite Move (formerly Double-Take) install an agent on source and destination and clone the machine live. Once they’re in sync, you cut over: source shuts down, destination reboots, done.

Every path shares the same planning work: know your app dependencies, group machines into migration waves, and settle your outage window and budget before you start.

Is Hyper-V enterprise ready

This is the objection Ben hears constantly, and he pushed back on it directly. “Enterprise ready” is relative. What counts as enterprise in New Zealand is small business in the US. The question that matters isn’t scale, it’s ecosystem: does your monitoring tool integrate with Hyper-V, does your storage vendor support it, does your ITSM tool route tickets off it. Ben’s answer across the board was yes. Hyper-V has been shipping since 2008 and now runs Azure itself, which is about as large an enterprise workload as exists.

The licensing math

If you’re already running Windows Server Datacenter to license your VMware VMs, that Hyper-V capability is something you’ve already paid for. It’s a switch flip, not a new purchase. Ben’s framing: you’re not just trimming a license line, you’re removing an entire cost category, the VMware licensing sitting on top of Windows Server you already own.

He also cleared up a piece of FUD I hear a lot: Hyper-V Server, the free standalone SKU, went away after 2019. Hyper-V didn’t. It’s a role inside Windows Server, and if you don’t enable the other roles, nothing else runs. Only running Linux VMs? License the host with Windows Server Standard and get unlimited Linux VMs with no Hyper-V tax at all.

Storage Spaces Direct gets a real look

Storage is the piece people forget is part of the migration. Ben’s been running Storage Spaces Direct since 2015, and he made a comparison worth repeating: VMware’s newer vSAN Express Storage Architecture, with its move away from disk groups to a flat pool of disks, now looks a lot like how S2D has worked for years. On disk failure, S2D rebuilds the missing blocks into spare capacity within minutes, so the window where you’re exposed to a second failure is short.

Where this leaves you

Ben’s closing advice was simple: don’t rule out Microsoft because of an experience from over a decade ago. If you’re evaluating a move, the tool exists for almost every path, whether that’s rebuild, native migration tooling, backup-based cutover, or agent replication. The harder work is matching the path to your actual constraints: hardware age, staff skills, outage tolerance, and what you’re already licensed for.

This is part of the VMware to Microsoft podcast series.

Subscribe for more of these.