Migrating Your Entire VPS to a New Server Without Downtime

Moving to a new VPS - a bigger plan, a different provider, or a fresh Getwebup instance - is one of those jobs that looks simple until you're two hours in and remember cron jobs, mail, and firewall rules all live on the old box too. Here's how to move the whole server, not just the website, without your visitors ever noticing.

Why "Just Copy the Website" Isn't Enough

Most VPS migration guides only cover the web files and the database. That's fine for a single WordPress site, but a real server usually carries more than that:

• Cron jobs (backups, WP-Cron workarounds, report generators)
• Mail - Postfix/Exim queues, mailboxes, SPF/DKIM keys tied to the old IP
• System users and their SSH keys
• Firewall rules (UFW/CSF) and fail2ban jail state
• SSL certificates and renewal hooks (Certbot/AutoSSL)
• Multiple sites or apps sharing the one box

Miss any of these and the new server "works" for a day, then something quietly breaks - a report cron that never fires again, or outbound mail that starts bouncing because the new IP has no reputation and no matching PTR record.

Step 1: Inventory the Old Server Before You Touch Anything

Don't start copying files yet. Spend twenty minutes writing down what's actually running:

# List enabled services
systemctl list-unit-files --state=enabled

# List installed packages (Debian/Ubuntu)
dpkg --get-selections > /root/old-packages.txt

Then check crontab -l for each account you know runs scheduled jobs (your own user and any app users), and note which system users actually have a login shell rather than a service account - those are the ones with real home directories and SSH keys worth carrying over.

If it's a cPanel VPS, this part is easier - WHM's Transfer Tool can pull entire cPanel accounts (files, mail, databases, DNS zones, cron jobs) to a new server in one job. For a plain unmanaged VPS, you're doing the inventory and the copy by hand, which is what the rest of this guide covers.

Step 2: Provision and Harden the New Server First

Set up the new VPS completely before you move a single byte of data:

• Match the OS version (or go newer, never older)
• Create your sudo user and install your public key before disabling password auth
• Install the same stack - Nginx/Apache, PHP-FPM version, MySQL/MariaDB version, Redis if you use it
• Set up UFW or CSF with the same rules as the old box

Getting SSH access locked down correctly on the new server before you route any real traffic to it matters - it's worth reading through SSH hardening for a VPS if you haven't already set that up on the old server either.

Step 3: Copy the Data With rsync, Not a Single tar Dump

rsync over SSH is the right tool here - it's resumable, it shows progress, and you can run it more than once without re-copying everything.

# From the new server, pull from the old one
rsync -avz --progress -e ssh root@OLD_SERVER_IP:/var/www/ /var/www/
rsync -avz --progress -e ssh root@OLD_SERVER_IP:/etc/nginx/sites-available/ /etc/nginx/sites-available/
rsync -avz --progress -e ssh root@OLD_SERVER_IP:/home/ /home/

For MySQL/MariaDB, dump per-database instead of copying raw data files - it's safer across MySQL versions:

mysqldump --single-transaction yourdatabase | gzip > yourdatabase.sql.gz

Run that once per database (skip the built-in information_schema, performance_schema, mysql, and sys schemas - those come with the server, not with your data).

Then scp or rsync those dumps to the new server and import them. If a database is large enough that mysqldump is painfully slow, see our guide on backing up MySQL on a VPS with mysqldump for the flags that speed it up.

For mail, copy the Maildir folders (not the queue - let old mail finish delivering on the old server):

rsync -avz --progress -e ssh root@OLD_SERVER_IP:/home/*/mail/ /home/

Step 4: Rebuild What Doesn't Copy Cleanly

Some things move better rebuilt than copied:

Step 5: Test on the New Server Before Any DNS Change

Point your local machine at the new server without touching DNS yet, using a hosts file entry:

# On your local machine (not the server)
echo "NEW_SERVER_IP yourdomain.com www.yourdomain.com" | sudo tee -a /etc/hosts

Browse the site, log into wp-admin, test a form submission, check a cron-dependent feature. Remove the hosts entry when you're done so you don't forget it's there next week.

Step 6: Lower DNS TTL Ahead of the Cutover

Do this at least 24-48 hours before the actual switch. Log into cPanel's Zone Editor or your DNS provider and drop the TTL on your A record to 300 seconds (5 minutes). Full guidance is in our DNS propagation explainer, but the short version: a low TTL now means a fast, low-risk cutover later instead of a multi-hour window where some visitors hit the old server and some hit the new one.

Step 7: Cut Over

1. Do a final rsync pass to catch anything changed since Step 3 (files and a fresh database dump)
2. Set the old server to read-only or put up a maintenance page, so nothing writes to it during the switch
3. Update the A record (and AAAA if you use IPv6) to the new server's IP
4. Watch traffic hit the new server: tail -f /var/log/nginx/access.log
5. Once traffic has fully shifted (give it the TTL window plus a buffer), update MX records and mail client settings if the mail server moved too

Step 8: Keep the Old Server Alive for a Week

Don't cancel the old VPS immediately. DNS caching outside your control - ISP resolvers, some corporate networks, stale mobile DNS - can hang on to the old IP longer than your TTL suggests. Keep the old server running (even just for logging stragglers) for 5-7 days, then decommission it.

Prevention: Make the Next Migration Easier

• Keep infrastructure as code where you can - even a simple provisioning script beats rebuilding by memory
• Document custom cron jobs and systemd services somewhere outside the server itself
• Set up automated off-site backups so a migration is a restore job, not a from-scratch rebuild
• Use a config management tool (Ansible is the common choice) once you're running more than two or three servers

If this all sounds like more risk than you want to carry solo, Getwebup's support team handles full VPS-to-VPS migrations as part of onboarding - including the mail and DNS cutover - so open a ticket before you start moving anything by hand.