Migrating a website between hosts with zero downtime

Why Is Zero-Downtime Site Transfer Important?

Transferring a site from one host to another is one of the most sensitive web management operations. If not done correctly, users may encounter a 503 error or a white screen, and search engines could experience ranking drops. In this article, we provide a practical, tested method for site transfer without even a second of downtime. This method works for WordPress sites, Laravel sites, and even static sites.

Step One: Preparing the Destination Host

Before anything else, you need to prepare the new host. Assume your old host is at old.server.net and the new host is at new.server.net.

1. Create Database and User

On the new host, create an empty database. Note the database name and user. For example:

Database: newdb_user
User: newdb_user_pass
Host: localhost

Important Note: Do not set the database password on the new host the same as the old host’s password. We will change it later in the site’s config file.

2. Create the Main Directory

On the new host, empty the public_html directory or its equivalent. If you use cPanel, use the "File Manager" option.

Step Two: Copying Files and Database

You can perform this step at any time of day, since traffic is still directed to the old host.

1. Transfer Files with rsync

The best tool for copying files is rsync. If you have SSH access to both hosts, use the following command:

rsync -avz --progress user@old.server.net:/home/user/public_html/ /home/user2/public_html/

If you only have SSH access to the old host, first transfer the files to your local system and then to the new host:

rsync -avz user@old.server.net:/home/user/public_html/ ./backup-site/
rsync -avz ./backup-site/ user2@new.server.net:/home/user2/public_html/

Common Mistake: Using FTP to transfer large files. FTP is slow with many files and may disconnect midway. Always use rsync or scp.

2. Transfer the Database

First, take a dump of the old database:

mysqldump -u olduser -p olddb > olddb.sql

Then, transfer the SQL file to the new host and import it:

mysql -u newuser -p newdb < olddb.sql

If the database is large (over 50 MB), use bigdump or mysql -e.

3. Edit the Config File

On the new host, edit the site’s config file. For WordPress, open the wp-config.php file and change the following values:

define('DB_NAME', 'newdb_user');
define('DB_USER', 'newdb_user');
define('DB_PASSWORD', 'new_password');
define('DB_HOST', 'localhost');

For Laravel, edit the .env file.

Step Three: Test the Site on the New Host Without Downtime

Before changing DNS, you must ensure the site works correctly on the new host. We do this using the hosts file.

1. Set Up the hosts File on Your System

Open the hosts file on your system:

• Windows: C:\Windows\System32\drivers\etc\hosts
• Linux/Mac: /etc/hosts

Add a line to the end of the file:

192.168.1.100 example.com www.example.com

Replace the IP address with the new host’s IP. Now, if you open example.com in your browser, you will be directed to the new host.

2. Fully Test the Site

At this stage, test all parts of the site:

• Main and internal pages
• Contact and registration forms
• User login
• Images and CSS/JS files
• SSL (if you have a certificate, it must be installed on the new host)

SSL Test: If you use SSL, install the certificate on the new host. You can use Let's Encrypt:

certbot --apache -d example.com -d www.example.com

If SSL does not work, the browser will show a security error.

Step Four: Reduce TTL and Switch DNS

Now that you are sure the site works on the new host, it is time to change DNS.

1. Reduce TTL (Time To Live)

TTL determines how long DNS records remain in cache. The default value is usually 14400 seconds (4 hours). Reduce this to 300 seconds (5 minutes). Do this at least 24 hours before the switch.

In your DNS panel, find the A and CNAME records and change the TTL:

example.com.  300  IN  A  192.168.1.100
www.example.com.  300  IN  CNAME  example.com.

Common Mistake: Forgetting to reduce TTL for MX records (email). If you have email, also reduce the TTL of MX records.

2. Change DNS Records

After 24 hours (or the old TTL duration), change the A record to the new host’s IP:

example.com.  300  IN  A  IP_NEW_HOST

If you use a CDN (like Cloudflare), only change the origin IP.

3. Wait for Propagation

DNS changes typically propagate worldwide within 5 minutes to 24 hours. During this time, some users will be directed to the old host and some to the new host. This is normal and is not considered downtime.

Step Five: Emergency Rollback

If a problem occurs after the DNS switch (e.g., a 502 error or severe slowness), you must quickly revert to the old host.

1. Revert DNS

Change the A record back to the old host’s IP. Also, restore the TTL to its previous value.

2. Check Logs

Examine the error logs on the new host:

tail -f /var/log/apache2/error.log

Identify the cause of the problem (e.g., an incompatible plugin or PHP settings).

3. Fix the Issue and Repeat Steps

After fixing the issue, start again from step three (testing with the hosts file).

Additional Tips and Troubleshooting

1. Transferring Emails

If you use the host’s email service, you must also transfer emails. Use the imapsync tool:

imapsync --host1 old.server.net --user1 info@example.com --password1 oldpass \
         --host2 new.server.net --user2 info@example.com --password2 newpass

2. Relative Path Issues

Some sites use absolute paths. On the new host, check the paths. For example, in WordPress, use the "Better Search Replace" plugin.

3. Browser and CDN Cache

After the switch, clear your browser cache and CDN cache. In Cloudflare, use the "Purge Cache" option.

4. Proper Timing

The best time to switch DNS is during low-traffic hours (e.g., 2 AM). This minimizes the number of users affected during propagation.

Summary

Zero-downtime site transfer requires careful planning and following the correct order of steps. Using the method presented in this article (copying files, testing with the hosts file, reducing TTL, switching DNS, and being prepared for emergency rollback), you can perform a site transfer with minimal risk. If you are looking for a stable host for your site, ServerNet offers suitable options. However, more important than choosing a host is executing the transfer process correctly.

Finally, always take a full backup of the site and database before starting. This is the simplest way to avoid disaster.