We're planning to move about 60 VMs from vCenter to Proxmox VE, and we're also considering replacing Veeam with Proxmox Backup Server. We already have a small Proxmox cluster running alongside VMware.
What tends to catch people out with Windows migrations, backups, storage, or production support?
Start with a few representative VMs, not just the easiest Linux box. Windows boot storage and networking deserve a proper test.
Make sure the VirtIO storage driver is installed before switching the boot disk to a VirtIO controller. If a converted guest won't boot, a SATA controller can be a useful way to get it running while you sort out the driver, then change the boot disk last. Also check the boot order and keep console access available.
The new virtual NIC may appear as a different adapter, so static IP settings can need attention and the old adapter can linger as a hidden device. Install the guest agent and plan when to remove VMware Tools. Test the application after the guest boots, not just whether you can log in.
For domain controllers, I'd seriously consider building fresh ones on Proxmox instead of converting them. Promote a new server, check replication and DNS, transfer any roles and dependencies, then demote the old one. Do them one at a time.
DHCP, fixed DNS addresses, site placement and anything else running on a DC need a plan before you retire it. If conversion is necessary, avoid copying a running DC as an ordinary live VM. Understand the risks around AD replication and validate it carefully after the move.
Don't treat PBS as a straight feature swap for Veeam just because both can restore a VM. List the restores you actually rely on, especially SQL and other application-aware recovery, then test those workflows before retiring the existing backups.
Work out where PBS storage will live, how long backups need to be kept, and how you'll recover if the Proxmox cluster or backup server is unavailable. A successful backup job is only half the test. Restore a representative Windows server and verify the application and data too.
~slightly!more+legible:
That gives us a useful test plan. SQL recovery is one of the things we need to compare before deciding.
Inventory vendor appliances and supported hypervisors early. A VM can run perfectly well and still leave you without vendor support on Proxmox. That may decide which workloads can move at all.
Also check CPU compatibility across cluster nodes if live migration matters. Using the host CPU type can expose features that aren't available on another node. Storage needs its own rehearsal too, particularly multipathing and snapshot or backup requirements on shared SAN storage.
For production, decide what support you need rather than treating the repository choice as just a price question. A subscription gives access to the enterprise repository and support, so compare the options with your maintenance and escalation requirements.
Plan the update strategy before moving the bulk of the workloads. You already have a parallel cluster, which gives you somewhere to test the process before it becomes the only home for everything.
Answers are reviewed before publication.
604miles_before_refuel:
Check the virtual switch and VLAN configuration too. A healthy guest NIC won't help if its new network isn't mapped correctly.