Plan a move or handover: Proxmox setup covers preparing the target. For an existing environment and a provider change, use Proxmox takeover. Initial meeting.
Moving a Proxmox server and changing its service provider are separate projects. The technical move transfers guests and, where necessary, data; the operational handover establishes access, knowledge and responsibility. The article includes the common commands for cluster join, migration, restore and node removal. As of October 2026.
Contents
- Assess the starting point and select a method
- Prepare the new hardware
- Transfer guests under control
- Example: commands for migration and restore
- Cutover and fallback
- Document the provider handover
- Acceptance and next steps
- Sources
Assess the starting point and select a method
Inventory guests, local and shared disks, CPU types, passthrough, container mounts, bridges and external services. Check the last recoverable backup point before approving a transfer method. The PVE backup path and VM migration have different requirements.
| Situation | Planning path | Clarify beforehand |
|---|---|---|
| Separate old and new hosts | Restore guest backup on new PVE | Backup access, free target, downtime window and final data point |
| Replacement within one cluster | Join an empty node, migrate guests, remove old node in order | Quorum, capacity, CPU compatibility and storage |
| CPU change or locally bound devices | Planned shutdown with restore or suitable offline migration | Guest CPU configuration, drivers and devices on the target |
| Provider change only | Operational handover without forcing a hardware move | Documentation, access and responsibilities |
Regular live migration requires source and target in the same cluster, a reliable connection and a suitable target package version. Passed-through PCI/USB devices block this path; CPU compatibility must be established first (VM migration requirements). This is not a promise of uninterrupted migration. Other transfer functions need a separate assessment of version and topology.
Prepare the new hardware
Check CPU, RAM, disks, controllers and networking against Proxmox system requirements and actual guest demand. The hardware and sizing guide explains resource planning. Include headroom for migration, backups and a planned node failure in the same assessment.
Install the target with a unique hostname and suitable networking. Record bridge names, VLANs, routing and storage IDs. Do not infer NIC names and disk paths solely from the old installation (network configuration). Keep console access independent of the affected network configuration.
The target node must contain no guests before joining the cluster. Joining overwrites /etc/pve and inherits the cluster storage configuration. Different local storage layouts and node restrictions need suitable configuration afterwards (Cluster Manager). Do not remove or rename old and new nodes without coordination.
Transfer guests under control
For backup restore: confirm access to the actual backup storage and, where applicable, PBS namespace, permissions and encryption keys. Select target storage and ID, restore without automatic startup, then check networking and devices. The restore test guide describes an isolated trial.
For LXC, PVE backups do not include bind/device mount contents. Transfer additional data separately. Before a test start, check all mpX entries and remove production bind/device mounts or redirect them to independent test copies. This limitation is documented in Backup and Restore.
For cluster migration: transfer a suitable guest first, with defined acceptance criteria. Assess local disks, CPU model and device bindings using the VM documentation. One successful migration does not replace checks for other guest types. When changing CPU vendor, plan a shutdown and a suitable startup CPU type rather than assuming live compatibility.
Example: commands for migration and restore
The following commands show the common paths. Guest IDs, node and storage names are placeholders.
Add a new node to the cluster (on the new, guest-free node):
pvecm add 192.0.2.11 --link0 10.10.10.15 # IP of an existing node, own Corosync address
pvecm status # check quorum and members
pvecm nodes
Migrate guests:
qm migrate 100 pve-new --online # VM live, shared storage
qm migrate 100 pve-new --online --with-local-disks --targetstorage local-zfs # VM with local disks
pct migrate 200 pve-new --restart # container: restart migration
A VM with different CPU types on source and target gets a compatible CPU type before it moves to the new host:
qm set 100 --cpu x86-64-v2-AES # broadly compatible CPU model; takes effect after the guest's next restart
Restore guests from a backup (standalone new host), each without automatic start:
qmrestore /mnt/backup/vzdump-qemu-100-2026_10_21-02_00_00.vma.zst 100 --storage local-zfs
pct restore 200 /mnt/backup/vzdump-lxc-200-2026_10_21-02_00_00.tar.zst --storage local-zfs
# from a Proxmox Backup Server:
qmrestore pbs-store1:backup/vm/100/2026-10-21T02:00:00Z 100 --storage local-zfs
Remove the old node, only after acceptance, once it has been shut down and is no longer reachable (on a remaining node):
pvecm delnode pve-old
pvecm status
Do not bring the removed node back into the network without reinstalling it first: the old and the new cluster identity would collide.
Cutover and fallback
Before the final transfer, stop writes in a controlled way and establish the final data point. Applications spanning multiple VMs also require coordinated consistency. Then secure the source against duplicate startup; move production IP, DNS, routing and external connections to the target according to the cutover plan.
Define fallback beforehand: who decides, which data has been written since cutover, and how will it return to the source? An old backup point is not a lossless return after production writes on the target. Document the authoritative writer and an abort point before production acceptance.
Document the provider handover
Clarify these items with the previous and future operator. They are review points, not automatically included additional services:
- Hand over inventory, network plan, storage mapping and documented deviations.
- Establish administrator access, MFA recovery and account ownership.
- Check backup catalogue, key access and existing restore evidence.
- Record monitoring, alarm paths and open incidents.
- Define responsibility for host, guest, application and external providers.
- Agree when permissions change and old access is revoked.
Transfer secrets through a protected handover channel. Revoke existing access only after confirming replacement access. A hardware move follows only if findings and target architecture require it. WZ-IT describes entry through a health check and documented handover on the takeover page.
Acceptance and next steps
After cutover, check guest startup, data point, business workflow, connectivity, backups and monitoring. Remove the old node only after acceptance and according to the node removal procedure. Where data deletion is required, account for the agreed backup and retention scope.
For new target hardware: Proxmox setup. For inventory review, documentation and operational handover: Proxmox takeover. Findings determine the transfer method and operational scope.
