Azure Migrate for VMware to Azure Stack HCI
Back in June I wrote about migrating VMs to Azure Stack HCI 23H2 , focusing on the Hyper-V to Azure Stack HCI path using Azure Migrate. At the time, the VMware to Azure Stack HCI migration path was in private preview, and I noted that while you might think that VMware migration was the more critical capability, the Hyper-V path was arguably more important because of its utility as a conversion mechanism for workloads coming from any source platform.
Well, the VMware to Azure Stack HCI path has now moved into public preview, and given the Broadcom effect that I wrote about last month, the timing couldn’t be better. Let’s dig in.
Why This Matters Now
The context here is everything. With VMware licensing changes driving a wave of infrastructure re-evaluation, the ability to migrate directly from VMware to Azure Stack HCI without going through an intermediate step is a significant capability. Previously, if you wanted to move a VMware VM to Azure Stack HCI, you’d typically need to use a third party tool to convert the VM to Hyper-V format, then use the Hyper-V to Azure Stack HCI conversion path I documented previously. Not impossible, but certainly not elegant.
Azure Migrate for VMware to Azure Stack HCI provides a direct path. Discover your VMware VMs, replicate them, and migrate them as proper Azure Stack HCI VMs. No intermediate Hyper-V step, no third party conversion tools, and critically, the migrated VMs land as full Azure Stack HCI VMs with all of the management, policy, and feature benefits that entails.
The Architecture
The architecture follows a similar pattern to the Hyper-V migration path. You deploy a source appliance into your VMware environment which handles discovery and replication, and a target appliance in your Azure Stack HCI cluster which handles the receiving end. The Azure Migrate project in the Azure portal orchestrates the whole thing.
The key differences from the Hyper-V path are in how the source appliance interacts with the VMware environment. It connects to your vCenter Server to discover VMs, and uses the VMware vSphere APIs to handle the replication of VM data. From there, the flow is conceptually similar: initial replication, ongoing delta sync, and then a cutover when you’re ready.
One thing worth noting is that the source appliance for VMware discovery needs connectivity to both vCenter and ESXi hosts. This is important to plan for from a network perspective, especially in environments where management and workload networks are segregated.
What Works Today
As a public preview, there are some boundaries to be aware of. The feature supports migration of VMware VMs running on vSphere 6.7 and later, which covers the vast majority of production environments I’ve seen. Both Windows and Linux guest operating systems are supported, and the migration handles the necessary driver and boot configuration changes to transition from a VMware paravirtualised environment to a Hyper-V based one.
The replication mechanism supports both initial full replication and ongoing delta synchronisation, which means you can minimise the cutover window. For workloads where downtime needs to be measured in minutes rather than hours, this is critical.
Planning Considerations
If you’re planning a VMware to Azure Stack HCI migration, there are a few things I’d suggest thinking through beyond the migration tooling itself.
First, networking. Your Azure Stack HCI network topology is almost certainly different from your VMware environment. VLANs, subnets, firewall rules, load balancers, all of this needs to be mapped out before you start moving workloads. Azure Migrate handles the VM data move, but it doesn’t magically reconfigure your network.
Second, storage. Understand where your VMs will land in terms of storage paths and cluster shared volumes. If you’re running Dell AX nodes, work with your Dell support team to ensure your storage configuration is optimised for the workloads you’re bringing across.
Third, application dependencies. This applies to any migration exercise, but it bears repeating. Understand which VMs talk to which other VMs, which services depend on which other services, and plan your migration waves accordingly. Moving a web server without its database server is going to cause problems.
Fourth, and this is something I keep coming back to, make sure you understand the different VM types in the Azure Stack HCI world. The whole point of using Azure Migrate rather than a third party tool is to ensure your VMs land as proper Azure Stack HCI VMs. If you’re going to the effort of migrating, do it properly.
The Bigger Picture
What excites me about this capability is not just the migration itself, it’s what it enables strategically. Organisations now have a supported, Microsoft-provided path to move from VMware to Azure Stack HCI. This removes one of the biggest practical barriers to evaluation. You can stand up an Azure Stack HCI cluster, migrate a subset of workloads, validate the experience, and then make an informed decision about broader adoption. The reversibility of that decision is important too. If Azure Stack HCI doesn’t meet your needs, you can migrate back.
I mentioned in my previous post that the Hyper-V migration path doubles as a conversion path for workloads migrated from any source using third party tools. That still holds true, and in practice I expect many migration projects will use a combination of both paths. Direct VMware to Azure Stack HCI for the bulk of the VMware estate, and the Hyper-V conversion path for workloads coming from other platforms like Nutanix AHV or bare metal.
It’s still in preview, so expect some rough edges and limitations that will be ironed out before GA. But the direction is clear, and the timing is spot on. If you’re evaluating Azure Stack HCI as a VMware alternative, this is a capability you should be testing now.