From a VPS to a dedicated server

What actually changes underneath

A VPS and a dedicated server differ in the parts a Linux system notices at boot and nowhere else: the disk controller, the disk names, the network card and the firmware. Everything above that, the packages and the configuration and the data, has no opinion about which it runs on.

• The disks stop being vda and become sda or nvme0n1. Anything in fstab or in the bootloader that names a device instead of a UUID would break, so the copy keeps the UUIDs and the names stop mattering.
• The virtio driver gives way to a real controller, which has to be in the initramfs or the kernel cannot reach the root at all.
• The firmware may differ: many VPS are BIOS where the hardware is UEFI, or the other way round.
• The network card is new, with a new MAC and often a new name.

The tool handles each of these in the fix-up phase: it builds an initramfs with the drivers of the new controller, installs grub for the firmware the target actually has, renames the main interface to eth0 and pins it to the new MAC, and leaves the rest of the system untouched.

Getting the VPS into the move

If the VPS keeps running, nothing has to be prepared on it at all: the tool reads its disks over ssh while it serves, and that is the on-line mode. If you would rather copy it stopped, it needs a Live OS, and a VPS gives you two ways in.

curl -fsSL reloca.to/live | bash

That one reboots the machine straight into the Live with kexec, keeping its address. Where kexec does not work, and on Hyper-V, Azure and a few cloud platforms it does not, attach reloca.to/live.iso through the provider's console or VPS panel and pick full in the menu.

The move

On the new server, booted into the Live OS:

ssh -A root@NEW-SERVER
curl -fsSL reloca.to | bash
reloca.to -n root@VPS-IP      # the plan, nothing written
reloca.to root@VPS-IP

Two disks in the new server and no hardware RAID controller? Mirror them while you are at it:

reloca.to -d /dev/sda,/dev/sdb -o raid=1 root@VPS-IP

The tool then lays out md RAID1 pairs slot by slot, puts the bootloader on both disks, and adds mdadm to the migrated system if it was not there. A VPS with a single disk becomes a server that survives losing one.

Things that bite on this route

• cloud-init. A VPS installed from a cloud image carries it, and on the first boot it would rewrite the network and possibly the hostname. The tool turns off its network and hostname handling by default; -o cloudinit=keep if you have a reason to keep it.
• A smaller disk. The new server does not have to be bigger. If the data fits, the root travels file by file into a fresh filesystem with the same UUID and features, and the bootloader never notices.
• Licences and allow-lists. The IP changes, so anything keyed to it needs updating: firewall rules elsewhere, payment providers, mail reputation.
• The first boot. Watch it on the new server's console. On a VPS you had a panel console; on a dedicated server it is the BMC, and it is the only place the first boot is visible.

Every option that shapes the layout is in the option reference.