Options for Migrating from VMware to Microsoft

Here at Virtualization & Cloud Review we've looked at the frankly terrible spot VMware customers have found themselves in lately here, here and here.

In this article I'll lay out the options you have as an organization that's relied on VMware for your virtualization needs but is finding the "sticker shock" too hot to handle and is looking for alternatives.

First of all though, let's acknowledge the power of VMware. They were the first to bring x86 server virtualization into the mainstream, the first to enable VM mobility between physical hosts without downtime (VMotion), and when the game was enterprise datacenter virtualization, they won. The problem (in my view) was that AWS and Microsoft (and the rest of the IT industry) moved the game to an entirely different arena -- public cloud -- and VMware simply wasn't relevant anymore. My impression now is that Broadcom (where technology goes to die) is forcibly trying to milk the last few million out of the acquisition, while caring nothing for nurturing the technology long term. A colleague of mine who works in the health care industry in the U.S. told me that his hospital got a quote for their license renewal of $10 million USD; previously they'd paid $2 million USD per year!

I was a long-time user of VMware Workstation, but as Hyper-V became available in Windows Server, and later in Windows client, it was (and is) a better fit for me and my SMB client's needs. However, I acknowledge the importance of VMware's technology to our industry, and it's sad to see it wither like this.

Many organizations will find themselves contemplating moving off VMware at an accelerated pace compared to their original plans, given the price hikes. Here I'll describe the different options Microsoft has for you.

Straight to Azure Without Passing Go
One option is migrating straight to native public cloud VMs in Azure. There's a very mature, free technology to accomplish this in the form of Azure Migrate.

I've delivered courses to Microsoft partner organizations over the years (and used Migrate myself); in a nutshell it involves the following steps:

  1. Create an Azure Migrate instance, and make sure you have either Contributor or Owner permissions on the subscription.
  2. Create a read only account in VCenter.
  3. Download the appliance (a Windows Server preconfigured OVA image) and go through the configuration wizard to connect it to the Azure Migrate instance. If you can't create the appliance (due to lack of permissions), there's a PowerShell script you can run on an existing Windows Server 2019/2022 server.
  4. Enter the IP address or FQDN of the VCenter server and the required credentials, and continuous discovery of your VM workloads will start. It'll identify Linux and Windows Servers, their VM configuration, see if they're running SQL server and identify if they're running a webserver.

New (currently in preview) is the ability to build a business case based on discovered assets.

As for scale, the appliance can discover up to 10,000 servers in a VMware environment (5,000 in Hyper-V and 1,000 physical servers), and you can have multiple appliances if your environment is larger. All the discovery assessment and migrations are managed from the Azure portal in the Migrate UI. There are both agentless (only the appliance in VCenter is required) and agent-based options, but Microsoft has steadily been improving the agentless coverage, so there are few scenarios where an agent on each VM is required.

Azure Migrate - Servers Databases and Web Apps
[Click on image for larger view.] Azure Migrate - Servers Databases and Web Apps

Once the discovery is complete, you can move to the assess phase, where it'll identify the best Azure VM size as a target for each source VM and also dependency visualization (formerly called Service Map) to identify relationships between VMs. This will assist in the migration because you can move groups of VMs together where an application relies on a backend database server and front-end web server, for example.

Azure Migrate Dependency View
[Click on image for larger view.] Azure Migrate Dependency View

Once you have assessed all your workloads you can start migrating groups of VMs in waves. The workload continues to run on-premises, but the contents of the virtual disks are copied to Azure virtual disks. Once all data on each disk has been uploaded, further disk writes are also uploaded continuously to the virtual disks in the cloud.

When you're ready you can then perform a test failover, where one or more VMs are started in a separate virtual network in Azure for you to verify application functionality. Once you have verified that it's working as expected, you can complete the migration, which will turn off the on-premises VM(s) and copy the last disk writes to the destination VMs, before starting them.

It's worth mentioning that Azure Migrate also integrates with several different third-party (paid) migration services that you can explore if you have specialized needs or extremely large scale.

In the end you'll have all your VMs running in Azure (on Hyper-V, all of Azure relies on this fundamental technology) and you can retire your on-premises hardware (and VMware licensing). Depending on how quickly you needed to migrate, this can be a simple "lift and shift," which doesn't really take advantage of everything else public cloud offers beyond just running VMs. Yes, you're no longer responsible for server hardware and on-premises networking, but you're still managing VMs, with all the associated monitoring, backup, security and patching needs. If you have more time / budget, consider moving some applications / workloads to PaaS services such as web apps or Azure SQL DB.

This approach also means you must train your staff to maintain VMs in Azure, a somewhat different skillset than VMware management. If you really like the VMware approach, but you want to get out of the datacenter business -- a second option is Azure VMware Solution (AVS).

VMware on Azure -- the Best of Both Worlds
If learning a whole new platform doesn't take your fancy, Azure has for many years offered hosted VMware environments, known as Azure VMware Solution (AVS). With a minimum of three hosts (16 max in each cluster) these are full bare metal deployments of vCenter Server, VMware vSAN, VMware vSphere and VMware NSX. You can also incorporate Azure IaaS and PaaS services and connect your on-premises to AVS via Expressroute (or VPN). Don't forget Azure Backup, it'll happily back up and protect all your VMs. Most importantly, you can connect the clusters in AVS to your on-premises VCenter management and thus migrate workloads from one environment to the other.

This is a managed service, so you no longer need to deal with hardware, or software upgrades. Here's a good summary of who's managing what:

Azure VMware Solutions Shared Responsibility Model
[Click on image for larger view.] Azure VMware Solutions Shared Responsibility Model

The biggest difference between these two approaches (apart from the management interface) is cost. AVS is an enterprise solution. You'll want to do your homework in the Azure Pricing Calculator and definitely consider reserved instances, plus take into consideration that if you run older versions of Windows Server and SQL Server, the free Extended Security Updates (ESUs) will help. If you really want the VMware experience, and are ready to migrate to the cloud, AVS is a great solution.

Overall, if you're looking to migrate to Azure with either of these two options, familiarize yourself with the Cloud Adoption Framework (CAF), which comes with tools, assessments and documentation to assist with migration projects.

Pry These Servers Out of My Cold, Dead Hands
Now, if public cloud isn't your jam, either by choice or by some (by this stage outdated) regulation and you must host your VMs on-premises, Azure Stack HCI is a good option. Despite the confusing name this is a version of Windows Server that you run on your own hardware, either that you gather yourself (validated nodes), or on a pre-installed integrated system or as a Premier solution as Hardware-as-a-Service (HaaS) from select partners. See different flavors and the full catalog.

Azure Stack HCI Management in the Azure Portal
[Click on image for larger view.] Azure Stack HCI Management in the Azure Portal

Azure Stack HCI uses Hyper-V for the virtualization layer, Storage Spaces Direct (S2D) for distributed storage across the nodes (hence "Hyper-Converged Infrastructure," HCI) just like vSAN, and Microsoft's VXLan based Software Defined Networking (SDN). The software is updated twice a year (plus monthly patches) and can now be managed entirely from the Azure Portal via Arc, or from the web-based Windows Admin Center (WAC). You can run Azure Virtual Desktop (AVD) on top of Azure Stack HCI for a modern VDI solution, including support for GPUs for graphics intensive workloads. There's GPU Partitioning, the sharing of a GPUs amongst several VMs and GPU Pooling, allowing you to Live Migrate (VMotion) a VM using a GPU from one host to another. And you can run Azure Kubernetes Services (AKS), a managed K8S platform on Azure Stack HCI.

And the kicker (currently in preview) is that Azure Migrate also supports migrating VM workloads from VMware to Azure Stack HCI.

In some ways Azure Stack HCI is the test bed for new Windows Server versions, with many features currently in Azure Stack HCI showing up in the forthcoming Windows Server 2025.

I've taught several courses on Azure Stack HCI, and it's a solid solution built on top of cutting-edge virtualization tech, both for server hardware, networking and storage.

Old School Is the Only Way for Us
I suspect that if a business has stayed with VMware for the last decade+, knowing that Microsoft had a competing solution in the form of Windows Server Hyper-V and System Center that was just as capable (at least from say 2012 onwards) and less costly, the appetite for taking the leap from one to the other hasn't been great. However, the sticker shock might just be the straw that breaks this particular camel's back.

Remember though that you're really not modernizing if you take this approach. There aren't a lot of cloud benefits in running Windows Server 2025 and System Center 2025 -- you're still managing hardware and standing up SQL servers for each of the System Center components. But if you really must keep it all on-premises but moving off VMware is a necessity, this is a perfectly valid solution.

VMware vs Hyper-V is only one in a long list of ideological battles that have been fought in IT (Linux vs Windows vs Mac, cloud vs on-premises spring to mind) but at the end of the day, businesses run on IT and if your current provider isn't providing value for money, it's time to look elsewhere.

Hopefully I've shown you that Microsoft has several different solutions, depending on your needs.


  • How AI Helps Me Write

  • What's New in VMware vSphere Foundation 5.2

  • What's New in vSAN 8 U3

Subscribe on YouTube