Every clean migration is the same seven moves in the same order: inventory what exists, copy it, verify the copy on the destination before anyone points traffic at it, lower DNS TTLs ahead of time, cut over in a quiet hour, watch the error logs, and freeze rather than delete the source until a full cycle of backups has run on the new home. Sites and whole servers differ only in how long the inventory takes. Skipping steps does not fail loudly; it fails Tuesday.
Inventory: the step everyone shortens and regrets
List the site files and databases, then the invisible half: cron jobs, mail routing, TLS certificates, environment variables and API keys, redirect rules, and every DNS record at the current provider, exported before anything moves. On a whole server, add users, installed packages and firewall rules. The inventory is the checklist's real content; the WordPress project's own moving guide is blunt that most failed moves are incomplete copies, and the incompleteness is almost always from this list, not the site files.
Copy and verify before any traffic moves
Stage everything on the destination and test it against a hosts-file override or a preview URL while the public site still runs on the old server. Verify the application actually works, not that files arrived: log in, submit the forms, check a payment in sandbox, confirm the database character set survived. This is also the moment to capture baseline numbers (response time, page weight) so cutover regressions are measurable instead of vibes. Nothing about a migration requires downtime except skipping this stage.
Cutover, and the week after
Days ahead, drop the DNS TTLs on the records that will change so caches expire quickly. At cutover, freeze content changes, switch the records, and watch both servers' logs: traffic drains from one and rises on the other, and stragglers hitting the old box tell you which caches and which forgotten subdomains still point there. Keep the old server running but frozen for at least a week and until the new host has produced and test-restored its own backups. Deleting the source on migration day is the only unrecoverable mistake on this page.
Questions people ask about migration checklist
How long should a site migration take?
Staging and verification dominate: hours to days depending on the inventory. The cutover itself, done with lowered TTLs, is minutes.
Can I migrate with zero downtime?
Close to it: verify on the new host first, cut DNS with short TTLs in a quiet window, and put the old site in read-only mode during the overlap so nothing written gets lost.
What goes wrong most often on a server migration checklist?
Mail: MX records and mailbox data live outside the site copy, and the first sign of a botched move is customers replying to email that never arrives.