Migration to serverplus

serverplus is built on OpenStack, so you can move almost anything to it: VMs from other clouds and VPS providers, servers from your own server room, individual sites and databases. Below is how to plan the move, three working approaches and how to keep downtime to a minimum.

Where to start: an inventory

Before the move, list what you are migrating — that's half the battle.

• Servers: OS and version, disk sizes, data volume, installed software.
• Dependencies: which services talk to which (web → database → cache), external integrations, addresses and ports.
• Data: where files and databases live and how large they are — that drives the transfer time.
• Domains and DNS: which records point to the old addresses; lower the TTL in advance.
• Downtime window: when the switch-over will hurt the least.

Three migration approaches

The choice depends on what you are moving and how important it is to keep the system exactly as-is.

Approach 1. Move data to a new server (most common)

You spin up a clean server on serverplus, install the software and move only the data. Slower to set up, but you get a fresh system without accumulated cruft and old problems. Fits most sites and applications.

Approach 2. Move the disk image (lift-and-shift)

You take an image of the whole old server, upload it to serverplus and run it as-is. Fast and no rebuild, but the image must be able to run on OpenStack: virtio driver support and, ideally, cloud-init. Fits when moving the system is easier than reconfiguring it.

Approach 3. Move individual disks and volumes

If you only need to move a data disk (for example a database volume), you can upload it as a separate volume and attach it to a server on serverplus. Often combined with approach 1.

Moving files and databases

Files — via rsync (repeatable, transferring only changes):

rsync -aAXz --info=progress2 -e ssh /var/www/  user@<new-IP>:/var/www/

PostgreSQL:

# on the old server
pg_dump -Fc mydb > mydb.dump
scp mydb.dump user@<new-IP>:~

# on the new server
pg_restore -d mydb mydb.dump

MySQL / MariaDB:

mysqldump mydb | gzip > mydb.sql.gz
scp mydb.sql.gz user@<new-IP>:~

gunzip < mydb.sql.gz | mysql mydb

For large volumes it is convenient to stage the data in serverplus S3 object storage and download it on the new server — faster and more reliable than copying directly between machines.

Uploading a disk image to serverplus

If you chose lift-and-shift: take a disk image, convert it to qcow2 if needed and upload it to images (Glance).

# convert (if the source is raw/vmdk)
qemu-img convert -O qcow2 disk.raw disk.qcow2

# upload the image to serverplus
openstack image create --disk-format qcow2 --container-format bare --file disk.qcow2 my-migrated-image

# launch a server from the uploaded image
openstack server create --image my-migrated-image --flavor m1.small --network private --key-name my-key migrated-vm

For the image to boot and work. The system must already have virtio drivers (disk and network), cloud-init enabled or SSH-key access and network settings preset, and a bootloader (GRUB) not tied to old disk names. Otherwise the server comes up but is not reachable over the network, or won't boot.

Special case: Windows and Hyper-V

Windows servers (including from Hyper-V) migrate with the same lift-and-shift, but need preparation — otherwise Windows won't boot on OpenStack. The key: install VirtIO drivers and cloudbase-init beforehand.

Preparing Windows (before the move)

• VirtIO drivers. On the running Windows install the disk (viostor) and network (netkvm) drivers from the virtio-win package. Without them you get a 0x7B blue screen (INACCESSIBLE_BOOT_DEVICE) after the move, or lose the network.
• cloudbase-init — the Windows equivalent of cloud-init. Sets the administrator password, hostname and network on first boot. Install it beforehand.
• Remote access. Enable RDP and a firewall rule for port 3389 (better via cloudbase-init).
• Licensing. Agree the Windows licensing question with serverplus in advance (your own license or provider-supplied).

Export and conversion from Hyper-V

Hyper-V stores disks in VHD/VHDX format. Before converting, merge checkpoints so a single file without differencing disks (AVHDX) remains.

# PowerShell on the Hyper-V host: stop cleanly and merge checkpoints
Stop-VM -Name "MyWinVM"
Get-VMSnapshot -VMName "MyWinVM" | Remove-VMSnapshot   # merges into the base VHDX

Then convert the disk to qcow2 (qemu-img can read VHDX):

qemu-img convert -p -O qcow2 MyWinVM.vhdx windows.qcow2

Uploading the image with the right properties

When creating the image, set properties so Windows sees the disk and network, and for Gen2 — UEFI:

openstack image create --disk-format qcow2 --container-format bare \
  --property os_type=windows \
  --property hw_disk_bus=virtio \
  --property hw_vif_model=virtio \
  --property hw_qemu_guest_agent=yes \
  --file windows.qcow2 win-server-2022

# for Hyper-V Generation 2 (UEFI) add:
#   --property hw_firmware_type=uefi

The generation matters. Hyper-V Gen1 is BIOS, Gen2 is UEFI. The hw_firmware_type=uefi property is only needed for Gen2. Check in the serverplus panel or support whether UEFI boot is supported; if not — migrate a Gen1 (BIOS) disk.

First boot

• Open port 3389 (RDP) in the security group and give the server a floating IP.
• After boot the VirtIO drivers load and cloudbase-init sets the administrator password — connect over RDP to the external address.
• Check Device Manager (no "unknown devices"), the network and Windows activation.

Networking and DNS switch-over

While the old server is still running, prepare the network, floating IP and security groups on serverplus (open only the ports you need). Then switch traffic:

• In advance (a day or two) lower the DNS TTL to 300 seconds — so the switch-over is quick.
• At cut-over, point the A records to the new floating IP.
• Do not delete the old server — keep it until you've fully verified, for a quick rollback.

Minimizing downtime

Don't move everything in one window. Do a pre-sync in advance (the bulk of the data), and in a short downtime window only a final delta-sync of changes and the DNS switch.

# beforehand — full pass
rsync -aAXz /var/www/  user@<new-IP>:/var/www/

# during the downtime window — only changes, plus deletions
rsync -aAXz --delete /var/www/  user@<new-IP>:/var/www/

Post-switch verification

• The site/app opens at the new address, forms and login work.
• The database responds, data is present and current.
• External integrations (payments, email, APIs) work from the new addresses.
• The SSL certificate is valid (move it or re-issue for the new server).

FAQ

The uploaded image won't boot or isn't reachable. Almost always missing virtio drivers or cloud-init in the image. Building a clean server (approach 1) and moving data is easier than fixing someone else's image.

No internet on the new server. The network must have a router with an external gateway, and the server needs a floating IP.

The migration is too slow. Push large volumes through S3 object storage, compress data (rsync -z), and use dumps for databases.

Windows: a 0x7B blue screen on boot. The VirtIO disk driver (viostor) was not installed before conversion. Install virtio-win on the source Windows and retry; or temporarily boot on a SATA/IDE bus, install the driver and switch to virtio.

Windows: no network after the move. Missing the netkvm driver, or the image was created without hw_vif_model=virtio.

Windows: can't log in. Use cloudbase-init to set the administrator password on first boot.

I'd rather not do this myself. serverplus offers an infrastructure migration service — contact support to have the migration handled for you.

Migration checklist

• Data backed up on the old side (before starting the move).
• Network, floating IP and security groups prepared on serverplus.
• DNS TTL lowered in advance.
• Data moved and verified; a final delta-sync done.
• DNS switched, application and SSL verified.
• The old server kept until everything is confirmed working.