How to Migrate VMware to Azure: A Practical Guide

If you’re running VMware infrastructure and you’ve been watching the fallout from Broadcom’s acquisition, you’re not alone.

Gartner forecasts that around 35% of VMware workloads will migrate to alternative platforms by 2028, and while the initial panic has settled, organisations across the UK are steadily working through their exit plans. The bundled subscriptions, per-core licensing changes, and eye-watering price increases have turned “should we leave VMware?” from a hypothetical into an active line item on IT roadmaps everywhere.

Thankfully, Microsoft has made the path from VMware to Azure a lot smoother over the past few years. You might be looking at Azure Local (formerly Azure Stack HCI) as an on-prem replacement, or Azure VMware Solution for a like-for-like lift into the cloud. You might even want a full migration to Azure IaaS. Whichever way, there’s a clear route for each.

In this guide, we’ll walk through why organisations are making the move and which migration paths are available. You’ll discover the step-by-step process, the tools you’ll need, and the pitfalls to avoid along the way.

The most obvious driver is cost.

Broadcom ended perpetual licensing and moved VMware to bundled subscriptions through VMware Cloud Foundation. This forced many customers into large suites they don’t fully need. The shift from per-CPU to per-core metrics has hit hard on modern high-core servers. Many mid-market orgs report price jumps of several times their previous spend.

But cost isn’t the whole story. There are various reasons why Azure, in particular, is a compelling destination:

• Licensing simplicity. If you’re already a Microsoft shop (and most UK businesses are), moving to Hyper-V-based infrastructure (through Azure Local or Azure IaaS) means you can take advantage of existing Windows Server and SQL Server licences through Azure Hybrid Benefit. That’s a big saving that compounds over time.
• Unified management. Azure Arc lets you manage on-premises, edge, and cloud resources from a single pane of glass. Instead of juggling vCenter, vSAN, and NSX, you get one consistent management layer across your entire estate.
• A clear modernisation path. Migrating to Azure doesn’t just mean swapping one hypervisor for another. It opens the door to Azure-native services like Azure Virtual Desktop, Azure SQL, and Azure Kubernetes Service. You can modernise at your own pace rather than doing everything at once.
• Ecosystem integration. Tight integration with Microsoft 365, Entra ID (formerly Azure AD), Microsoft Defender, and the broader Microsoft security stack means less friction across your IT environment.

If you’re weighing up all your options beyond Azure, our guide to the best real-world VMware alternatives covers the full landscape, including Nutanix, Proxmox, and others.

Azure Local is Microsoft’s on-prem hyperconverged infrastructure platform. If you’re used to VMware’s stack, think of it as the Microsoft equivalent: compute, storage, and networking in a single cluster, but managed through Azure Arc rather than vCenter.

Here’s a brief look at the key differences:

The biggest shift is the management model. With Azure Local, your on-prem infrastructure is managed as an extension of Azure itself. VMs show up in the Azure portal, and you can apply Azure policies. Your team uses the same tools whether they’re managing on-prem or cloud workloads. For firms already invested in the Microsoft ecosystem, this can simplify operations a fair bit.

It’s also worth noting that Azure Local vs Hyper-V is a common discussion point.

Standard Hyper-V is still a solid option for straightforward virtualisation, but Azure Local adds the hyper-converged storage layer. You also get Azure management integration and the ability to run Azure services on-premises. For companies replacing VMware’s full stack, Azure Local is generally the closer equivalent.

In short: Azure Local gives you a modern, cloud-connected alternative to VMware without losing the control of on-premises infrastructure.

Before diving into the how, it’s worth looking at the three main routes for migrating VMware VMs to Azure. Each suits different situations, and it’s not unusual for firms to use more than one.

Azure Local: the on-prem replacement

This is the path for organisations that need to keep workloads on-premises, whether for latency, data sovereignty, compliance, or simply because it suits their operating model. You’re essentially replacing VMware’s hypervisor stack with Microsoft’s, while gaining cloud management through Azure Arc.

Best for: organisations with on-prem requirements, edge locations, regulated industries, or those who want a like-for-like infrastructure replacement.

Azure VMware Solution (AVS): lift and shift to the cloud

Azure VMware Solution runs the full VMware stack (vSphere, vSAN, NSX, HCX) on dedicated hardware in Azure data centres. Your VMware admins use the same tools they already know, and you can migrate VMs using VMware HCX with minimal changes.

That said, AVS isn’t cheap and it isn’t always the right call. Our guide on when Azure VMware Solution makes sense (and when it doesn’t) goes into detail on this.

Best for: organisations under pressure to exit a data centre quickly or those with complex VMware environments that’d be costly to refactor. Or teams that need a fast path to the cloud while they plan longer-term modernisation.

Azure IaaS: full cloud migration

This means converting VMware VMs into Azure Virtual Machines running on Hyper-V. It’s a more involved migration than AVS, since you’re changing hypervisor, but it gives you access to the full range of Azure services and typically offers better long-term cost efficiency.

(For a broader look at cloud migration strategy, our on-premise to cloud migration guide covers the planning process in detail.)

Best for: organisations ready to move to the cloud, those looking to modernise applications over time, or workloads where the flexibility and scale of public cloud makes sense.

Whether you’re heading to Azure Local or Azure IaaS, the migration process follows a similar structure. Here’s a practical walkthrough of the key stages.

1. Assess your environment

This is where most migrations either succeed or stumble. Before you move anything, you need a clear picture of what you’re working with.

Start by inventorying your VMware VMs, their configurations, resource usage, and dependencies. Azure Migrate is the go-to tool here. It connects to your vCenter Server, discovers your VMs, and collects performance data over time.

Running it for at least a couple of weeks gives you realistic utilisation figures rather than just what’s been allocated (and it’s common to find that VMware environments are significantly over-provisioned).

The key things you want to capture during assessment are:

• VM inventory: OS versions, disk sizes, CPU and memory allocation
• Actual resource utilisation (not just allocated resources)
• Application dependencies and communication patterns
• Network configuration: VLANs, firewall rules, static IPs
• Any VMware-specific features in use (DRS, vSAN policies, NSX micro-segmentation)
• Licensing: Windows Server, SQL Server, and any third-party software

The assessment output will tell you which VMs are ready to migrate as-is, which need adjustments, and what the estimated Azure costs will look like.

2. Plan your target architecture

With your assessment data in hand, you can design your landing zone. This looks different depending on your destination.

For Azure Local: you’ll need to size your cluster hardware (nodes, storage, networking), plan your Azure Arc connectivity, and design your logical networks and storage paths. Microsoft maintains a catalogue of validated hardware from vendors like Dell, Lenovo, and HPE.

For Azure IaaS: you’ll be choosing VM sizes, storage tiers (managed disks, premium vs standard SSD), virtual networks, and resource groups. Azure Migrate’s assessment tools can recommend VM sizes based on your actual performance data. This helps avoid the classic mistake of simply matching your on-prem specs one-for-one and ending up with an inflated Azure bill.

In both cases, think about networking early. How will your migrated VMs communicate with the rest of your estate during and after migration? Do you need ExpressRoute or VPN connectivity? What about DNS and Active Directory?

3. Prepare your target environment

For Azure Local: deploy and configure your Azure Local cluster and register it with Azure Arc. Then set up the Azure Migrate target appliance on the cluster. You’ll also need to configure logical networks and storage paths for the incoming VMs.

For Azure IaaS: set up your Azure subscription, virtual networks, storage accounts, and any required connectivity (VPN gateway or ExpressRoute). Create your Azure Migrate project in the portal if you haven’t already.

This is also the time to think about governance: resource naming conventions, tagging strategy, role-based access control (RBAC), and Azure Policy. Getting this right before migration saves a lot of tidying up afterwards.

4. Migrate your VMs

This is where the actual migration happens, and you have a few options depending on your tooling (covered in detail in the next section).

The general flow using Azure Migrate looks like this:

• Enable replication for your VMs. Azure Migrate begins copying disk data from your VMware environment to the target (Azure Local or Azure managed disks). Your production VMs continue running during this phase.
• Run test migrations in an isolated network. This lets you verify that VMs boot correctly, applications work, and network connectivity is as expected, all without affecting production.
• Perform the cutover. Once you’re confident, you trigger the final migration. There’s a brief period of downtime while the last changes sync and the VM switches over to the new platform.

It’s best practice to migrate in waves rather than all at once. Group VMs by application and dependency, and start with low-risk workloads (dev and test environments are ideal). Build confidence before tackling production.

5. Validate and optimise

After each migration wave, take the time to validate thoroughly:

• Confirm your VMs are running and accessible
• Test application functionality end-to-end
• Check network connectivity and DNS resolution
• Verify backup and monitoring are in place
• Review performance against your baseline data

Once you’re satisfied, decommission the source VMware VMs and clean up any temporary migration infrastructure.

This is also a good time to right-size your Azure resources based on actual post-migration performance. Many organisations find they can reduce VM sizes further once workloads are running in Azure, which directly reduces costs.

For ongoing management and cost control, our guide to Azure cost management covers the tools and strategies that make a real difference.

Having the right tools makes all the difference. Here’s what’s available for migrating VMware VMs to Azure.

Azure Migrate

This is Microsoft’s primary migration platform and the natural starting point for most VMware-to-Azure projects. It handles discovery, assessment, and migration from a single hub in the Azure portal.

For VMware environments, Azure Migrate supports two approaches:

• Agentless migration is the simpler option. You deploy a lightweight appliance as a VM in your vCenter environment (using an OVA template or PowerShell script). The appliance discovers your VMs and handles replication without needing to install anything on the guest operating systems. It supports vCenter Server versions 6.5 through 8.0.
• Agent-based migration gives you more control and supports a broader range of operating systems and disk configurations. You deploy a replication appliance and install the Mobility Service agent on each VM you want to migrate. This approach is better for complex environments or VMs with specific requirements that agentless can’t handle.

For migrations to Azure Local specifically, Azure Migrate uses a two-appliance model:

a source appliance in VMware and a target appliance/component on Azure Local, both registered to an Azure Migrate project. VM data flows directly from the on‑premises VMware hosts to Azure Local, so the data path stays local.

The associated Azure resources are used only for orchestration and metadata. VM disks and payload data aren’t stored in Azure Storage. Instead, only metadata and replication state are stored in Azure — a clear win for data sovereignty and compliance.

Installing the Azure Migrate appliance on VMware

Setting up the Azure Migrate appliance in your VMware environment is straightforward. From your Azure Migrate project in the portal, download the OVA template, import it into vCenter, and power it on. The appliance configuration manager launches automatically, and you’ll register it with your Azure Migrate project using the generated key.

The appliance needs around 8 vCPUs and 16GB of RAM, plus outbound connectivity on port 443 to Azure. Once it’s running, it’ll discover your VMs and begin collecting performance data. You can connect a single appliance to up to 10 vCenter Servers.

If you can’t deploy an OVA (for example, due to security policies), you can set up the appliance on any Windows Server 2022 machine using the PowerShell installer script instead.

VMware HCX (for Azure VMware Solution)

If you’re migrating to AVS rather than Azure Local or IaaS, VMware HCX is your tool of choice. It’s included with AVS and handles bulk migration, live vMotion, and network extension between your on-premises VMware environment and AVS. Since you’re staying on the VMware stack, there’s no hypervisor conversion involved.

Third-party migration tools

Several third-party tools also support VMware-to-Azure migrations:

• Veeam can perform cross-platform restores of VMware backups directly to Azure, which is handy if you already use Veeam for backup.
• Carbonite Migrate and Zerto offer real-time replication with low RPOs, which suits environments with strict recovery requirements.
• SCVMM (System Center Virtual Machine Manager) can convert VMware VMs to Hyper-V format, useful if you’re moving to Azure Local via an intermediate Hyper-V step. Our guide on migrating from VMware to Hyper-V covers this process in more detail.

Migrating VMware VMs without vCenter

If you don’t have vCenter Server (perhaps you’re running standalone ESXi hosts), Azure Migrate’s standard agentless approach won’t work, as it needs vCenter for discovery and replication. The workaround is to use Azure Migrate’s agent-based method and treat your VMware VMs as physical servers. You deploy the replication appliance, install the Mobility Service agent on each VM, and migrate them that way. It’s a bit more hands-on, but it gets the job done.

As a last resort, you can manually export and convert disks, but this involves more downtime and effort.

Every VMware migration has its surprises. Here are the most common pitfalls and how to avoid them.

VMware features without direct equivalents in Azure

If you’re heavily using VMware-specific features like DRS (Distributed Resource Scheduler), vSAN storage policies, or NSX micro-segmentation, you’ll need to find Azure equivalents or adjust your approach.

Azure has matches for most of these, but they work differently. For example, Azure Load Balancer and availability sets handle workload distribution differently from DRS, and Azure Network Security Groups replace NSX firewall rules but with a different configuration model. Plan for this mapping early.

Microsoft licensing surprises

Moving from VMware to Azure changes your licensing landscape by quite a bit. That said, Azure Hybrid Benefit can save you a lot on Windows Server and SQL Server costs if you have Software Assurance.

On the other hand, some third-party software has specific virtualisation licensing terms that might change when you switch hypervisors. Audit your software licensing before you migrate, not after.

Network reconfiguration

This catches more teams out than almost anything else. Your VMware environment probably has a carefully configured set of VLANs, firewall rules, static IPs, and DNS records. Some of this will map cleanly to Azure networking; some won’t. Pay particular attention to:

• Static IP addresses: Azure Migrate can retain static IPs in many scenarios, but you need to plan for this during replication setup.
• DNS: make sure your DNS records update correctly after cutover.
• Firewall rules: NSG (Network Security Group) rules in Azure work differently from VMware firewall policies. Don’t assume a one-to-one translation.

Application compatibility

Most applications run happily on Hyper-V after running on VMware, but “most” isn’t “all”. Test thoroughly, especially for applications that use VMware Tools integrations or custom hardware drivers. Also those that have specific hypervisor requirements in their support agreements. Running test migrations before your production cutover is super important for catching these issues early.

The temptation to lift and shift everything

It’s common to see organisations treat a VMware exit as a pure infrastructure swap: take every VM, move it as-is, and call it done. While that gets you off VMware quickly, it misses the opportunity to modernise. Some of those VMs might be better served as Azure PaaS services, containers, or even retired entirely. A migration is the perfect time to question whether every workload still needs to exist in its current form.

Underestimating the timeline

A VMware-to-Azure migration is a meaty project, and it takes longer than most people expect.

Assessment alone can take several weeks if you want reliable performance data. Factor in testing, wave-based migration, validation, and decommissioning, and a realistic timeline for a medium-sized estate is typically three to six months. Rushing it makes things more risky.

Migrating away from VMware doesn’t have to be painful. With the right planning and tools, it’s an opportunity to modernise your infrastructure and simplify your management. You might potentially reduce costs in the process, too.

Whichever way you’re going to do it, make sure you have a clear strategy. We’d also recommend finding a partner who understands both sides of the journey.

As an Azure-focused managed service provider, we help organisations plan and execute migrations to Azure all the time. If you’re weighing up your options or ready to get started, get in touch and we’ll walk you through what your migration might look like.