How to Migrate a VPS: A Step-By-Step Guide

The safest way to migrate to Website Hosts UK is to deploy a clean VPS or VDS, install the software your workloads need and then move the workloads deliberately. That normally means transferring website files, exporting and restoring databases, recreating web and PHP configuration, synchronising email, moving scheduled tasks and finally changing DNS.

This approach takes more planning than cloning the whole disk, but it avoids importing provider-specific network files, old boot settings, obsolete packages and years of configuration that you may no longer need. It also gives you a clean point from which to document the server properly.

What you need before starting

You should have the following before touching live data:

• Root or sudo access to the old VPS.
• Root or sudo access to the new Website Hosts UK VPS or VDS.
• Enough destination storage for websites, databases, mail and temporary backup files.
• A separate backup stored somewhere other than the two servers.
• Access to the DNS provider for every domain being moved.
• A list of applications that must continue running after the migration.
• A planned maintenance window for the final data synchronisation.

The examples use placeholders such as OLD_SERVER_IP, NEW_SERVER_IP, example.com and database_name. Replace them with your own details. Commands that need administrative privileges are shown with sudo; when you are already logged in as root, remove sudo if preferred.

Choose the correct migration route

Route A: DirectAdmin to DirectAdmin

This is normally the simplest route when the old VPS and the new VPS both use DirectAdmin. DirectAdmin account backups can include website files, databases, email accounts, mail data, FTP accounts, DNS records and other account-level settings. You create the backup on the source server, copy it to the destination and restore it through DirectAdmin.

A sensible DirectAdmin migration sequence is:

1. Create user or reseller backups on the old server.
2. Transfer the backup archives to the new server.
3. Restore the accounts in DirectAdmin.
4. Compare PHP versions and required PHP extensions.
5. Test each website using a local hosts-file entry.
6. Run a final mail and dynamic-data synchronisation where required.
7. Change the relevant DNS records.

The restore process removes much of the manual work, but it does not remove the need to test. A restored WordPress site may still rely on a PHP extension that is not installed. A mail domain may still need the correct SPF, DKIM, DMARC and reverse-DNS setup. A custom application may still need a system service that lives outside the DirectAdmin user backup.

Route B: Control panel to a different control panel

Moving from cPanel or Plesk to DirectAdmin needs more checking because account structures, configuration files and backup formats are different. Migration tools can help, but you should still verify website paths, database users, email forwarders, DNS zones, PHP versions, cron jobs and SSL after the restore.

Route C: General Linux VPS to a clean Linux VPS

This is the route covered in greatest depth below. It works whether the source uses Rocky Linux, AlmaLinux, Ubuntu or Debian, and whether the destination uses the same distribution or a different one. The main rule is to move application data and deliberately recreated configuration rather than copying the complete root filesystem.

Rocky Linux, AlmaLinux, Ubuntu and Debian command differences

The core tools used for a migration—SSH, rsync, tar, database dump utilities and systemd—work similarly across all four operating systems. Most differences appear when installing packages, naming Apache services and opening firewall ports.

AlmaLinux and Rocky Linux are close enough that the migration commands in this guide are generally identical. Ubuntu and Debian also share the same APT package workflow, although package versions and default modules may differ. Always check the exact software versions on the source before installing the destination stack.

sudo dnf update -y
sudo dnf install -y rsync tar gzip unzip openssh-clients curl wget

sudo apt update
sudo apt upgrade -y
sudo apt install -y rsync tar gzip unzip openssh-client curl wget

Step 1: Create a complete VPS inventory

A migration fails most often because something was forgotten, not because rsync stopped working. Create a written inventory before building the destination. Record every domain, application, database, mailbox, scheduled task and background service.

Useful source-server inventory commands

# Operating system and kernel
cat /etc/os-release
uname -a

# Disk and memory
lsblk -f
df -hT
free -h

# Listening network ports
sudo ss -lntup

# Running and enabled services
systemctl --type=service --state=running
systemctl list-unit-files --state=enabled

# PHP and web-server versions
php -v 2>/dev/null || true
php -m 2>/dev/null || true
apachectl -v 2>/dev/null || httpd -v 2>/dev/null || true
nginx -v 2>&1 || true

# Database versions
mariadb --version 2>/dev/null || mysql --version 2>/dev/null || true
psql --version 2>/dev/null || true

# Scheduled jobs
sudo crontab -l 2>/dev/null || true
for user in $(cut -d: -f1 /etc/passwd); do
  sudo crontab -u "$user" -l 2>/dev/null && echo "--- $user ---"
done
sudo find /etc/cron.d /etc/cron.daily /etc/cron.hourly -maxdepth 1 -type f -print

Save the outputs into your migration notes. Do not assume you will remember a custom port or a small cron job later. Also check application-specific files such as WordPress wp-config.php, Laravel .env files and Node.js process-manager configuration.

Step 2: Prepare the Website Hosts UK VPS or VDS

Choose a destination with enough CPU, RAM and NVMe storage for the current workload plus room to grow. A VDS may be a better destination when the workload needs dedicated CPU resources and more predictable compute performance. Deploy one of the available Linux images—Rocky Linux, AlmaLinux, Ubuntu or Debian—and record the new public IP address.

Set the hostname and install updates

sudo hostnamectl set-hostname server.example.com
hostnamectl

# Rocky Linux / AlmaLinux
sudo dnf update -y

# Ubuntu / Debian
sudo apt update && sudo apt upgrade -y

Use a real fully qualified hostname that resolves to the server. For a mail server, arrange reverse DNS so the public IP points back to the mail hostname. Forward and reverse DNS alignment is important for mail reputation.

Create an administration user and add your SSH key

sudo useradd -m -U -s /bin/bash migrationadmin
sudo passwd migrationadmin

# Rocky Linux / AlmaLinux: add to wheel
sudo usermod -aG wheel migrationadmin

# Ubuntu / Debian: add to sudo
sudo usermod -aG sudo migrationadmin

sudo install -d -m 700 -o migrationadmin -g migrationadmin /home/migrationadmin/.ssh
sudo nano /home/migrationadmin/.ssh/authorized_keys
sudo chmod 600 /home/migrationadmin/.ssh/authorized_keys
sudo chown migrationadmin:migrationadmin /home/migrationadmin/.ssh/authorized_keys

Test the new user in a second terminal before changing SSH settings. Do not close your working root session until key-based access has been confirmed.

Open only the ports you actually need

sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Mail, DNS, control-panel and application ports should only be opened when those services are actually being used. When running DirectAdmin or CSF, follow the control panel's firewall requirements rather than building a conflicting second firewall configuration.

Step 3: Perform the first website-file transfer

The first transfer can normally happen while the source websites remain live. It copies the bulk of the data so the final maintenance window only needs to transfer files that changed recently.

Set up passwordless SSH from the destination

ssh-keygen -t ed25519 -f ~/.ssh/vps-migration -C "vps-migration"
ssh-copy-id -i ~/.ssh/vps-migration.pub root@OLD_SERVER_IP
ssh -i ~/.ssh/vps-migration root@OLD_SERVER_IP

Where root SSH is disabled, use an administrative source user and sudo. Keep the migration key private, restrict access to it and remove it from the old server after the work is complete.

Copy a single website safely

sudo rsync -aHAX --numeric-ids --info=progress2 \
  -e "ssh -i /root/.ssh/vps-migration" \
  root@OLD_SERVER_IP:/var/www/example.com/ \
  /var/www/example.com/

The trailing slashes matter: the example copies the contents of the source directory into the destination directory. -a preserves the normal archive attributes, -HAX preserves hard links, ACLs and extended attributes, and --numeric-ids preserves numeric ownership values. That last option is useful only when user and group IDs are intentionally aligned; otherwise recreate the correct ownership on the destination after the copy.

Copy several common hosting directories

sudo rsync -aHAX --numeric-ids --info=progress2 \
  -e "ssh -i /root/.ssh/vps-migration" \
  root@OLD_SERVER_IP:/home/ /home/

sudo rsync -aHAX --numeric-ids --info=progress2 \
  -e "ssh -i /root/.ssh/vps-migration" \
  root@OLD_SERVER_IP:/var/www/ /var/www/

Step 4: Export and restore databases correctly

Databases must be transferred in a consistent state. Never assume that an rsync copy of /var/lib/mysql from a running server is a valid backup. Database files can change during the copy and internal formats can differ between versions.

Check database versions first

mariadb --version 2>/dev/null || mysql --version
sudo mariadb -e "SELECT VERSION();" 2>/dev/null || sudo mysql -e "SELECT VERSION();"

Moving to the same or a newer compatible version is usually easier than moving backwards. If the versions differ significantly, test the restore before the live cutover and review application compatibility.

Export one MariaDB or MySQL application database

sudo mariadb-dump \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --default-character-set=utf8mb4 \
  database_name | gzip > /root/database_name.sql.gz

On systems where the command is named mysqldump, replace mariadb-dump with mysqldump. The --single-transaction option reduces locking for transactional tables, while routines, triggers and events include database objects that a basic export can miss.

Transfer and restore the database

# Run on the new VPS
scp -i /root/.ssh/vps-migration \
  root@OLD_SERVER_IP:/root/database_name.sql.gz \
  /root/

# Create the empty database and application user
sudo mariadb <<'SQL'
CREATE DATABASE database_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'database_user'@'localhost' IDENTIFIED BY 'USE-A-STRONG-UNIQUE-PASSWORD';
GRANT ALL PRIVILEGES ON database_name.* TO 'database_user'@'localhost';
FLUSH PRIVILEGES;
SQL

# Restore the data
gunzip -c /root/database_name.sql.gz | sudo mariadb database_name

Update the application's database configuration when the database name, username or password changes. For WordPress, that means checking DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php. For Laravel and similar frameworks, check the relevant .env values.

PostgreSQL example

# Old VPS
sudo -u postgres pg_dump -Fc database_name > /root/database_name.dump

# Copy to new VPS
scp -i /root/.ssh/vps-migration \
  root@OLD_SERVER_IP:/root/database_name.dump \
  /root/

# New VPS
sudo -u postgres createdb database_name
sudo -u postgres pg_restore --clean --if-exists \
  --dbname=database_name /root/database_name.dump

PostgreSQL roles are separate from database contents. Recreate the required roles and permissions, or export global objects with pg_dumpall --globals-only and review the output before restoring it.

Step 5: Recreate the web server and PHP environment

Install a compatible web stack on the destination before copying configuration. The migration tools are similar across the operating systems, but Apache names and configuration layouts differ.

Install Apache, PHP and MariaDB

sudo dnf install -y httpd mariadb-server php php-cli php-fpm php-mysqlnd \
  php-gd php-mbstring php-xml php-curl php-zip
sudo systemctl enable --now httpd mariadb php-fpm

sudo apt update
sudo apt install -y apache2 mariadb-server php php-cli php-fpm php-mysql \
  php-gd php-mbstring php-xml php-curl php-zip
sudo systemctl enable --now apache2 mariadb

# PHP-FPM service names are versioned on Ubuntu and Debian. Find yours first:
systemctl list-unit-files --type=service 'php*-fpm.service'
# Then enable the service shown, for example:
sudo systemctl enable --now php8.3-fpm

These commands install distribution-provided PHP packages. They do not guarantee the same PHP version as the old VPS. Compare the application's supported PHP versions and install the correct repository or control-panel build where necessary. Do not upgrade a production application across several PHP major versions as an untested part of the same migration.

Compare PHP extensions and limits

php -v
php -m | sort
php --ini
php -i | grep -E 'memory_limit|upload_max_filesize|post_max_size|max_execution_time'

Move virtual hosts deliberately

Nginx configuration is commonly stored under /etc/nginx/. Apache configuration is commonly under /etc/httpd/ on Rocky Linux and AlmaLinux, and under /etc/apache2/ on Ubuntu and Debian. Copy individual virtual-host files into a staging directory, inspect paths and directives, then place adapted files in the destination configuration tree.

# Apache on Rocky Linux / AlmaLinux
sudo apachectl configtest
sudo systemctl reload httpd

# Apache on Ubuntu / Debian
sudo apache2ctl configtest
sudo systemctl reload apache2

# Nginx on any supported OS
sudo nginx -t
sudo systemctl reload nginx

Never reload a web server after copying configuration without first running its configuration test. A missing module, incorrect certificate path or distribution-specific directive can stop the service from reloading.

Step 6: Migrate mailboxes, aliases and stored email

Email deserves its own migration plan. A website can appear correct while new messages are still being delivered to the old server. Record all mail domains, mailbox names, aliases, forwarders, autoresponders and storage usage before changing MX records.

DirectAdmin email migration

DirectAdmin account backups are normally the preferred method when both servers use DirectAdmin. Restore the user accounts, verify mailboxes and then compare DNS records. Check that DKIM is enabled on the new server and update SPF, DKIM and DMARC where the mail hostname or IP changes.

Maildir migration between compatible Dovecot servers

If both systems use compatible Maildir storage, you can perform an initial rsync while mail remains active and a final rsync during cutover. Paths vary by control panel and configuration, so identify the real mail root first.

sudo rsync -aHAX --numeric-ids --info=progress2 \
  -e "ssh -i /root/.ssh/vps-migration" \
  root@OLD_SERVER_IP:/home/example/imap/example.com/ \
  /home/example/imap/example.com/

Recreate mailbox accounts before transferring mail, then verify ownership and permissions. If the source and destination use different UID values, preserving numeric IDs may create the wrong ownership. In that case, restore the accounts first and apply the destination ownership after copying.

IMAP-to-IMAP synchronisation

When the source and destination mail layouts differ, an IMAP synchronisation tool is often safer than copying storage files. The tool logs into both mailboxes and copies messages through IMAP. This works across different control panels and can be repeated after the DNS change to collect late-arriving messages.

imapsync \
  --host1 old-mail.example.com \
  --user1 user@example.com \
  --password1 'OLD-MAILBOX-PASSWORD' \
  --ssl1 \
  --host2 new-mail.example.com \
  --user2 user@example.com \
  --password2 'NEW-MAILBOX-PASSWORD' \
  --ssl2 \
  --automap \
  --syncinternaldates

Avoid placing real mailbox passwords in shell history. Use a secure password-file method supported by your chosen tool, restrict file permissions and remove temporary credentials after the migration.

Mail DNS records to review

• MX records for the receiving mail hostname.
• A or AAAA records for the mail hostname.
• SPF records that contain the old sending IP.
• DKIM records if new keys are generated.
• DMARC policy and reporting addresses.
• PTR or reverse DNS for the new outbound-mail IP.

Step 7: Prepare DNS and SSL

Lower DNS TTL before the move

Reduce the TTL on records that will change at least several hours before the cutover, preferably earlier. A lower TTL does not force every resolver to update instantly, but it can reduce the time old answers are cached after you change the IP.

Typical records to review include:

• The root-domain A record.
• The www record.
• Application or API subdomains.
• Mail A and MX records.
• SPF records containing an IP address.

Prefer reissuing Let's Encrypt certificates

It is normally cleaner to request fresh certificates on the new server once the domain can validate there. If testing before DNS cutover, use the control panel's DNS validation route where available, temporarily point validation records to the new server or wait until cutover to issue the live certificate.

Copying /etc/letsencrypt can work in some like-for-like migrations, but renewal configuration and web-server paths must match. Do not assume copied certificates will renew correctly without testing certbot renew --dry-run or the control panel's equivalent renewal process.

Step 8: Recreate cron jobs, timers and custom services

Export user crontabs

sudo crontab -l > /root/root-crontab.txt 2>/dev/null || true
crontab -l > ~/user-crontab.txt 2>/dev/null || true
sudo tar -czf /root/system-cron-files.tar.gz /etc/cron.d /etc/cron.daily /etc/cron.hourly

Review every command before importing it. Paths, PHP binaries, usernames and backup destinations may be different on the new server. Do not enable duplicate jobs while both servers are live; two billing jobs, queue workers or scheduled emails can process the same work twice.

Find custom systemd units and timers

sudo find /etc/systemd/system -maxdepth 2 -type f -print
systemctl list-timers --all
systemctl list-unit-files --type=service --state=enabled

Copy custom unit files individually, verify user accounts, working directories, environment files and executable paths, then reload systemd and test the service.

sudo systemctl daemon-reload
sudo systemctl enable --now example-worker.service
sudo systemctl status example-worker.service
sudo journalctl -u example-worker.service --since "10 minutes ago"

Step 9: Test the new VPS before changing public DNS

A hosts-file entry lets only your computer resolve a domain to the new IP. Normal visitors continue reaching the old server, so you can test privately without changing public DNS.

Windows hosts file

Open Notepad as Administrator and edit:

C:\Windows\System32\drivers\etc\hosts

NEW_SERVER_IP example.com www.example.com

Then clear the Windows DNS cache:

ipconfig /flushdns

Linux or macOS hosts file

sudo nano /etc/hosts

NEW_SERVER_IP example.com www.example.com

What to test

• Homepage, service pages and deep links.
• WordPress or application administration logins.
• Contact forms and outbound application email.
• File uploads, image processing and writable directories.
• Database inserts, updates and search functions.
• Ecommerce basket, checkout and payment callback paths.
• Redirects, canonical URLs and HTTPS behaviour.
• API endpoints, webhooks, queue workers and scheduled jobs.
• Web-server, PHP and application error logs.

Useful HTTP checks

curl -I --resolve example.com:443:NEW_SERVER_IP https://example.com/
curl -I --resolve www.example.com:443:NEW_SERVER_IP https://www.example.com/

The --resolve option sends the request to the new IP while retaining the correct hostname for HTTPS and virtual-host selection. This is especially useful for automated checks.

Step 10: Complete the final sync and DNS cutover

The first file copy and database restore were for testing. The final synchronisation captures content added after that first copy. Schedule a short maintenance window for dynamic sites so no orders, uploads or database changes are lost.

sudo rsync -aHAX --numeric-ids --info=progress2 \
  -e "ssh -i /root/.ssh/vps-migration" \
  root@OLD_SERVER_IP:/var/www/example.com/ \
  /var/www/example.com/

sudo rsync -aHAX --numeric-ids --delete --dry-run \
  -e "ssh -i /root/.ssh/vps-migration" \
  root@OLD_SERVER_IP:/var/www/example.com/ \
  /var/www/example.com/

Step 11: Monitor the new server after cutover

Watch the new VPS closely during the first hours and days. Check system load, disk usage, memory, failed services, web errors, database errors, mail queues and application logs.

uptime
free -h
df -hT
df -ih
systemctl --failed
sudo journalctl -p 0..3 --since "2 hours ago"
sudo ss -lntup

# Rocky Linux / AlmaLinux Apache
sudo systemctl status httpd
sudo journalctl -u httpd --since "1 hour ago"

# Ubuntu / Debian Apache
sudo systemctl status apache2
sudo journalctl -u apache2 --since "1 hour ago"

# Nginx, PHP-FPM and MariaDB
sudo systemctl status nginx 2>/dev/null || true
sudo systemctl status php-fpm 2>/dev/null || true
systemctl --no-pager --type=service --all | grep -E 'php[0-9.]+-fpm' || true
sudo systemctl status mariadb
sudo journalctl -u mariadb --since "1 hour ago"

Verify DNS from outside your own network

dig +short A example.com
dig +short A www.example.com
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com

Check from more than one resolver if possible. DNS caches update at different times, so seeing the new IP from your computer does not prove that every visitor is using the new VPS yet.

Remove temporary migration access

After the migration has been accepted:

• Remove the temporary migration SSH key from the old VPS.
• Delete temporary SQL dumps and mailbox credential files securely.
• Remove broad firewall allowances created for migration.
• Confirm automated backups are running on the new server.
• Store a final independent backup before cancelling the old VPS.
• Return DNS TTL values to your normal policy.

Worked example: moving a WordPress site with minimal downtime

Imagine that example.com runs WordPress on the old VPS. Its files live in /var/www/example.com/public_html, and its MariaDB database is named example_wp. The target is a clean Website Hosts UK VPS.

Initial copy while the site remains live

sudo mkdir -p /var/www/example.com/public_html
sudo rsync -aHAX --info=progress2 \
  -e "ssh -i /root/.ssh/vps-migration" \
  root@OLD_SERVER_IP:/var/www/example.com/public_html/ \
  /var/www/example.com/public_html/

Initial database export and restore

sudo mariadb-dump --single-transaction --routines --triggers --events \
  example_wp | gzip > /root/example_wp-initial.sql.gz

scp -i /root/.ssh/vps-migration \
  root@OLD_SERVER_IP:/root/example_wp-initial.sql.gz /root/

gunzip -c /root/example_wp-initial.sql.gz | sudo mariadb example_wp

Configure the virtual host, PHP-FPM pool and database credentials, then test with a hosts-file entry. Log into WordPress, open several pages, upload a test image, submit a form and check the PHP and web-server error logs.

Final maintenance window

1. Enable WordPress maintenance mode or temporarily restrict public writes.
2. Run the second rsync.
3. Export example_wp again.
4. Restore the final dump on the new VPS.
5. Change the A records to the new IP.
6. Issue or verify the live SSL certificate.
7. Disable maintenance mode on the new VPS.
8. Monitor logs and forms.

Because the bulk file copy and full test happened beforehand, the maintenance window is mainly the final changed files and fresh database. That is how the migration can remain careful without requiring a long outage.

What not to do during a VPS migration

• Do not copy a live database data directory and assume it is consistent.
• Do not overwrite the destination's network configuration with files from another provider.
• Do not change DNS before testing the websites and application writes.
• Do not run duplicate cron jobs on both servers without understanding the effect.
• Do not cancel the old VPS immediately after the DNS change.
• Do not expose passwords in shell history or leave temporary dumps world-readable.
• Do not combine an unnecessary application upgrade with the migration unless you have tested both changes together.

VPS migration checklist

Choosing between a VPS and VDS for the destination

The migration process is similar for both products. Choose a Website Hosts UK VPS when a flexible virtual server with root access fits the workload. Choose a VDS when dedicated CPU resources and more predictable compute performance are important. Storage, memory and application requirements still need to be sized for the workload in either case.

Before ordering, review the source server's actual memory use, disk use and CPU patterns rather than copying the old plan name. An oversized old VPS may be using very little, while a small VPS may be regularly constrained. Use real measurements to select the destination.