WordPress Migration Checklist for Minimal Downtime

A well-run WordPress migration is a sequence of verifiable steps, ordered so the DNS switch becomes almost a formality. No migration is entirely free of interruption, but the right order shrinks the risky window and keeps it reversible. The checklist works for brochure sites and WooCommerce stores alike; if you look after many client sites, run it per site and stagger the cutovers.

Inventory: what you are actually moving

Most post-migration surprises come from something nobody wrote down. Before you copy a single file, document:

• Versions of WordPress, PHP (and the extensions you rely on) and MySQL/MariaDB. WordPress currently recommends PHP 8.3 or later and MySQL 8.0 or MariaDB 10.11 or later.
• Size: disk usage, database size and file count (inodes), which some shared plans cap.
• .htaccess rules and custom php.ini or .user.ini files. Moving to Nginx means rewriting the .htaccess rules, because Nginx does not read them.
• Scheduled jobs: system cron, WP-Cron, backup scripts and exports.
• The full DNS zone: A/AAAA, CNAMEs, MX, SPF, DKIM and DMARC TXT records, and third-party verification records.
• Email: mailboxes, forwarders, and everything that sends mail from the site (forms, order notifications).
• IP-based integrations: payment gateways, shipping APIs, SMTP relays.
• Access to the registrar, DNS provider, old and new host, plus the old plan's renewal date: it must not lapse mid-migration.

Lower the DNS TTL well in advance

TTL (time to live) is the number of seconds a resolver may cache a record before asking again, as defined in RFC 1035 and clarified in RFC 2181. If your A record has a TTL of 86400, some visitors may keep reaching the old server for a full day after you change it.

Lower the TTL on the records you will change (A, AAAA, www) to something short, such as 300 seconds, at least one old TTL ahead: the previous value has to expire from caches first. Google's guide to changing hosting without URL changes suggests doing this at least a week before the move. Once things are stable, raise it back. Not every cache honours TTLs to the letter, so a few visitors may linger on the old server a little longer.

Copy the files and the database

There are three main routes; the right one depends on site size, the access you have and how much control you want.

The manual route, run from the old server:

# Consistent database dump (InnoDB tables)
mysqldump --single-transaction -u db_user -p db_name > ~/migration/site.sql

# Copy the files to the new server
rsync -avz ~/public_html/ user@203.0.113.10:public_html/

Per MySQL's documentation, --single-transaction gives a consistent snapshot of InnoDB tables only: convert any MyISAM tables first, or put the site in read-only mode while you dump. On the new server, import the file and update wp-config.php with the new database credentials.

Search-replace URLs without breaking serialised data

If the domain stays the same, leave the database alone. You need a search-replace when the address changes: staging to live, http to https, www to non-www. Never run a plain find-and-replace on the SQL file: WordPress and its plugins store many options as serialised PHP, which records string lengths. Change a URL's length and the value can no longer be read, so widgets and settings quietly vanish.

WP-CLI handles serialised data. Always start with a dry run:

wp search-replace 'https://staging.example.com' 'https://www.example.com' \
  --skip-columns=guid --dry-run
# if the report looks right, run it again without --dry-run
wp cache flush

Test the new server before switching DNS

The most reliable test is the real site, on the real domain, served by the new server while everyone else still sees the old one. Your hosts file does exactly that (C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on macOS and Linux, admin rights required): add the new server's IP and your domain, then flush the DNS cache or restart the browser.

203.0.113.10  example.com www.example.com

From a terminal, curl can pin the resolution without touching system settings; until a valid certificate is in place, -k skips TLS verification, for this test only:

curl -skI --resolve www.example.com:443:203.0.113.10 https://www.example.com/

• Home page, key landing pages, posts and on-site search.
• Admin login, and saving a draft.
• Contact forms: does the email actually arrive?
• Cart and checkout, with the payment gateway in test mode.
• Permalinks: if inner pages return 404, re-save the permalink settings or run wp rewrite flush.
• The new server's PHP error log, during and after your clicks.

If staging had “Discourage search engines from indexing this site” ticked, untick it: Google likewise recommends removing robots.txt disallows and noindex tags before updating DNS.

Email and SSL: where migrations trip up

Email and MX records

If mail runs on an external service (Google Workspace, Microsoft 365), there is nothing to move: if you change DNS provider, copy the MX, SPF, DKIM and DMARC records exactly. Mailboxes on the old host are a migration of their own. Watch out: on many shared hosts mail.example.com points to the website's IP, so changing that record moves your mail too.

If the destination is unreachable for a while, inbound mail is not lost straight away: under RFC 5321, senders retry at intervals of at least 30 minutes and generally keep trying for at least 4-5 days. The real risk is mail delivered to the old server after you copied the mailboxes: keep them alive for a few days and run a second IMAP sync after the switch.

If the site sends email, add the new IP to SPF or route WordPress mail through an authenticated SMTP relay; otherwise notifications land in spam or are rejected by receivers enforcing DMARC.

SSL certificates

Let's Encrypt and many other automated issuers validate the domain with the HTTP-01 challenge, on port 80 of whichever server the domain points to at that moment, so the new server cannot pass it before DNS moves. The alternatives: the DNS-01 challenge (a TXT record at _acme-challenge), copying the certificate and private key from the old server, or accepting a few minutes without a valid certificate after the switch.

Cutover day and the rollback plan

With the groundwork done, the switch itself is short. In order:

1. Confirm the low TTL has been live for at least as long as the old TTL value.
2. If the site writes data, put the old one in maintenance mode and take the final copy of the database and of any files uploaded since.
3. Remove the hosts file entry so you see what everyone else sees.
4. Point the A/AAAA records to the new server (and the MX records, if mail is moving too).
5. Query the authoritative nameservers and a few public resolvers; watch the logs on both servers.
6. Repeat the test round from the previous section on the public domain.

Decide the rollback plan before cutover, not during it. If something serious cannot be fixed in acceptable time, point the A record back to the old server; with the TTL still low, that takes effect quickly. That is why the old host stays live and untouched, and is not cancelled on switch day. Agree a clear trigger (say, checkout still broken after 30 minutes) and who makes the call. Data written to the new server in the meantime, such as orders, will have to be carried back by hand.

Post-migration checks

• Valid HTTPS on every variant (with and without www) and redirects from http to https.
• No mixed content: images or scripts still loading over http or from an old hostname.
• Cron: WP-Cron runs or, if you set DISABLE_WP_CRON, the system cron job has been recreated.
• Automatic backups enabled on the new server, with one test restore already done.
• Outbound mail from forms and orders arrives and passes SPF, DKIM and DMARC.
• Search Console shows no spike in crawl errors; Google notes that a temporary dip in crawl rate right after a move is normal.
• The old server's logs: once traffic reaches zero, you can decommission it.
• TTL raised back to a normal value.

If you would rather hand these steps to someone else, our assisted migration follows this same checklist, with a staging rehearsal and an agreed rollback plan.