VMware Migration: Where to Start

Every VMware shop I talk to eventually asks the same question: where do we even start? Not the strategy deck version, the actual first Tuesday morning version. For episode 5 of the podcast, I sat down with Jaromir Kaspar, a Microsoft MVP who spent nine and a half years at Microsoft as a Premier Field Engineer working on Hyper-V, and now runs the Global Engineering Outreach Specialist group at Dell. He’s also the author of MSLab, a tool built for exactly this question.

The pattern he’s seeing

Jaromir isn’t a VMware guy. He doesn’t need to be. He’s hearing the same requests from customers over and over: is this VMware feature available in Hyper-V, we’re VM admins, where do we start, we need to understand Azure Stack HCI fast. The Broadcom pricing shock pushed people from “someday” to “this quarter,” and most of them are starting from zero.

Start with a lab, not a design doc

His first answer isn’t a whitepaper. It’s Dell’s GEOS GitHub repo: hands-on labs for deploying Azure Stack HCI, step by step, including admin guides for things like OS deployment with Microsoft Deployment Toolkit. Search “Dell GEOS GitHub” and you’ll find it.

His second answer is MSLab, the project he built and still maintains. It’s a zip file with a handful of PowerShell scripts. You right-click and run them. In Windows 11 you need to go into “more options” to get the “run with PowerShell” option, but that’s the whole learning curve. The first script sets up folders and pulls some DSC dependencies. The second asks for a Windows Server ISO (2016 through 2025) and builds a base parent disk. Then a deploy script spins up a small lab: a domain controller and a couple of domain-joined VMs, ready to explore.

Once you’re comfortable, you go one level deeper: edit the lab config to define your own list of VMs, then work through the scenario script section by section. It’s commented, so you’re not guessing at what each block does.

This isn’t just a toy

The part that stuck with me: a Dell customer built their production VM provisioning on top of MSLab. They wired it up with an orchestration tool (Universal Dashboard) to give users a self-service portal for T-shirt-sized SQL VMs. Pick a size, the workflow picks a host, applies the right QoS, and creates the VM. Jaromir pointed out there’s no off-the-shelf product that does exactly this. System Center Virtual Machine Manager gets close but still needs a self-service layer bolted on. PowerShell plus a lightweight orchestrator filled the gap.

You need less networking than you think

A common worry is software defined networking. Jaromir’s take: most mid-size shops don’t need it. A company running 5 to 10 VLANs can run Hyper-V just fine with VLANs and PVLANs for isolation. The Hyper-V switch handles a lot without SDN at all.

He’s also not sold on SDN Express yet. It provisions self-signed certificates that expire in one or two years, a ticking clock nobody wants to manage. Using your own certificate authority instead means exportable certs and a consistent endpoint across every node, which is its own headache. He wants Microsoft to turn this into more of a managed service before he recommends it broadly.

Azure Stack HCI is becoming a product, not a hypervisor

The bigger shift Jaromir described: Azure Stack HCI 23H2 reuses the Azure Stack Hub codebase and merges it with the on-premises failover cluster model. You still have the low-level access system admins expect (failover cluster manager, Hyper-V manager, storage pools) but the deployment and updates are now consistent, pushed from the Azure portal through a supplemental package covering firmware, drivers, and WDAC policy. For compliance, that means one place to check that everything’s green, and that answer is provable to a security team on demand.

The Resource Bridge in 23H2 lets you create on-premises VMs using ARM templates, the same automation model as Azure itself. It’s not a finished hybrid experience yet, but it’s a real step toward managing on-prem infrastructure the same way you manage a cloud subscription.

His advice if you’re stuck

Jaromir’s closing advice for any VMware shop staring at this decision:

Check if anyone on your team already runs Microsoft failover clusters. If so, Azure Stack HCI is a Hyper-V cluster on Windows Server, and that skill set already transfers.
Your VMware admins likely already know PowerShell, since it’s needed for VMware automation too. Azure Stack HCI troubleshooting runs through PowerShell on Windows Server, so that’s not new territory either.
Figure out which workloads just need to run as VMs, no private cloud features required. Those are your easiest first moves.
If you’re on Citrix, look at Azure Virtual Desktop on premises as a migration target.
If you have Software Assurance, check your Azure Hybrid Benefit for Azure Stack HCI. Azure Arc connectivity and portal control are free under it. That’s real money back against the VMware invoice that started this whole conversation.

The community piece

Jaromir also pointed to the Azure Stack HCI Slack channel, around 2,500 people deep with a lot of Microsoft-world experience beyond just Hyper-V. His experience with Reddit and general search results for Hyper-V questions has been weak. A live community of people who’ve run this at scale is a better resource than a forum thread from three years ago.

This is part of the VMware to Microsoft podcast series. Subscribe for more of these.