Subscribe to GEN
Login to GEN
Across 2021 and 2022, GEN engineers migrated 3,900 nodes from VMware ESXi to Proxmox VE. We have carried on doing that work ever since, for estates ranging from a single host in one office to multi-site clusters carrying production workloads.
Migration is the part of the job where most providers are learning on your infrastructure. We are not. The route off vSphere, the guest-level work that follows, and the storage and network design that has to be right before anything moves are all well travelled ground here, and we run Proxmox in our own UK data centres, so the destination is not theoretical either.
Migration can be delivered as a fixed scope project or absorbed into ongoing Proxmox support, so the team that moves you carries on running the result.
The move away from VMware is a commercial decision far more often than a technical one. Perpetual licences gave way to subscription, product tiers were consolidated into bundles that include a great deal most organisations will never deploy, and minimum core commitments changed the arithmetic for anyone running modest hosts. A three node cluster that cost very little to keep licensed suddenly did not.
Smaller customers also found their route to renewal changed, as partner programmes were restructured and some resellers stopped serving that end of the market altogether. For a lot of organisations the first sign of any of this was a renewal quotation several times the previous one, arriving with limited notice.
None of that makes VMware a bad platform. vSphere remains capable and, where the licensing still makes sense, staying put is a perfectly reasonable answer. GEN support VMware as well as Proxmox and hold no partner status with either, so we have nothing to gain from telling you to move. What has changed for most people is the price of staying, and that is a question worth modelling properly rather than reacting to.
Proxmox VE 8 will import from ESXi directly, and for a straightforward Linux guest that is very nearly the whole job. The difficulty in a real migration is almost never the transfer itself. It is what the guest expects to find when it boots on different virtual hardware, and that is where a migration either succeeds quietly or turns into a week of unexplained faults.
A Windows guest that booted from a VMware paravirtual controller will not boot from VirtIO SCSI without the driver already present. Get the order wrong and the guest bluescreens on first start. The same applies to firmware: an EFI guest needs an EFI disk and the correct boot entry on the Proxmox side, and a legacy BIOS guest needs the machine type to match. Secure Boot adds its own certificate work on top.
VMware Tools has to come out and the QEMU guest agent has to go in, or the host cannot quiesce filesystems, report IP addresses or shut a guest down cleanly. Leaving the old tooling installed is a common cause of guests that appear to work and then behave strangely under backup, snapshot or shutdown.
New virtual NICs mean new interface names and new MAC addresses. Linux guests with interfaces pinned by name or by udev rule come up with no network at all, and Windows guests quietly retain the old adapter as a hidden device holding the static address you are trying to reuse. Both are easy to fix and very easy to miss.
Thin provisioned VMDKs do not always land as thin volumes at the far end, and an estate that fitted comfortably on the old datastore can arrive needing considerably more space. Disk identifiers change too, so anything referencing a disk by path or UUID, including some clustering and database configurations, needs checking before cutover rather than after.
Windows guests frequently deactivate when the underlying hardware changes, and Windows Server licensed per physical host needs its position reviewed against the new cluster rather than assumed. Application licences tied to a MAC address, a host identifier or a dongle need identifying in the planning stage, because they are discovered at the worst possible moment otherwise.
Whatever protected the estate on vSphere almost certainly does not protect it on Proxmox. Proxmox Backup Server needs designing in, tested against a real restore rather than a successful job report, before the old platform is decommissioned. Migrating first and solving backup afterwards is the single most common sequencing mistake we are called in to correct.
We assess the existing estate before proposing anything: host specification and age, guest inventory with real rather than allocated resource usage, storage consumption and growth, network topology, backup arrangements and the licensing position. That assessment is what tells us whether Proxmox saves you money at all, and occasionally it tells us it will not.
Design comes next, and it is the part that decides whether the result is any good. Ceph, ZFS, LVM-thin, NFS or iSCSI are not interchangeable, and the right answer depends on node count, network capability, failure domain and how much rebuild traffic you can tolerate. On the network side, distributed switches and port groups map onto Linux bridges, bonds, VLAN awareness or Proxmox SDN, and that mapping is worth getting right on paper first.
We then pilot with a small group of representative guests, one of them awkward by choice, and prove the boot, driver, network and backup path end to end before touching anything that matters. Production moves in scheduled waves, each with a defined rollback, and the source virtual machine stays intact and powered off rather than deleted. Nothing is decommissioned until a full restore has been demonstrated from the new backups.
Afterwards we tune what the move exposed, hand over documentation, and train the team who will run it. Every fault raised along the way is handled through our SAPR method, so a problem is captured and understood before anybody starts changing things.
There is no live migration between vSphere and Proxmox, so every guest takes some downtime. How much depends on the method and on how much preparation is done beforehand. A guest whose disks have been copied in advance and synchronised again immediately before cutover can be down for minutes rather than hours, and for most estates the window fits inside a normal maintenance evening.
Where a service genuinely cannot stop, the answer is usually application level rather than hypervisor level: bring a second node up on Proxmox, replicate or cluster at the application layer, move the traffic, then retire the original. We will tell you which of your workloads justify that treatment and which do not.
Older hardware is worth mentioning here. Proxmox is Debian, and it will happily run production on servers that newer VMware releases have dropped from the compatibility list. HPE ProLiant from G8 through to G11 is a good example, and we support that hardware directly.
That often changes the economics of the whole exercise. An estate facing a licensing increase and a hardware refresh at the same time may only need the first problem solved, which buys several years on equipment that is doing nothing wrong.
A single host with a handful of guests is typically a matter of days from assessment to completion. A multi-site cluster is a project of weeks, most of which is assessment, design and piloting rather than transferring data. GEN migrate production in scheduled waves, so the estate is never in an all-or-nothing state.
There is no live migration between vSphere and Proxmox, so every guest takes some downtime. Where disks are copied in advance and synchronised again immediately before cutover, that is usually minutes rather than hours. Workloads that genuinely cannot stop are handled at the application layer instead, by standing up a second node on Proxmox and moving the traffic.
Usually, yes. Proxmox VE is Debian based and supports a considerably wider range of hardware than current VMware releases, including HPE ProLiant generations that have been dropped from newer compatibility lists. GEN assess the existing hardware as part of the migration and will say plainly where a host is not worth keeping.
Backup is designed in before migration, not after. GEN deploy and test Proxmox Backup Server as part of the project, and nothing on the old platform is decommissioned until a genuine restore has been demonstrated from the new backups. Offsite synchronisation to GEN's UK data centres is available as an option.
No. Mixed estates are normal and GEN support VMware vSphere and ESXi, Microsoft Hyper-V, XCP-ng, HPE VM Essentials and bare metal KVM/QEMU alongside Proxmox VE. Where part of an estate is better left on its current platform, that is a perfectly good outcome and GEN will support the result as one estate.
GEN do, if you want us to. Migration can be delivered as a standalone project or rolled into ongoing Proxmox support with a 30 minute SLA available 24 hours a day. There is no support contract, no minimum term and no notice period.
Before committing to anything, have the estate assessed properly: what you are actually running, what it will cost on each platform, and what the migration genuinely involves. We will tell you if staying on VMware is the better answer, because we support that too and we sell no licences either way.
Full detail of the ongoing service is on our Proxmox support page. For anything urgent, raise a case on the HelpDesk and an engineer will pick it up.
