Guide to Migrating From VMware to Hyper-V

If you're looking to migrate workloads from a VMware platform to Microsoft Hyper-V, the good news is that there are multiple migration paths possible. The bad news is that it may not be immediately obvious which approach is best for your needs.

That's why we've prepared this guide to migrating from VMware to Hyper-V. Below, you'll find a comparison of the main migration strategies, along with the key steps you'll need to carry out to move your virtual machines (VMs) from a VMware environment into Hyper-V.

Background: What Is VMware, and What Is Hyper-V?

Let's start by defining each product.

VMware is a suite of solutions for running and managing virtual machines. VMware was one of the first major vendors in the virtual machine business, and it has long offered a robust set of virtualization capabilities.

Hyper-V is a virtualization platform from Microsoft. It lets you deploy and run virtual machines on most versions of Windows. (Hyper-V doesn't support Windows Home, but it works on other modern versions of the Windows operating system.) 

Why Migrate From VMware to Hyper-V?

Related:VMware's Pivot to Subscriptions: Innovation or Disruption for Customers?

Generally speaking, VMware and Hyper-V are both excellent virtualization platforms. They provide the same core features and support most of the same use cases. Their price points are also similar (especially when you factor in the costs of all of the ancillary technologies — such as operating system licenses, networking, and storage — that you'll need to support VM deployments).

That said, Hyper-V offers some capabilities that VMware lacks. Hyper-V is more tightly integrated with Windows — which is unsurprising, given that Hyper-V is a Microsoft technology. This makes Hyper-V simpler to deploy and manage in some senses, since much of the technology you'll need is available by default if you already have a Windows environment running.

There's also the fact that Broadcom's recent acquisition of VMware has created some uncertainty about the future of VMware's products, increasing interest in VMware alternatives. Although at this point there is no specific reason to think that Broadcom will upend VMware's product offerings, even the slightest possibility that it could happen may have some organizations considering migrating from VMware to an alternative like Hyper-V.

On balance, we should note that VMware has plenty of strengths that Hyper-V lacks. For example, VMware works across a wider range of operating systems, whereas Hyper-V is Windows-centric. VMware's orchestration, virtual networking, and security features are also arguably more robust than those of Hyper-V — but a detailed comparison of these capabilities within each platform is beyond the scope of this article.

Related:Broadcom Explains VMware Strategy Amid Product 'Confusion'

Prerequisites for Migrating to Hyper-V

As we discuss in detail below, there are multiple migration methods available for getting VMs from a VMware environment into Hyper-V. However, all the migration paths will require you to address a few prerequisites prior to starting the migration.

Prerequisite 1: Licensing considerations

Migrating VMs from one platform to another may impact the availability of licenses for the Windows operating systems that you have running on VMs. This is because when you change a VM's configuration, it appears to the operating system that the system's "hardware" has changed (even though the hardware is virtual rather than physical), which will cause licenses to stop working in some cases.

Whether this will actually present an issue depends on exactly which type of Windows operating system license you have. In most cases, it is possible to migrate a Windows license to a new VM; you shouldn't have to pay for new licenses. But this is something you'll want to look into prior to performing the migration, to ensure that your new Hyper-V environment doesn't become unusable due to licensing issues.

Prerequisite 2: Hardware considerations

Your new Hyper-V environment requires servers to host it. If all your servers are currently tied up hosting VMware VMs, you'll need to either purchase new servers or (if you want to take a more cost-efficient approach) migrate your VMware VMs incrementally rather than all at once.

The latter approach means shutting down some of your VMware VMs, converting them to Hyper-V, then repeating the process with the other VMware VMs until you have migrated all of the VMs. That way, you don't have to stand up a whole new set of servers to host the new VMs.

In general, since VMware and Hyper-V offer similar levels of performance and resource consumption, Hyper-V shouldn't require any additional bare-metal servers beyond the ones you use for VMware.

Prerequisite 3: Installing Hyper-V

You'll need to install Hyper-V before you can migrate VMs to it. Fortunately, this step is relatively easy, thanks to Hyper-V's tight integration with Windows. In most cases, to install it, you simply need to tell Windows to enable Hyper-V.

The exact process for enabling Hyper-V depends on which version of Windows you are using. On Windows 10, you can turn on Hyper-V through the Windows Settings app. On Windows Server editions, use Server Manager to enable Hyper-V.

You'll need to set up Hyper-V on each bare-metal server that will be part of your Hyper-V environment.

Ways to Migrate From VMware to Hyper-V

Once you've sorted out licensing and hardware requirements, you can decide exactly how you'll migrate VMs from a VMware environment to Hyper-V. There are two main approaches.

Method 1: Convert offline VMs

This conversion method is the most straightforward, and since a variety of free VM conversion tools are available, you can carry out this type of migration without having to pay for additional software.

The downside of this approach is that you have to shut down each VM (this is necessary because you can't convert images of running VMs), then convert it to a new VM format, as part of the migration. Since the conversion process can take quite a bit of time, especially if you have large VM images, you may incur significant downtime.

How to migrate VMs offline

The offline migration approach involves these steps:

qemu-img convert -O vpc -f vmdk vmware-image.vmdk hyper-v-image.vhd

The time required to convert VMs can vary depending on your VM configurations and the conversion tool you use — so it's worth experimenting with different options to see which tool works faster for the types of VMs you are working with.

Method 2: Migrate using VM snapshots

A second migration method is to take snapshots of your VMware VMs, then use those snapshots to create new virtual machines in Hyper-V. You can achieve this using any backup and restore software that supports both VMware and Hyper-V environments.

The advantage of this approach is that, because you're taking a snapshot of a running VM instead of converting VM images from one format to another, you don't have to shut down your VMware VMs before you can begin the migration. You also don't have to undertake a long conversion process. Thus, this approach is faster and (in some ways) simpler than the offline conversion method described above.

The downside of snapshot-based migration is that you need third-party software to carry it out. VMware lets you take snapshots of VMs, but you can't directly import those snapshots into Hyper-V — and you can't use Hyper-V to take snapshots of VMware VMs. So, you need a third-party backup-and-restore tool that is capable of taking snapshots from VMware, then "restoring" them as Hyper-V VMs. (We put "restoring" in quotes here because this process doesn't really involve restoring the VMs back to their original state; instead, you're restoring them as VMs running on a different platform — although when performed successfully, the contents of the VMs should remain intact.)

To carry out this type of migration, follow these steps:

Post-migration Steps

No matter which VMware migration method you choose to get VMs into Hyper-V, you'll want to take some time afterward for post-migration validation and configuration.

For example, you may need to set up new virtual networking or storage resources in Hyper-V to emulate the networking and storage configuration you had running in VMware. You may also need to adjust roles and permissions to ensure that different members of your team have the proper levels of access to the Hyper-V VMs.

And you should, of course, validate that your newly migrated VMs work as expected. Bugs in conversion and recovery tools can occasionally trigger strange behavior or cause data corruption, so consider steps like running file system checks to make sure there are no abnormalities in the new VMs before you commit them fully to production.