Complete step-by-step guide to migrating your Hetzner Cloud servers to RamNode Cloud VPS.
This guide provides comprehensive instructions for migrating your virtual servers from Hetzner Cloud to RamNode Cloud. Whether you're seeking different datacenter locations, better pricing, or expanded infrastructure options, this guide covers everything needed for a successful migration.
Hetzner Cloud provides rescue mode access which makes disk imaging straightforward. This guide presents two proven methods: complete disk imaging via rescue mode and live file synchronization using rsync.
| Format | Description | Notes |
|---|---|---|
| RAW | Uncompressed disk image | Largest file size, fastest to create |
| QCOW2 | QEMU Copy-On-Write format | ✓ Recommended - space efficient |
| VMDK | VMware virtual disk format | Convert from VMware exports |
| VDI | VirtualBox disk image | Convert from VirtualBox exports |
| VHD/VHDX | Microsoft Hyper-V format | Convert from Azure/Hyper-V |
Recommendation: QCOW2 is recommended for most migrations due to its compression support. A 40GB disk with 8GB of actual data will result in a much smaller QCOW2 file compared to RAW format.
This method uses Hetzner's rescue mode to boot outside the main OS and create a complete disk image. This is the recommended approach for complete system migrations with all configurations preserved.
Before starting, create a snapshot of your server in the Hetzner Cloud Console:
Connect to your server using the rescue mode credentials:
ssh root@YOUR_SERVER_IP
# Enter the temporary password shown in the consoleList available disk devices:
fdisk -l
# or
lsblkYour main disk is typically /dev/sda on Hetzner Cloud servers. Note the disk size for later.
The rescue system includes most tools, but ensure qemu-utils is available:
apt-get update
apt-get install -y qemu-utilsCreate a compressed QCOW2 image of the disk:
# Create the image (this may take a while depending on disk size)
qemu-img convert -f raw -O qcow2 -c /dev/sda /tmp/hetzner-server.qcow2
# Check the resulting image size
ls -lh /tmp/hetzner-server.qcow2Note: The rescue system has limited disk space in /tmp. For large images, you may need to stream directly to remote storage or use attached volumes.
Stream directly to a remote server or S3-compatible storage:
# Option 1: SCP to a remote server
scp /tmp/hetzner-server.qcow2 user@remote-server:/path/to/destination/
# Option 2: Upload to S3-compatible storage (requires aws-cli)
apt-get install -y awscli
aws s3 cp /tmp/hetzner-server.qcow2 s3://your-bucket/hetzner-server.qcow2Alternatively, serve the image temporarily via HTTP:
# Install and start a simple web server
apt-get install -y nginx
ln -s /tmp/hetzner-server.qcow2 /var/www/html/
systemctl start nginx
# The image is now available at:
# http://YOUR_SERVER_IP/hetzner-server.qcow2Security Notice
This temporarily exposes your disk image publicly. Complete the upload to RamNode quickly and exit rescue mode immediately afterward.
After successfully uploading the image, disable rescue mode in the Hetzner Console and reboot your server to return it to normal operation.
For simpler setups, application-level migrations, or when you want to change the operating system during migration, you can use rsync to transfer files directly to a new RamNode instance.
Create a new VPS on RamNode with the same operating system (or compatible version) as your Hetzner server.
On your Hetzner server, copy your SSH key to the RamNode server:
# Generate key if you don't have one
ssh-keygen -t ed25519 -C "migration"
# Copy to RamNode server
ssh-copy-id root@RAMNODE_IPExecute rsync from your Hetzner server to transfer all files:
rsync -avzP --numeric-ids \
--exclude='/dev/*' \
--exclude='/proc/*' \
--exclude='/sys/*' \
--exclude='/tmp/*' \
--exclude='/run/*' \
--exclude='/mnt/*' \
--exclude='/media/*' \
--exclude='/lost+found' \
--exclude='/boot/efi/*' \
/ root@RAMNODE_IP:/Tip: For minimal downtime, run rsync multiple times. The first run copies everything, subsequent runs only sync changes. Do a final sync after stopping services.
On the RamNode server, update critical configuration files:
# Update hostname
hostnamectl set-hostname your-new-hostname
# Update /etc/hosts
nano /etc/hosts
# Reset machine-id for cloud-init
rm /etc/machine-id
systemd-machine-id-setup
# Update network configuration (if static IP was used)
# For Ubuntu/Debian with Netplan:
nano /etc/netplan/50-cloud-init.yaml
# Apply network changes
netplan applyEnsure the bootloader is properly configured:
# Ubuntu/Debian
update-grub
grub-install /dev/vda
# CentOS/Rocky/Alma
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/vdaFor images larger than 2GB, use the OpenStack CLI for reliable uploads:
# Download your authentication file from the Cloud Control Panel
# Navigate to: API Access → Download OpenStack RC File
# Install the OpenStack CLI
pip install python-openstackclient
# Source your authentication file
source your-openrc.sh
# Upload the image
openstack image create \
--disk-format qcow2 \
--container-format bare \
--file hetzner-server.qcow2 \
"hetzner-migration-image"
# Verify the upload
openstack image listFor more details on using the OpenStack CLI, see our OpenStack API Guide.
After the image upload completes:
| Hetzner Type | Specs | RamNode Equivalent |
|---|---|---|
| CX11 | 1 vCPU, 2 GB RAM | Cloud VPS 2GB+ |
| CX21 | 2 vCPU, 4 GB RAM | Cloud VPS 4GB+ |
| CX31 | 2 vCPU, 8 GB RAM | Cloud VPS 8GB+ |
| CX41 | 4 vCPU, 16 GB RAM | Cloud VPS 16GB+ |
| CX51 | 8 vCPU, 32 GB RAM | Cloud VPS 32GB+ |
Access the VNC console to verify your system boots correctly. Check for any boot errors or driver issues.
If your image has cloud-init installed, network configuration should be automatic. Otherwise, you may need to:
If cloud-init was previously configured for Hetzner, reset it to work with RamNode's metadata service:
Ubuntu/Debian:
# Clean existing cloud-init data
cloud-init clean --logs
rm -rf /var/lib/cloud/*
# Reboot to reinitialize
rebootIf that doesn't work, fully reinstall:
apt purge cloud-init
rm -rf /etc/cloud /var/lib/cloud
apt install cloud-initUpdate your DNS records to point to the new RamNode IP address. Consider lowering TTL values before migration to minimize downtime during the DNS propagation period.
Test all critical services to ensure they function correctly:
systemctl status sshdssh-keygen -A| Practice | Recommendation |
|---|---|
| Create Snapshots First | Always snapshot your Hetzner server before making any changes |
| Minimize Image Size | Clean logs, temp files, and package caches before imaging |
| Use QCOW2 Format | More space-efficient than RAW, faster uploads |
| Test Before Switching | Deploy and test on RamNode while keeping Hetzner running |
| Lower DNS TTL | Reduce TTL days before migration for faster DNS propagation |
| Document Everything | Note services, ports, configurations before migration |
| Plan for Rollback | Keep Hetzner instance available for at least 48 hours after migration |
Need Professional Assistance?
Our Professional Services team can help with complex migrations, ensuring minimal downtime and proper configuration.