Not sure if you're still preparing for this, but I've found using a cloud-based backup provider (I won't mention the one I used because I don't want to be accused of shilling) that does bare metal restores will let you move without needing to boot to an image on the source side. If the site has a decent connection, you simply create the backup, boot a fresh VM using their recovery image, and restore to that as though it was hardware. Most providers don't support it and you may need to boot using ide controllers, install drivers, then change the controller but it will get the job done. If You're moving a domain controller or exchange keep in mind that can sometimes be a bit trickier. Also, you'll need to make sure everyone treats things as read-only until the job is done (nothing on the old server will get synced after the backup is taken) and you'll want some way to disconnect - turn off the old server when you go live with the restored version.
If it is a large backup and you need to keep things more or less in sync (for example, a TB sized db), there is a more roundabout way of doing it. Build a jumpbox with enough room to store a restored
image. Lots of cloud providers will allow you to restore to a vhd. They'll also generally allow continuous back up and restore.. you can probably see where this is going. Do your intiial restore over a weekend, keep it up to date during the week, then go readonly on the source the Friday night. One last sync, then copy the file to your host, convert from vhd to qcow2 and do the driver shuffle. It'll be wonderful if one day backup provides will allow restoring to a KVM set up natively (
https://meldco.dk/?Page=/Doc/History/doc/linux/virt-p2v-move-windows-to-linux seems like a decent start), but for now you can do it yourself if you're wiling to put in the work.