I have seen the documentation saying to build an empty VM with slightly more space for each volume than was on the physical server, then use clonezilla to create an image of the server, then import it. That seems ok, but I’m hoping someone out there has more real-world experience in doing this and can share if they did it differently, or encountered any pitfalls.
As my environment matures, I am moving from “Hey I have 1 physical server with everything on it” to “Let’s use a hypervisor and spin off services onto their own.” When the base OS is P2V’d, I’ll be able to have 2 hypervisors and start implementing HA. I’ve been using this system as a scratchpad and dev box for 10 years and would love to just migrate it over.
If this is in commercial space, there’s products like carbonite and others that kind of don’t care if the machine is a physical or virtual in some senses. If getting it done is time sensitive (eg a migration from old provider to new provider of a few dozen servers) is required in like 1 week, don’t spend too much time on which perfect world you want to live in, you’ll end up like 50% of projects which end up failing.
If you migrate then rebuild that’s also completely reasonable.
One thing I’m not sure of, but here’s an answer using just veeam: get your backup, export to VMDK, then convert to qcow2 or whatever. https://blog.lbdg.me/proxmox-convert-vmdk-to-qcow2/
With that converted, then do delta syncing with carbonite.
If you have a huge outage window like for dozens of terrabytes you might need more than a weekend, ask everyone to finish up on Friday lunch and take all servers offline, then you should be able to take the source vmdks and convert them. Just straight attach the storage to proxmox.
One thing though is install virtio drivers in advance. Before migration begins.
BTW I’m not an expert on proxmox since I only have a 3 node cluster on my home lab, but at work I’ve done dozens of client migrations to and from different platforms, hyperv, vmware, Nutanix, aws, azure.
But other commenters are totally right, best to rebuild, but you don’t have to do that before, just start doing them after. Get, and onboard. Remove that touching timber. Then replace. Fewer changes at once. You’ll take fewer shortcuts in rebuild when there’s no hard immediate deadline.
If you’re not under a deadline, don’t migrate imo. Just build new. If there’s anything you can’t do that just maybe keep it on the old platform and complain to the vendor over and over until they move it and raise it as a risk to your decision makers so it’s not your fault for performance and or legacy debt reasons.
Hope that helps but good luck!