Moving to a new VPS

Part 4 of the Running your VPS series.

There are plenty of reasons to move servers: a bigger plan, a better location, a sale deal that replaces an older plan, or a fresh start on a newer operating system. Moving is not automatic. You build the new server, copy your data across, test it and then switch your domain over.

This guide walks through that in order, with a checklist so nothing is left behind. Done carefully, most small sites move with only a few minutes of downtime, or none. It assumes Ubuntu or Debian on both servers, and a website with a MySQL or MariaDB database as the example. The same steps apply to other apps with small changes.

What is in this guide

• Before you start
• 1. Make a list of what the old server does
• 2. Lower your DNS TTL
• 3. Build and secure the new server
• 4. Copy files
• 5. Copy databases
• 6. Copy the rest
• 7. Test before you switch
• 8. The final sync and the switch
• 9. Keep the old server for a while
• Troubleshooting
• Limits
• When to step up
• More in the series

Before you start

• SSH access to both servers, with sudo on each.
• Access to wherever your domain's DNS records live. See domains and DNS explained.
• A recent backup of the old server, kept somewhere other than either server.
• A quiet time for the final switch, when few people use the site.
• The old server's renewal date. Plan to finish well before it, so you do not pay for an extra cycle by accident.

In the commands, replace OLD_IP and NEW_IP with the two servers' addresses, alex with your username and mysite with your database name.

1. Make a list of what the old server does

Most problems after a move come from something nobody remembered. Spend ten minutes making a list. On the old server:

systemctl list-units --type=service --state=running
sudo ss -tlnp
crontab -l
sudo crontab -l
ls /etc/nginx/sites-enabled
docker ps

These show running services, open ports, scheduled jobs for your user and for root, nginx sites and any Docker containers. Skip any command for software you do not use. Write down:

Item	Example, for illustration only
Websites and their folders	example.com in /var/www/example
Databases	mysite in MariaDB
Config files you changed	nginx sites, PHP settings, firewall rules
Scheduled jobs	A nightly backup script in crontab
Secrets	Env files and API keys
Other services	A VPN, a bot, a Docker app
Anything that trusts the old IP	API allowlists, firewall rules on other servers

2. Lower your DNS TTL

At least a day before the switch, lower the TTL on your domain's A and AAAA records to something short, such as 300 seconds. When you switch, visitors then pick up the new address within minutes instead of hours. You can raise it again a few days after the move.

3. Build and secure the new server

Set up the new server as if it were brand new, because it is. Update it, create your user, add SSH keys and turn on the firewall. Your first hour on a new RackNerd VPS walks through it.

Then install the same software as the old server: web server, PHP or your language runtime, the database and anything else on your list. Use the same major versions where you can, or test carefully if you are upgrading as part of the move.

4. Copy files

For a typical website folder, pack it up on the old server:

sudo tar czf ~/site.tar.gz -C /var/www/example .

Copy it across from the new server, then unpack it into place:

scp alex@OLD_IP:site.tar.gz ~/
sudo mkdir -p /var/www/example
sudo tar xzf ~/site.tar.gz -C /var/www/example

Check that the files are owned by the right user for your web server. On Debian and Ubuntu, nginx and PHP usually run as www-data.

For large folders, rsync is better, because it can be run again later and only sends what changed. It needs to be installed on both servers. A simple form, run on the new server, is rsync -a alex@OLD_IP:/var/www/example/ ~/example/, then move the folder into place with sudo. Your user on the old server needs permission to read the files.

5. Copy databases

Do not copy a running database's files. Export it instead. On the old server:

sudo mysqldump --single-transaction --databases mysite > ~/mysite.sql

On the new server, copy the file across and import it:

scp alex@OLD_IP:mysite.sql ~/
sudo mysql < ~/mysite.sql

Create the database user on the new server with the same name and password your app uses, as your database's documentation explains. For PostgreSQL, use pg_dump and psql instead.

Delete the dump files from both servers when the move is finished. They contain your whole database.

6. Copy the rest

• Web server config. Copy your site files from /etc/nginx/sites-available, check them and enable them. Run sudo nginx -t before reloading.
• Env files and secrets. Copy them over SSH, not by email or chat. Keep them readable only by the app's user, with chmod 600.
• Scheduled jobs. Recreate them with crontab -e, and copy any scripts they run.
• Docker apps. Copy the folder with the Compose file and the data volumes. Stop the containers on the old server before copying their data, so nothing changes mid-copy.
• SSL certificates. You can issue new ones on the new server after the switch, or copy the existing certificate folder across. Free certificate tools usually need the domain to point at the new server first.
• Firewall rules. Open the same ports as before, and no more.

7. Test before you switch

You can see the site on the new server before anyone else does, by telling your own computer to use the new IP address for your domain. Add a line to your computer's hosts file:

NEW_IP example.com www.example.com

On macOS and Linux the file is /etc/hosts. On Windows it is C:\Windows\System32\drivers\etc\hosts, edited as administrator. Now your browser goes to the new server, while everyone else still sees the old one.

Click through the site: log in, submit a form, upload a file, check pages that use the database. Expect a certificate warning if the new server does not have a certificate yet. Remove the hosts file line when you finish testing.

8. The final sync and the switch

Between your first copy and the switch, the old site may have changed: new comments, orders or uploads. For a site that changes often:

1. Put the old site into maintenance mode, or stop changes another way, so nothing new is written.
2. Export the database again and import it on the new server, as in step 5.
3. Copy any new uploads, for example by running rsync again.
4. Change your DNS A record, and AAAA if you have one, to the new IP address.
5. Watch the new server's access log to see visitors arrive. With nginx: sudo tail -f /var/log/nginx/access.log.
6. Issue SSL certificates on the new server once DNS points to it, if you did not copy them.

For a site that rarely changes, you can skip the maintenance step and simply switch DNS.

9. Keep the old server for a while

• Leave the old server running for a few days to a week. Some visitors and systems use cached DNS for longer than you expect.
• Check its access log. When real visits stop arriving there, the switch is complete.
• Update anything that trusted the old IP address, such as API allowlists.
• Set up backups on the new server. See using a storage VPS for backups.
• Take a final backup of the old server, then cancel it before its renewal date. Cancelling removes your data, so be sure first.
• Raise the DNS TTL back to its usual value.

Troubleshooting

Symptom	Likely cause	Fix
"Error establishing a database connection"	Database user or password missing on the new server	Create the user with the same name and password as the app's config
Images or uploads missing	Upload folder not copied, or wrong owner	Copy it again and fix ownership with chown
403 or permission errors	Files owned by the wrong user	Set ownership to the web server's user, usually www-data
Site loads the old server after the switch	DNS cached, or hosts file line still in place	Remove the hosts line and wait for the TTL to expire
Scheduled jobs stopped running	Crontab not recreated	Recreate it from your list in step 1
Email stopped	Mail records changed, or the old server was sending mail	Check MX and other mail records, and set up mail sending on the new server

Limits

• Your own mail server is the hardest thing to move. New IP addresses often start with no sending reputation. If you can, move email to a dedicated email service instead.
• Sale prices do not transfer. Cancelling an old deal plan usually means losing its price for good. Be sure you no longer need it.
• Big data takes time. Copying hundreds of gigabytes can take hours, and counts towards both servers' bandwidth. Unmetered does not mean unlimited.
• Licences may be tied to the server. Some software licences are linked to an IP address or machine. Check before moving.
• This is a manual move. Complex setups, such as several apps with shared databases, need more planning than this guide covers.

When to step up

A move is the easiest moment to change size, because you are building a new server anyway. If the old server was often short on memory, move to the next size up rather than the same again. How to read VPS specs helps you compare, and VPS or dedicated server? covers the bigger jump.

To compare what is available now, start with the cheapest RackNerd VPS guide and check the sales page.

More in the series

This is part 4 of 5. Previous: Domains and DNS explained. Next: My VPS is slow or down: what to check. See the whole series.