For well over a decade VMware was the default answer to “what do we run our virtual machines on”, and plenty of organisations never had a reason to revisit it. That changed after Broadcom acquired VMware and changed how the products are packaged and licensed, and many organisations are now reviewing their options at renewal time.
This post is not about the licensing itself. It is about what a sensible exit looks like, for those who decide to move, because replacing the hypervisor that runs everything is a project with real risk, and most of that risk lives in the details.
Start with what you actually run
The virtual machine list is the easy part. Export every VM with its operating system and version, disk sizes, firmware type, snapshot state and the application it belongs to. Then write down who owns each one, because a migration is when you discover how many nobody does.
The harder list is everything that depends on vCenter itself. Backup software that uses VMware’s APIs to take image-level backups. Monitoring that polls vCenter for health. Scripts written against PowerCLI that nobody remembers writing. Disaster recovery tooling. vSAN, if storage lives inside the VMware stack, and NSX, if firewall rules and segmentation do. Vendor appliances shipped as OVA files whose support statements only mention ESXi. Software whose licence is tied to a host or hardware identifier.
The VM list tells you how much work there is. The integration list tells you how long it will take.
Choosing the destination
The realistic options are another commercial hypervisor, public cloud, or an open-source platform. This post is about the last, and the hypervisor itself is not where the risk sits. KVM has been part of the Linux kernel for many years and sits underneath several of the major public clouds; Xen has a similarly long production history. Both are mature.
What separates platforms is everything around the hypervisor. How good is the management plane for the people who will use it every day? Does it do clustering, live migration, high availability and role-based access properly, with an API you can automate against? Which backup products support it? And, most importantly, who do you call at three in the morning? Open source removes the licence fee. It does not remove the need for someone who knows the platform deeply.
The move is also a natural point to rethink storage. If the servers and the SAN are both near the end of their life, replacing them with a hyperconverged cluster, where every node contributes compute and disks to a shared distributed storage pool, removes the array and its renewal from the picture. If the servers are recent, many can be repurposed as cluster nodes, provided they have drive bays, SSDs with power-loss protection and enough network ports to keep storage traffic separate. Most open-source hypervisors can also use an existing SAN over iSCSI or NFS, so the array can serve as an interim datastore while the cluster is built out.
Converting the virtual machines
There are four common routes, and most migrations use more than one.
Cold conversion. Shut the VM down, export its disks, convert them to the target’s format and import. It is simple and predictable, and the downtime scales with the size of the disks.
Direct import. Some open-source platforms now include import tools that connect to an ESXi host or vCenter and pull the disks across, and some can start the guest on the new platform while the remaining data streams in behind it.
Backup and restore. Some backup products can restore a VMware backup onto a different hypervisor, which turns the migration into a restore you were hopefully already practising.
Rebuild. For web tiers and other stateless services, building fresh VMs on the new platform and moving only the data is often cleaner than carrying ten years of accumulated configuration across.
The things that break
Conversions rarely fail at the disk copy. They fail on first boot, for predictable reasons.
- Storage and network drivers. VMware guests use VMware’s own paravirtual disk controller and network adapter. Windows is the guest that bites: install the new platform’s paravirtualised drivers before the move, or boot on an emulated controller first and switch once the drivers are in. Remove VMware Tools while the guest is still on VMware, as it can be awkward to uninstall afterwards.
- Network identity. The new virtual adapter has a new MAC address. Windows treats it as a new network card and the static address stays attached to the old, now hidden, one. Linux interface names can change too. Have the addressing documented before cutover.
- Snapshots. Consolidate them first. A VM with a long snapshot chain is a conversion failure waiting to happen.
- Firmware and virtual TPM. A guest installed under UEFI will not boot on a VM configured for legacy BIOS, and the other way around. Virtual TPM contents generally do not come across, so any guest using BitLocker needs its recovery key to hand.
- Time. If VMware Tools was providing time synchronisation, make sure the guest has a proper time source afterwards, particularly domain controllers.
- Activation. Some software re-activates or complains when it sees new virtual hardware.
Sequencing the cutover
Build the new platform first and try to break it before any production workload arrives. Pull a disk, power off a node, live-migrate under load, and run a full backup and restore. A platform that has only ever been healthy has not been tested.
Then pilot with a few low-risk VMs and leave them for a week. After that, move by application rather than by VM: an application and its database go together, because splitting them across platforms adds latency through the interconnect and makes rollback messy. Keep the ESXi environment available as a fallback for each group until that group has been proven, and decommission it last.
Work backwards from the renewal date. If the migration cannot finish before it, find out early what the shortest term on offer is, rather than compressing the cutover to fit a deadline.
What to leave behind
A migration is the cheapest time to stop running things. The inventory will surface VMs nobody owns, operating systems past their support date, and servers allocated three times the memory they have ever used. Retire, upgrade and right-size on the way through rather than faithfully recreating the old estate on new foundations, and write runbooks for the new platform as it goes in, not after.
A practical starting point
If a renewal is on the horizon, four things are worth doing this month:
- export a full inventory, including firmware type, snapshots, virtual TPM use and owner
- list every system that talks to vCenter, and what each would need on a new platform
- convert three low-risk VMs onto a test host and time each step
- put the renewal date in the plan and work backwards from it
Those four answers turn “we should look at leaving VMware” into a timeline that can be costed.
Where Bizix fits
Bizix designs, builds and operates hyperconverged private cloud on an open-source hypervisor and storage layer, with no per-socket licence fees, deployed through a phased runbook and run day to day through the Bizix Operator UI. Lifting legacy workloads across and bringing them under managed control is part of that work, whether the cluster sits on your premises or in our Australian cloud.