Move Complete Linux VPS Workloads Across the Fleet Boundary.
Import an external Linux VPS into a newly built Fleet replacement, or export a Fleet VPS into a fresh external machine, without treating a backup archive as a system migration.
A Live First Pass, a Controlled Final Cutover.
The replacement pulls from the source over SSH. Most data moves while the source remains online; stateful application services are stopped only for the final synchronization.
External → Fleet
Inspect the source first, build a compatible replacement through the normal Fleet VPS create path, map the replacement's management keys to source oneclick, then pull the source installation into the new VM.
Fleet → External
Prepare a fresh like-for-like external VPS with temporary bootstrap access. The external replacement pulls the Fleet source and retains its own network, SSH and machine identity.
Stage, Swap, Reboot
User/group account databases are staged until cutover, PAM is synchronized, and the destination swaps the staged accounts immediately before reboot instead of testing SSH in a half-migrated userspace.
The Destination Remains the Destination.
The migration deliberately preserves destination-specific boot, network, SSH, machine, WireGuard and Fleet/virtualisation state while transferring source userspace and application state.
The Old Machine Is Retained.
Import never deletes the external source. Export never deletes the original Fleet VPS. After successful cutover, source application services remain stopped to prevent split-brain while the operator validates the replacement.
External Portability Is not the Same as Fleet-to-Fleet Migration.
Use Import/export
Use one-click --vps import or one-click --vps export --name <vps> when the migration crosses the Fleet boundary or the replacement needs to retain its own infrastructure identity.
Use Fleet-to-Fleet Migration
Use one-click --vps migrate when both KVM hypervisors are trusted Fleet members and the goal is to move the actual VM disk and libvirt definition between them.