Proxmox is a sensible choice for a small estate, a lab, or a team that wants KVM without a large platform group. The reason to leave is not that it fails. The operating model stopped fitting.
Where Proxmox fits
One cluster. Operators who live in the web UI. Backups you already understand. No requirement that every VM be a Terraform resource. If that is still the job, stay. A migration only to seem modern is a waste.
Where teams get stuck
The next requirement is usually one of these: an API a pipeline can call, YAML and Terraform as the review path, a written route from a Proxmox inventory to guest definitions on the destination, or a host update that boots the previous generation if it fails. Proxmox can be scripted. kcore's default path is the API. Provider kcorehypervisor/kcore is a Go provider, not a shell wrapper. kctl and YAML cover the resources provider 0.5.0 does not include.
kcore-migrate inventories Proxmox as well as vCenter. It converts exported disks to qcow2 or raw. It does not read disks straight from the source as a magic cutover. You still plan the window. The steps are in the import guide.
A fair test
- Export one disk and convert it. Time the steps. That is the project, multiplied.
- Recreate the guest with Terraform or YAML and see whether your review process accepts it.
- Break a host update in a lab and see whether the previous generation boots.
- Check Windows guests and the GPU limit: one physical GPU per VM, no NVIDIA vGPU.
If the UI was the product you wanted, you have your answer. If the reviewable text and the migration output were the product, try the evaluation ISO on the converted guest before you move the cluster.
Questions: team@tacconiconsulting.com.