The old office PC works fine - it is just old, loud and one fan away from retirement. Moving it into your Proxmox server sounds perfect. Here are the three real routes, with the catches left in.
Virtualising an existing Windows PC - a P2V migration - is the job where honesty matters most, because every route works and every route has a catch. This page lays out the three honest options for moving a working physical Windows machine onto your Proxmox server, so you can pick with the full picture.
Install Windows in the VM exactly as the video shows, reinstall the handful of programs the machine actually used, and copy the data across the network. It sounds like the slow option, and for a machine with years of accumulated software it is genuinely the most work - but it produces the cleanest long-term result: no inherited driver ghosts, no decade of startup junk, and a VM whose entire history you know.
For a lightly used PC - browser, office, one or two work programs - this route is usually fastest in total hours, including the troubleshooting the other routes can generate.
Use a disk-imaging or backup tool on the physical PC to capture the whole system, create an empty VM, boot it from the tool's recovery media, and restore the image into the virtual disk. The machine arrives with its programs, settings and files intact.
Two honest warnings travel with this route. First, the restored Windows wakes up in completely different hardware, so its first boots may need driver attention - and if the physical PC used a different storage controller mode, Windows can blue-screen with an inaccessible boot device until the storage driver situation is sorted; restoring onto a SATA-attached virtual disk first, installing the VirtIO drivers inside Windows, and only then switching the disk to VirtIO is the veteran order. Second, activation will likely ask questions, because in licensing terms this is a new machine - and an OEM licence from the physical PC does not transfer at all.
The most direct route: convert the physical disk into a virtual disk file on another machine (disk-to-VHD style tools do this from inside the running Windows), copy the file to the Proxmox host, and import it into a VM with a command of the form qm importdisk 100 windows.vhdx local-lvm, then attach the imported disk in the VM's Hardware tab.
Everything said about route two applies here too - new-hardware first boots, storage driver order, activation - with one addition: keep the source PC fully intact until the VM has booted, worked and been backed up. The moment of maximum confidence should come after the proof, not before it.
Whichever route you choose, the VM side is built exactly as in the video - create it there first, then bring the old machine across.
Watch Full VideoBecause the restored Windows is trying to boot from a storage controller it has no running driver for - its old physical controller is gone and the VirtIO controller is new. The veteran fix is ordering: attach the disk as SATA (which Windows can boot) first, install the VirtIO guest tools inside Windows, shut down, then switch the disk to VirtIO SCSI and boot again.
Expect it to ask. A migration is a complete hardware change in Microsoft's eyes. Retail licences can be reactivated on the new virtual machine once the old one is retired; OEM licences tied to the physical PC cannot legally move at all. Budget the licence question into the migration plan, not after it.
If the PC runs only a few programs and the data is easy to copy, a fresh install in the VM is cleaner and often quicker overall. If the machine carries years of configured software that would take days to recreate, imaging or disk conversion earns its complexity. The deciding factor is reinstall pain, not file size.