VMware to Azure Stack HCI Migration

Microsoft Azure Stack HCI has become one of the more frequently considered VMware alternatives in the post-Broadcom landscape, particularly for organisations whose strategic platform direction is already pointed at Azure. The combination of native Azure integration, Microsoft enterprise licensing relationships, and the gradual maturation of the platform has changed the migration calculus for many enterprises. This article is a practical guide to migrating VMware workloads to Azure Stack HCI — what fits, what does not, how to execute, and what the post-migration operating model looks like.

What Azure Stack HCI actually is

Azure Stack HCI is Microsoft's hybrid cloud HCI platform. Architecturally it is Hyper-V plus Storage Spaces Direct (S2D) plus Software-Defined Networking (SDN) plus Windows Admin Center plus the Azure Arc control plane. The product sits between traditional Hyper-V (which is a free hypervisor with no built-in HCI capabilities) and Azure (which is full public cloud). It runs on certified hardware from Dell, Lenovo, HPE, Cisco, Fujitsu, DataON, and several other vendors, with on-premises performance and Azure-style operations.

The defining characteristic is its Azure relationship. Azure Stack HCI is licensed and billed as an Azure service, not as a traditional perpetual product. The cluster registers with Azure, draws management policies from Azure, optionally hosts AKS clusters managed from Azure, and uses Azure Backup, Azure Site Recovery, and Azure Monitor as natural extensions. For organisations whose strategic direction is Azure-first, this integration is a meaningful operational advantage.

When Azure Stack HCI is the right migration target

The strongest fits for Azure Stack HCI migration are:

• Microsoft-centric enterprises — organisations whose application portfolio is dominated by Windows Server, SQL Server, and .NET workloads, and whose existing Microsoft Enterprise Agreement provides leverage on Azure pricing.
• Azure-first cloud strategy — organisations whose strategic platform is Azure, where on-premises HCI capacity is a tactical bridge to the public cloud.
• Edge and branch consolidation — organisations with distributed sites needing small, managed HCI clusters with central control, where the Azure Arc model provides operational simplicity.
• VDI and session-based workloads — particularly where Azure Virtual Desktop integration provides a hybrid VDI architecture.

The weakest fits are:

• Linux-heavy estates — Hyper-V supports Linux but the ecosystem and tooling depth is less than KVM-based hypervisors
• AWS-first cloud strategies — the Azure-centric design works against you if your cloud commitment is elsewhere
• Heavy NSX or vRealize dependence — Microsoft SDN does not match NSX-T's depth, and there is no direct vRealize equivalent
• Specialised guest OS estates — niche operating systems with VMware-specific certifications may not have Hyper-V support

Architecture and sizing

An Azure Stack HCI cluster comprises 2 to 16 nodes (the platform supports up to 16; most deployments are 4–8). Each node runs Azure Stack HCI OS (a hardened Windows Server variant) with S2D providing the distributed storage layer. The cluster connects to Azure for management, monitoring, and billing. Storage is local-only (no FC SAN, no NFS — only S2D); compute is x86 server hardware from the certified list; networking ranges from standard switching to full SDN with software load balancers.

For sizing, a typical migration from VMware uses a similar core count to the source cluster, with modest adjustments. S2D performance is competitive with vSAN; Hyper-V CPU oversubscription tolerance is similar to ESXi for general-purpose workloads. The largest sizing variable is RAM — Windows guests with Hyper-V Integration Services do not consume meaningfully different memory than under ESXi with VMware Tools, but estimates based on VMware allocation rather than actual utilisation routinely overspec by 30 percent or more.

Migration tooling and patterns

Azure Migrate

Microsoft provides Azure Migrate as the primary tool for VMware-to-Azure-Stack-HCI migration. It discovers VMware estates, assesses migration readiness, and performs the actual VM movement using replication-based agents. For most workloads, Azure Migrate handles the conversion automatically — disk format conversion, driver injection (VirtIO and Hyper-V Integration Services), and BIOS/UEFI mapping. Cutover is typically a brief planned outage on the destination side.

Manual conversion patterns

For workloads that resist Azure Migrate (legacy operating systems, applications with strict cutover requirements, VMs with unusual storage configurations), manual conversion using PowerShell and DISM is the fallback. The general pattern is: export the VMDK from VMware, convert to VHDX with qemu-img or vboxmanage, inject VirtIO and Hyper-V Integration Services drivers, import to Hyper-V, and validate networking. Manual conversion is more work per VM but more controllable for sensitive workloads.

Third-party tools

Carbonite, RackWare, Cloudbase Coriolis, and several other migration platforms support VMware-to-Hyper-V/Azure-Stack-HCI migration. For estates above 300 VMs or with strict cutover windows, third-party tools often pay for themselves through automation depth and rollback support.

The Azure Arc operating model

One of the defining features of Azure Stack HCI is its Azure Arc integration. Arc projects on-premises resources into Azure's management plane, providing a single console for hybrid operations. This means policy enforcement, monitoring, RBAC, identity, and update management all flow through Azure. For organisations whose operating model is moving toward cloud-style automation and policy-as-code, this is a meaningful advantage over traditional on-premises virtualisation platforms.

The tradeoff is dependency: Azure Stack HCI requires regular communication with Azure for licence validation, billing, and policy synchronisation. Clusters can run disconnected for up to 30 days; longer disconnection causes the cluster to enter a degraded state. For air-gapped environments, this is a meaningful constraint — Azure Stack HCI is not designed for fully disconnected operation, although Microsoft has been gradually extending disconnected support.

Licensing and economics

Azure Stack HCI is billed at $10 per physical core per month as of 2026 pricing, with that fee covering the Azure Stack HCI OS and the platform services. This is in addition to Windows Server guest licensing (which can be brought from existing Enterprise Agreements through Azure Hybrid Benefit) and the hardware cost. Compared with VCF subscription pricing for an equivalent on-premises footprint, Azure Stack HCI typically lands 20–40 percent cheaper, with the gap widening as VCF list pricing continues to rise.

The economic story improves further when existing Microsoft licences (Windows Server, SQL Server) can be applied via Azure Hybrid Benefit. Organisations with mature Microsoft Enterprise Agreements often find that the migration cost is largely the hardware refresh plus the per-core platform fee, with most of the existing licence stack rolling forward.

What you give up

The honest assessment includes the features Azure Stack HCI does not replicate. Hyper-V's snapshot and clone capabilities are competent but less polished than vSphere's. Hyper-V's live migration handles fewer concurrent migrations than vMotion. Microsoft SDN does not match NSX-T for micro-segmentation depth, distributed firewalling, or service insertion. There is no direct vRealize Automation equivalent — Azure Stack HCI customers typically use Azure Automation, Logic Apps, or third-party automation (Ansible, Terraform with the AzureRM provider) instead.

The most operationally significant gap is the smaller ecosystem of integrations. Hyper-V and Azure Stack HCI are well supported by major enterprise tools (Veeam, Commvault, Datadog, Splunk, Terraform), but the breadth of certified integrations is narrower than VMware's. Validate ecosystem fit for your specific stack before committing.

The Broadcom audit angle

For organisations under Broadcom audit pressure, an Azure Stack HCI migration provides credible exit leverage. Unlike Proxmox or Nutanix, the migration target is a major commercial platform with predictable support, broad partner ecosystem, and a relationship Microsoft is incentivised to make successful — making the threat of migration more credible to Broadcom commercial teams.

The most effective negotiation pattern is to begin Azure Stack HCI deployment for new workloads and refresh footprint first, while VMware audit and renewal discussions are active. The visible deployment activity demonstrates that the migration threat is real, which materially shifts settlement positions. Customers who pair active Azure Stack HCI rollout with independent audit defence consistently negotiate better outcomes than customers who attempt to manage Broadcom alone.

Operational considerations

Three operational areas need explicit planning during migration:

Backup and DR — Veeam, Commvault, and Azure Backup all support Azure Stack HCI; pick one and standardise. Avoid the trap of running multiple backup products across hypervisors during the migration period — operational complexity multiplies quickly. For DR, Azure Site Recovery provides a coherent path to either a paired Azure Stack HCI site or to Azure as a recovery target.

Identity and access — Azure Stack HCI integrates natively with Azure AD/Entra ID and Active Directory. The operational practice is typically: cluster authenticates through Azure, VM-level RBAC through Active Directory, sensitive operations gated through Azure Privileged Identity Management. Plan the identity model explicitly before cutover; ad-hoc RBAC accumulates technical debt quickly.

Monitoring — Azure Monitor, Azure Arc-enabled insights, and the native Windows Admin Center cover most monitoring needs. If you have existing Datadog, Splunk, or SCOM deployments, they continue to work, but the native Azure tooling is materially better-integrated and typically replaces older monitoring stacks within 12–18 months of migration.

Migration timeline

A realistic enterprise migration timeline from VMware to Azure Stack HCI looks like:

Months 0–2: Architecture decisions, hardware selection, Azure subscription and identity setup, lab cluster build.

Months 2–5: Pilot cluster in production, migration of non-production workloads, runbook development, team training.

Months 5–10: Production cluster build-out, migration of tier-2 workloads, refinement of DR and backup.

Months 10–18: Tier-1 migration, ESXi decommissioning, VMware footprint renegotiation with Broadcom for residual estate.

Frequently asked questions

Does Azure Stack HCI require continuous Azure connectivity?

It requires regular connectivity — typically every few hours — but tolerates short outages without issue. Extended disconnection (beyond 30 days as of 2026) causes the cluster to enter a limited-functionality state. For air-gapped environments, Microsoft has been gradually extending disconnected support but the platform is not fundamentally designed for fully air-gapped operation.

Can we keep our existing storage arrays?

No — Azure Stack HCI is HCI by design, using Storage Spaces Direct on local disks. There is no supported FC SAN or iSCSI connection for Azure Stack HCI storage. If retaining existing SAN is important, traditional Hyper-V on Windows Server is a different product that does support SAN; Azure Stack HCI is a different architectural decision.

How does Azure Stack HCI compare to Nutanix AHV?

Both are HCI platforms with mature hypervisors and integrated storage. AHV's ecosystem is broader within the on-premises virtualisation domain; Azure Stack HCI's integration with Azure is deeper. Choose based on cloud strategy: Azure-first organisations are better served by Azure Stack HCI; multi-cloud or AWS-leaning organisations are better served by AHV.

What about Hyper-V on standalone Windows Server — is that the same thing?

No. Hyper-V on standalone Windows Server is a free hypervisor without HCI capabilities, without Azure Arc integration, and without the platform services Azure Stack HCI provides. The two products share the underlying hypervisor but are operationally different platforms. Migration target evaluation should be clear about which product is in scope.

Will Azure Stack HCI continue to evolve or is it being deprecated?

Microsoft has invested heavily in the platform across 2023–2026, with the rebrand to Azure Local in some markets reflecting the strategic emphasis. The product is on an active investment track and is positioned as Microsoft's strategic on-premises platform. Treat it as a stable target for multi-year migration planning.