Migrate a Live WordPress Site to a New Host with Zero Downtime

Migrating a live WordPress site sounds simple until you confront the core problem: the domain has to point somewhere during the move. DNS propagation can take hours. Flip the A record too early, and visitors hit a dead server. Set up the new server first, and you risk losing every post, comment, or order written between the switch.

This guide walks through a proven, two-phase sync method that eliminates visible downtime. It works for single sites, reseller accounts, and agency portfolios. You need SSH access on both servers and basic command-line comfort.

What You Need Before You Start#

• SSH access to both the source and destination server
• A working WordPress installation on the source
• Matching or newer PHP version on both servers (check with php -v)
• MySQL or MariaDB available on the destination
• Enough disk space on the destination to hold the full site
• Access to your domain's DNS zone (registrar or DNS provider)

Confirm the destination server has the same or newer PHP version. WordPress will often run on a newer minor version without issues, but a downgrade from PHP 8.2 to 7.4 will break things. Check with php -v on both sides.

Step 1: Lower the DNS TTL#

At least 24 hours before the migration, lower the TTL on your domain's A and AAAA records to 300 seconds (5 minutes). This tells DNS resolvers to check for changes more frequently, so when you flip the record, propagation happens in minutes instead of hours.

If your TTL is currently 3600 or 86400, you need to wait out the old TTL before the change takes effect globally. Plan ahead.

Step 2: Create the Database on the Destination#

SSH into the destination server and create a fresh database and user.

CREATE DATABASE wordpress_db;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'strong_password_here';
GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;

Write down the database name, user, and password. You will need them for wp-config.php.

Step 3: Export the Database from the Source#

On the source server, dump the database. Find the database name and credentials in wp-config.php.

mysqldump -u wp_user_old -p wordpress_db_old > /tmp/site-dump.sql

If the database is large (over 500 MB), add --single-transaction to avoid locking tables on InnoDB:

mysqldump --single-transaction -u wp_user_old -p wordpress_db_old > /tmp/site-dump.sql

Step 4: Copy Files and the Dump to the Destination#

Use rsync over SSH to transfer the entire WordPress directory and the SQL dump. This is faster than SFTP and supports resume on interruption.

rsync -avz -e ssh /var/www/html/site/ user@destination:/var/www/html/site/
rsync -avz -e ssh /tmp/site-dump.sql user@destination:/tmp/site-dump.sql

Replace /var/www/html/site/ with the actual document root. The trailing slash matters in rsync—it copies the contents of the directory, not the directory itself.

This first sync will take time. If the site has a large uploads folder, expect 10–30 minutes depending on connection speed.

Step 5: Import the Database on the Destination#

mysql -u wp_user -p wordpress_db < /tmp/site-dump.sql

Step 6: Update wp-config.php#

On the destination, edit wp-config.php with the new database credentials:

define('DB_NAME', 'wordpress_db');
define('DB_USER', 'wp_user');
define('DB_PASSWORD', 'strong_password_here');
define('DB_HOST', 'localhost');

Do not change the table_prefix unless you deliberately changed it during the database setup.

Step 7: Fix URLs if the Site Path Changed#

If the document root path differs between servers (for example, /home/olduser/public_html vs /var/www/html), you may need to update siteurl and home in the database. You can do this with WP-CLI if available:

wp option update siteurl 'https://yourdomain.com' --path=/var/www/html/site
wp option update home 'https://yourdomain.com' --path=/var/www/html/site

Or run a search-replace if the domain itself is changing:

wp search-replace 'http://olddomain.com' 'https://newdomain.com' --path=/var/www/html/site

Step 8: Run a Final Rsync#

The site was live during the initial sync. Any posts, comments, orders, or uploads created since then are missing on the destination. Run rsync again to catch the delta:

rsync -avz -e ssh /var/www/html/site/ user@destination:/var/www/html/site/

This time it will be fast—only changed files transfer.

Then re-export and re-import the database one more time to capture any new rows:

mysqldump --single-transaction -u wp_user_old -p wordpress_db_old > /tmp/site-dump.sql
rsync -avz -e ssh /tmp/site-dump.sql user@destination:/tmp/site-dump.sql
mysql -u wp_user -p wordpress_db < /tmp/site-dump.sql

This is the critical step most tutorials skip. Without it, you lose whatever was written between the first sync and the DNS flip.

Step 9: Test on the Destination Before Flipping DNS#

You can preview the site on the new server without changing DNS by editing your local /etc/hosts file:

203.0.113.50  yourdomain.com www.yourdomain.com

Replace 203.0.113.50 with the destination server's IP. Now open the domain in your browser—you are hitting the new server while the rest of the internet still sees the old one.

Check that pages load, images display, forms submit, and the admin dashboard works. Log in and verify the site content is current.

Remove the hosts entry when you are done testing.

Step 10: Point DNS to the New Server#

Update the A record (and AAAA if applicable) to the destination server's IP address. With your TTL already at 300 seconds, most visitors will hit the new server within 5–15 minutes.

Keep the old server running for 48–72 hours. A small percentage of resolvers cache aggressively and will take longer to update.

Step 11: Verify and Clean Up#

Once traffic has fully moved:

• Check server access logs to confirm requests are arriving
• Submit a test form or post to confirm writes are working
• Run a broken-link checker to catch any path issues
• Disable or remove the old site after 72 hours

If you are managing multiple sites across a reseller panel, tools like Salieno Core can help automate the provisioning side—creating the database, setting up DNS zones, and configuring the web server—so you spend less time on boilerplate and more time on the actual migration logic.

Common Pitfalls#

• Forgetting to re-sync the database. The most common cause of "I lost a day of content" complaints.
• Hardcoded paths in `wp-config.php` or `.htaccess`. Some plugins write absolute paths. Search for the old path in the database after import.
• Mixed HTTP/HTTPS references. If the old site was HTTP and the new one is HTTPS, run a search-replace for the protocol.
• File permissions. WordPress expects 755 for directories and 644 for files. Run find /var/www/html/site -type d -exec chmod 755 {} \; and the equivalent for files.

Migrating WordPress without downtime is not complicated, but it rewards discipline. The two-sync approach—once before, once just before the DNS flip—is what makes it work. Get that rhythm right and you can move any number of sites cleanly.