Migrations go wrong in boring, predictable ways. Almost none of them are about the copy itself — they are about what nobody wrote down before the copy started. This is the checklist we run before a single DNS record changes.
Inventory first, copy second
Before anything moves, we write down what actually exists: PHP version, database size, cron jobs, scheduled tasks, mail configuration, and every integration that talks to the site. The last one is where the surprises live — payment webhooks and CRM syncs are usually undocumented.
Lower the TTL a day ahead
Set your DNS TTL to 300 seconds the day before. If you skip this and something is wrong after the switch, you are stuck waiting hours for the old record to expire while the site is broken for part of your audience.
Test on the target before you point at it
Run the new server behind a hosts-file override and walk the critical paths: checkout, login, contact form, search. A staging URL is not enough — plugins that hardcode the domain will only misbehave once the real hostname is in play.
Keep the old host warm
Do not cancel the old hosting the same week. Keep it running, read-only, for at least two weeks. It costs very little and it is the only real rollback you have.
After the switch
Check HTTPS on both apex and www, confirm the certificate auto-renews, verify mail still sends, and re-run the critical paths. Then watch the error log for a day — not the homepage, the error log.
