What Actually Breaks in a Proxmox Migration
Nobody loses a migration to an exotic kernel bug. They lose it to a forgotten route, a renamed NIC, or a backup job that quietly stopped weeks ago.
Migrations fail in boring ways
Nobody loses a migration to some exotic kernel bug. They lose it to a forgotten static route, a NIC named differently on the new host, or a backup job that quietly stopped running three weeks ago. The technology is the easy part. The details are what bite.
The four things to check first
- Network naming. VMware and Proxmox do not name interfaces the same way. Map every vSwitch and VLAN before you move a single VM, not during.
- Storage layout. Decide on ZFS or Ceph up front. Mixing them later because you ran out of space is how clusters get fragile.
- Boot mode. BIOS versus UEFI mismatches are a common reason a converted VM boots to a black screen. Confirm it per machine.
- Guest tools. Remove VMware Tools and install the QEMU guest agent. Skip this and you break clean shutdowns and live migration.
Move in waves, not in one night
The temptation is to schedule one long weekend and flip everything at once. Resist it. Pick a small wave of low risk machines, migrate them, and run them for a few days. You will find the gaps in your runbook while the stakes are low. Then the production wave is routine instead of heroic.
The cutover nobody regrets
A good cutover is boring. The runbook is written, the rollback is tested, and the team has already done the steps once on staging. If your plan depends on someone improvising at 2am, it is not a plan yet.