Migrating a website to a VPS with no service interruption

Moving a website to a VPS is not risky if you follow a precise order: copy everything, test everything on the new server, and only change the DNS at the very end. Throughout the preparation, visitors keep using the old hosting without noticing anything. This method works for PHP, static and Node.js sites; for WordPress, our dedicated guide migrating WordPress to a VPS with no downtime (in French) covers the steps specific to that CMS.

1. The principle

1. You set up and fill the new server alongside the old one.
2. You test it by fooling only your own computer about the site's address.
3. You switch the DNS once everything works, with a short TTL so the switch is fast.
4. You keep the old hosting active for a few days, as a safety net.

2. Take inventory

Before touching anything, list what makes up the site:

• Files: code, media uploaded by users, configuration files.
• Databases and their credentials.
• Scheduled tasks (cron) on the old hosting.
• The PHP or Node.js version and the extensions used.
• Email: are the mailboxes with the old host? If so, they do not move with the site, and the MX records must not change.
• The full DNS zone, exported or copied down.

3. Prepare the DNS the day before

Lower the TTL of the A, AAAA and www CNAME records to 300 seconds. Wait at least the length of the old TTL before switching: that way, on the day, every visitor follows the change within five minutes. Details in configuring DNS.

4. Prepare the VPS

Install the same software stack as the old hosting, in an equal or newer compatible version: web server, PHP or Node.js, database. Follow, as appropriate, Nginx, the PHP stack for WordPress or Node.js with PM2, without requesting a certificate yet: Let's Encrypt can only validate the domain after the DNS switch. Secure the server right away too: first steps and firewall.

5. Copy the files and databases

Files. If the old hosting provides SSH access, rsync is the ideal tool, run from the VPS:

rsync -avz --progress [email protected]:~/www/ /var/www/mysite.com/

The benefit of rsync: run a second time just before the switch, it only copies what changed in the meantime. Without SSH access, download an archive over FTP or from the host's panel, then send it to the VPS with scp.

Databases. Export from the old hosting, with mysqldump over SSH or the panel's export tool, then import:

mariadb -e "CREATE DATABASE mysite CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mariadb mysite < export.sql

Create the database user as described in securing MariaDB, then put the new credentials in the site's configuration. Finally, restore ownership: chown -R www-data:www-data /var/www/mysite.com.

6. Test before the switch

This is the step that makes the migration risk-free. On your computer only, pretend the domain already points to the VPS by adding a line to the hosts file:

# Windows: C:\Windows\System32\drivers\etc\hosts (editor run as administrator)
# macOS and Linux: /etc/hosts
203.0.113.10  mysite.com www.mysite.com

Open the site in a private browsing window: you see the VPS version, while the rest of the world still sees the old one. Test everything that matters: main pages, forms, login, sending email, payment in test mode, file uploads. HTTPS is not in place yet: accept the browser warning, or test over HTTP.

Also watch the server's error log during your tests: tail -f /var/log/nginx/error.log.

7. Switch over

1. If the site receives data (orders, accounts, comments), freeze it: maintenance mode on the old hosting.
2. Run rsync again and redo the database export and import to pick up the latest data.
3. Change the A and AAAA records to the VPS address. Do not touch the MX records.
4. Remove the line you added to your hosts file.
5. As soon as dig +short mysite.com returns the new address, get the certificate: certbot --nginx -d mysite.com -d www.mysite.com --redirect.

8. After the migration

• Keep the old hosting active for one to two weeks: a few visitors with stubborn caches still land there, and it is your fallback plan.
• Recreate the scheduled tasks noted in the inventory.
• Set up backups from day one: see backups with Borg.
• Raise the TTL to an hour or more once everything is stable.
• Watch Search Console over the following days: crawl errors point to a forgotten page or a missing redirect. See Google indexing and sitemaps.

Frequently asked questions