VPS Migration Guide

How to Migrate Your VPS to Website Hosts UK

A complete step-by-step guide to moving websites, databases, email, DNS, SSL and server workloads to a new Website Hosts UK VPS or VDS.

View VPS Hosting Compare VPS & VDS
Plan first, copy second

Moving a VPS is not simply a matter of copying every file from one server to another. A reliable migration keeps databases consistent, preserves website permissions, moves stored email, recreates services, updates DNS and gives you a way back if something does not work as expected.

This guide explains the complete process in practical terms. It covers DirectAdmin-to-DirectAdmin migrations and general Linux server migrations, with command differences for Rocky Linux, AlmaLinux, Ubuntu and Debian. Work through it in order, replace every example placeholder with your real values and never cancel the old VPS until the new one has been fully tested.

1

Inventory

Record websites, databases, mailboxes, DNS, PHP versions, cron jobs and custom services.

2

Build and copy

Prepare a clean destination, transfer files and restore database-aware backups.

3

Test privately

Use a hosts-file entry to test the new VPS before normal visitors are sent to it.

4

Final sync and DNS

Synchronise recent changes, update DNS and monitor before retiring the old server.

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.

Important safety warning

The examples below are templates, not commands to paste blindly. Test backups before relying on them, confirm paths on both servers and keep an independent copy of important data. Do not use rsync --delete until you have reviewed the source and destination carefully. A reversed source and destination can remove the wrong files.

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.

Task Rocky Linux / AlmaLinux Ubuntu / Debian
Update packages sudo dnf update -y sudo apt update && sudo apt upgrade -y
Install migration tools sudo dnf install -y rsync tar gzip openssh-clients sudo apt install -y rsync tar gzip openssh-client
Apache package/service httpd apache2
Common Apache configuration /etc/httpd/ /etc/apache2/
Default firewall tool Usually firewalld Often UFW when enabled
Enable a service sudo systemctl enable --now SERVICE_NAME

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.

Rocky Linux or AlmaLinux: install common migration tools 
sudo dnf update -y
sudo dnf install -y rsync tar gzip unzip openssh-clients curl wget
Ubuntu or Debian: install common migration tools 
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.

Area What to record
WebsitesDomains, document roots, application type, owner and current PHP version.
DatabasesEngine, version, database names, users, approximate size and application connection details.
EmailMail domains, mailboxes, aliases, forwarders, quotas, mailing lists and stored-mail size.
Web stackApache or Nginx, virtual hosts, redirects, reverse proxies and enabled modules.
PHPVersion, extensions, memory limits, upload limits, FPM pools and custom php.ini settings.
DNSA, AAAA, MX, CNAME, TXT, SRV, SPF, DKIM and DMARC records.
AutomationUser crontabs, files in /etc/cron.d, timers, queues and worker services.
SecuritySSH users, public keys, firewall ports, allowlists and fail2ban or CSF rules.
Other servicesRedis, Memcached, Docker, Node.js, Python apps, monitoring and backup software.

Useful source-server inventory commands

Run on the old VPS 
# 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

All four supported operating-system families 
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

Run on the new VPS 
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

Rocky Linux / AlmaLinux with firewalld 
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
Ubuntu / Debian with UFW enabled 
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

Run on the new VPS 
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

Copy a single website safely

Run on the new VPS 
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

Example only: adjust paths to match your source 
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/

Do not copy these blindly

Avoid copying /etc, /boot, /proc, /sys, /dev, /run or the entire root filesystem over a clean VPS. Those locations contain operating-system, network, device and provider-specific data. Copy individual configuration files only after comparing them with the destination version.

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

Run on both servers 
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

Run on the old VPS 
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

Transfer from the old VPS, then restore on the new VPS 
# 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

Custom-format PostgreSQL backup and restore 
# 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

Rocky Linux / AlmaLinux example 
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
Ubuntu / Debian example 
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

Run on both servers and compare the output 
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.

Validate before reloading 
# 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.

Example Maildir transfer—replace paths carefully 
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.

Illustrative imapsync command after installing the tool 
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

Old VPS 
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

Inventory custom services 
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.

New VPS 
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:

Windows path and example entry 
C:\Windows\System32\drivers\etc\hosts

NEW_SERVER_IP example.com www.example.com

Then clear the Windows DNS cache:

Windows Command Prompt 
ipconfig /flushdns

Linux or macOS hosts file

Linux or macOS 
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

Test directly against the new IP without changing DNS 
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.

Final cutover sequence

1. Put dynamic applications into maintenance mode

Stop new writes where practical. For WordPress and WooCommerce, use a maintenance page and avoid accepting orders during the final database transfer. Stop queue workers or scheduled jobs that could modify data.

Final cutover sequence

2. Run a final file synchronisation

Run on the new VPS 
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/

Add --delete only after using --dry-run and confirming that destination-only files should be removed.

Review deletions first 
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/
Final cutover sequence

3. Take a fresh database export

Export the database again after writes are stopped, transfer the fresh file and restore it over the tested destination database. This final export is the authoritative copy used at launch.

Final cutover sequence

4. Synchronise recent email

Run the final Maildir or IMAP sync. Keep the old mail service available during DNS propagation so late messages can be collected with another sync if necessary.

Final cutover sequence

5. Change DNS

Update the relevant A, AAAA, MX and TXT records. Check that the new IP is not accidentally left out of SPF and that a new DKIM key is published when the destination generated one.

Final cutover sequence

6. Remove the local hosts-file override

Remove your temporary entry so your own computer follows public DNS like everyone else. This helps you detect any DNS or certificate problem that was hidden by the test override.

Keep the old VPS available

Do not terminate the old server immediately after changing DNS. Keep it available long enough to confirm that websites, APIs, cron jobs and email are working correctly on the new VPS. Disable unnecessary writes on the old applications, but retain access for rollback and final comparison.

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.

Core post-migration checks 
uptime
free -h
df -hT
df -ih
systemctl --failed
sudo journalctl -p 0..3 --since "2 hours ago"
sudo ss -lntup
Common service checks—use the names installed on your OS 
# 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

DNS checks 
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

New VPS 
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

Old VPS 
sudo mariadb-dump --single-transaction --routines --triggers --events \
  example_wp | gzip > /root/example_wp-initial.sql.gz
New VPS 
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

Before cutover

  • Independent backup completed.
  • Inventory written and reviewed.
  • Destination resources checked.
  • Software versions compared.
  • Initial files and databases copied.
  • Mailboxes and DNS records prepared.
  • Hosts-file testing passed.
  • Final maintenance window agreed.

After cutover

  • Public DNS resolves to the new VPS.
  • SSL is valid and renews correctly.
  • Forms and application email work.
  • Mail arrives on the new server.
  • Cron jobs and workers run once.
  • No failed services or disk alerts.
  • Backups run on the destination.
  • Old VPS retained for rollback.

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.

Common questions

VPS Migration FAQs

You can copy a large amount of data with rsync, but a safe migration also needs database exports, service configuration, email synchronisation, DNS changes, testing and a rollback plan. A complete root-filesystem copy can also transfer incompatible network and boot settings.

Create DirectAdmin account backups on the old server, transfer them to the new server and restore the accounts. Then verify PHP compatibility, websites, databases, mailboxes, DNS and SSL before changing live records.

Core SSH, rsync, tar and database commands are similar. Rocky Linux and AlmaLinux generally use dnf and the httpd service name, while Ubuntu and Debian use apt and normally call Apache apache2.

Copy most files and perform a test restore while the old server remains live. During a short final maintenance window, synchronise changed files, export the database again, restore it and then update DNS.

Normally no. Copying a live database directory can produce an inconsistent backup and can fail when versions differ. Use mariadb-dump, mysqldump, replication or another database-aware backup method.

Add a temporary hosts-file entry on your own computer that maps the domain to the new VPS IP. Your computer reaches the new server while normal visitors continue reaching the old one.

Keep it until public DNS has changed, websites and mail are working, scheduled jobs are confirmed and no important data is missing. Retain a final independent backup after cancellation.

Yes. The workload-transfer process is largely the same. A VDS is worth considering when dedicated CPU resources and predictable compute performance are important to the application.

Ready to Deploy the New Server?

Choose a Website Hosts UK VPS or VDS, deploy Rocky Linux, AlmaLinux, Ubuntu or Debian, then use this guide to move your workloads carefully.

Configure VPS Hosting Configure VDS Hosting