Moving WordPress to a new host: a cutover checklist that loses nothing

#How this differs from a domain change

When you change hosts the domain usually stays the same. That removes the search and replace problem but adds a different one: for a while the site exists in two places, and the one visitors see is decided by DNS rather than by you. The plan below keeps the old host live and untouched until the new one is proven, then flips DNS, then keeps the old host for a few days as a rollback.

If you are changing host and domain at once, do the host move first with this guide, then follow migrating to a new domain on the new server.

#1. Set up the new server first

Install a fresh WordPress on the new host. Most providers give you a temporary URL such as https://site.temp-host.com or an IP; either is fine. Match the old site's PHP version (or go newer, never older) and check the database server version. Install Dragon Migrate on both sites.

Take note of the new site's table prefix. If you can, set it to the same prefix as the old site in wp-config.php before importing. Dragon Migrate refuses an import whose prefix does not match rather than importing a second set of tables beside the first.

#2. Freeze content and export

Ask editors to stop publishing. Then on the old site open Tools, then Migrate, then Archive and build a full-site archive: database plus uploads, themes and plugins in one zip. The job runs in batches sized to the host's limits and resumes if the tab closes, so a large media library on a slow shared host still completes.

If the site is very large and the new host has SSH, it is often faster to export only the database from the Export tab and copy the wp-content/uploads directory with rsync. Both are fine. The archive is the fewer-moving-parts option.

Because the domain is not changing, leave Find and Replace empty. If the temporary URL on the new host will be used for testing, do not replace the domain with it in the database. Use the hosts-file trick in step 4 instead, so nothing has to be replaced back later.

#3. Import on the new host

Upload the archive or dump on the new site's Import tab. A safety backup of the new site's (empty) database is taken first. When the import finishes you are logged out, because the users table was just replaced. Log back in with the old site's credentials.

Then in wp-config.php on the new host check the database credentials point at the new database, and that no WP_HOME or WP_SITEURL constant points at the temporary URL.

#4. Test the new host without touching DNS

Add a line to your computer's hosts file that points the real domain at the new server's IP:

203.0.113.10  example.com www.example.com

Now your browser loads the new host under the real domain while everyone else still sees the old one. Walk the site: homepage, a few deep pages, media, search, forms, login, and a test order if it sells anything. Check the SSL certificate on the new host is issued for the real domain, not the temporary one, or the first visitors after cutover will see a warning.

Remove the hosts entry when you are done.

#5. Cut over

Lower the DNS TTL on the domain's A record to 300 seconds at least a day before the move if you can. Then, in this order:

1. Ask editors to stop again, if they were allowed back.
2. Take a final database-only export on the old host and import it on the new host, so the last day's comments, orders and posts come across. This is quick: the files are already there.
3. Change the A record (and AAAA if you have one) to the new server.
4. Watch the new host's access log. When traffic arrives there, the flip is done.

Do not delete anything on the old host yet. If you need to go back on the new host itself, the Backups tab has the snapshot taken before the import, with a typed confirmation before it restores.

#6. Keep the old host as a rollback for a week

Leave the old host running and untouched for several days. Some resolvers ignore TTLs, and any email or webhook still pointed at the old IP shows up in its logs. If something is badly wrong on the new host, pointing DNS back is a two-minute fix.

Once the old host's logs are quiet, cancel it. Keep a final backup of the old database somewhere off both servers.

#Doing this repeatedly

Agencies that move sites every week get tired of the archive-and-upload loop. Dragon Migrate Pro pairs two sites with a shared key and then pulls the old host's database and files straight into the new one over a signed connection, resumable, with a rollback point taken automatically. Scheduled pulls also keep a staging copy fresh from production without anyone remembering to do it.

#Things that catch people out

• Cron. If the old host ran a real system cron calling wp-cron.php, set it up on the new host too, or scheduled posts and background jobs stop.
• Email. Sites that send through the host's mail server lose that when they move. Check outgoing mail on the new host; a transactional SMTP or API service is the durable fix.
• Object cache. A wp-content/object-cache.php drop-in from the old host's Redis or Memcached breaks silently if the new host has no such service. Remove it or reconfigure it.
• File permissions. Uploads copied as root are not writable by the web server. Chown them to the web user.
• Licences tied to IP. Rare, but some premium plugins and API keys are pinned to a server address. Reactivate them.