How to Migrate a WordPress Site to a New Host

The order that avoids downtime: copy → test on the new server with a hosts-file override → freeze content → sync the final changes → switch DNS → verify. Changing DNS first is what turns migrations into outages.

Before you start

Collect what you will need:

• SFTP/SSH access and database credentials on both hosts;
• registrar login for the DNS change;
• the current PHP and MySQL versions on the old host, so the new one is not older;
• a full, tested backup, per how to back up a WordPress site.

Lower the DNS TTL for the site's A record to 300 seconds at least 24 hours ahead. This is the single change that makes the final switch quick, and it must happen early to take effect.

Step 1: copy the files

# On the old server, package everything that matters.
tar -czf site.tar.gz wp-content wp-config.php .htaccess wp-admin wp-includes index.php wp-*.php

# On the new server.
tar -xzf site.tar.gz

Core files can equally be reinstalled fresh on the new host; what must travel is wp-content, wp-config.php and any root-level customisation.

Large uploads directories transfer faster with rsync if both hosts allow SSH:

rsync -avz --progress wp-content/uploads/ user@newhost:/path/to/wp-content/uploads/

Step 2: copy the database

# Old host.
wp db export migration.sql       # or: mysqldump -u USER -p DB > migration.sql

# New host, after creating an empty database and user.
wp db import migration.sql       # or: mysql -u USER -p DB < migration.sql

Then update the credentials in wp-config.php on the new server:

<?php
define('DB_NAME', 'new_database');
define('DB_USER', 'new_user');
define('DB_PASSWORD', 'new_password');
define('DB_HOST', 'localhost');

Keep the existing salts. Changing them logs everyone out, which is fine but unnecessary during a migration. The rest of the file is explained in wp-config.php explained.

Step 3: test before DNS changes

This is the step people skip and regret. Point your own machine at the new server without affecting anyone else, by editing the hosts file:

203.0.113.10   example.com www.example.com

On macOS and Linux that is /etc/hosts; on Windows, C:\Windows\System32\drivers\etc\hosts. Flush your DNS cache, then browse the site — you are now on the new server while the world is still on the old one.

Check, at minimum:

• the homepage, an interior page and a post;
• images loading from uploads;
• the admin login;
• a form submission;
• checkout, if it is a store;
• debug.log for new errors after browsing.

Remove the hosts entry when finished testing.

Step 4: search and replace, if the domain changes

If the domain stays the same, skip this. If it changes — including moving from a staging domain — the database is full of the old one.

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables --report-changed-only

Add --dry-run first and read the report. WP-CLI handles serialised data correctly; a plain SQL REPLACE does not and will corrupt widget and option values.

Step 5: freeze, sync and switch

1. Stop publishing on the old site. On a store, this means a short maintenance window or accepting that late orders need re-syncing.
2. Export the database from the old site one final time and import it over the new one, so nothing published during testing is lost.
3. Sync any uploads added since the first copy.
4. Change the A record (and www) at the registrar or DNS provider to the new IP.
5. Watch both servers' access logs. Traffic drains from one and appears on the other over the TTL window.

Keep the old host running for at least a week. It costs one more billing cycle and it is your rollback.

Step 6: after the switch

• Issue a new SSL certificate on the new host, and confirm HTTPS works on both www and apex — see fixing the not secure warning.
• Save permalinks once so rewrite rules are written on the new server, per permalinks not working.
• Reconfigure email. SMTP credentials, SPF records and sending IPs often differ; test with the email diagnosis.
• Recreate cron jobs. A system cron on the old server did not travel with the files.
• Set up backups on the new host immediately — do not wait until "later".
• Check the PHP version and enable object caching if it is available, then re-measure with the speed guide.

Common migration failures