If you can build it in a POC, you can build it in production.

The previous three posts gave you the components: host deployment (Post 5), storage integration (Post 6), and VM migration (Post 7). This post ties them all together into a single, cohesive deployment that you can complete in one afternoon. No hand-waving. No “left as an exercise for the reader.” A real cluster, with real storage, running real VMs.

You’ve built the case, validated the hardware, configured the hosts, and connected the storage. Now comes the part everyone’s been waiting for (and dreading): actually moving the virtual machines.

VM migration from VMware to Hyper-V is not a single-click operation. Disk formats differ (VMDK vs. VHDX). Virtual hardware differs (VMware paravirtual drivers vs. Hyper-V synthetic drivers). Guest integration tools differ (VMware Tools vs. Hyper-V Integration Services). But the tooling has improved dramatically, and in 2026, you have more options than ever—including a free, Microsoft-supported tool that performs online migration with minimal downtime.

Not everything needs to be hyper-converged.

There’s a strong narrative in the infrastructure world that three-tier architecture—separate compute, network, and storage tiers—is outdated. That hyper-converged infrastructure (HCI) is the only path forward. That separating your storage from your compute is a legacy pattern.

That narrative is incomplete.

Three-tier architecture remains the right answer for many workloads and many organizations. If you have an existing SAN investment, if your workloads require deterministic storage performance, if you need storage-level replication for disaster recovery, or if your team has deep storage operations expertise—three-tier isn’t just viable, it’s often superior.

This is where the keyboards come out.

Posts 1 through 4 made the business case, dismantled the myths, and confirmed your hardware is ready. Now it’s time to build something. In this fifth post of the Hyper-V Renaissance series, we’re going to take a bare-metal server—or a freshly wiped former VMware host—and turn it into a production-ready Hyper-V node that’s fully validated for cluster membership.

Every step is scripted. Every configuration is documented. If you can’t reproduce it with PowerShell, it doesn’t belong in a production deployment.

The servers sitting in your datacenter right now, the Dell PowerEdges, the HPE ProLiants, and the Lenovo ThinkSystems, were designed to run hypervisors, not a specific hypervisor. Any hypervisor.

This might seem obvious, but it’s worth stating clearly: enterprise server hardware is hypervisor-agnostic. The same CPUs, memory, storage controllers, and network adapters that run ESXi today will run Hyper-V tomorrow. You’re not abandoning hardware investments when you change virtualization platforms; you’re simply loading different software.

“Hyper-V? That’s legacy tech. It can’t compete with VMware. ‘Hyper-V is dead,’ isn’t it?”

I’ve heard this sentiment more times than I can count. In hallway conversations at conferences, in architecture review meetings, in vendor comparison spreadsheets filled with red X marks in the Hyper-V column. For years, this perception has been the default position—sometimes justified, often not.

In this third post of the Hyper-V Renaissance series, we’re going to dismantle this myth systematically. Not with marketing claims, but with verified specifications, feature-by-feature comparisons, and honest assessments of where Hyper-V excels and where it still trails.

I’m in the middle of writing The Hyper-V Renaissance—an 18-part series making the case for traditional Hyper-V with Windows Server 2025 as a serious virtualization platform. It’s been consuming most of my writing time, and I’ve been heads-down on TCO comparisons, cluster builds, and PowerShell automation.

But sometimes you stumble across something that deserves its own post, and you have to step away from the main project for a minute.

There’s a new community tool for Azure Local that’s worth your attention. It’s called Odin—the “Optimal Deployment and Infrastructure Navigator”—and it’s hosted right on Microsoft’s GitHub. Before you get too excited, let me set expectations: this tool comes with a clear disclaimer that it’s provided “as-is, without Microsoft support.” It’s experimental.

The invoice arrived, and the meeting quickly followed.

For nearly two decades, the “cost of virtualization” was a line item we grumbled about but accepted. It was the “VMware Tax,” the price of admission for a stable, feature-rich datacenter. But in the wake of the Broadcom acquisition and the subsequent licensing overhaul, that tax has, for many organizations, turned into a ransom.

This isn’t just about price hikes. It’s about a fundamental shift in how infrastructure is consumed. We are forcibly moving from a world of perpetual licenses and optional support to a world of mandatory subscriptions and bundled software stacks.

Introduction

A Perfect Storm Creates Opportunity

If you’ve been watching the virtualization market over the past eighteen months, you’ve witnessed something extraordinary: a once-stable industry thrown into chaos by a single acquisition. When Broadcom completed its $69 billion purchase of VMware in November 2023, few anticipated how dramatically—and rapidly—the landscape would shift. What followed wasn’t just a pricing adjustment; it was a fundamental restructuring that has sent shockwaves through data centers worldwide.

From VMware vSphere to Azure Local: What Changes and Where to Click

The industry shift away from VMware has accelerated dramatically. Organizations worldwide are evaluating alternatives, driven by licensing changes, acquisition uncertainty, and evolving business needs. For many enterprises, this transition represents both a significant operational challenge and a strategic opportunity to modernize their virtualization infrastructure.

This blog addresses the practical reality facing infrastructure teams: when organizational decisions mandate a platform change, success depends on understanding exactly how daily operations translate to the new environment. Rather than debating platform merits, this analysis provides the detailed operational mapping that VMware administrators need to maintain service levels during transition.