Pre-migration audit
Full inventory: domains and subdomains, DNS records, mailboxes and forwarders, cron jobs, SSL certificates, PHP version and extensions, redirects, and anything sitting outside the web root.
Servers, Hosting & DevOps
Server & website migration
Migrations go wrong in predictable ways. Email keeps arriving at the old server for two days because TTL was never lowered. Redirects were on the old host and nobody copied them. The database was exported while it was still being written to. SSL was not reissued and every visitor gets a warning.
None of that is difficult to avoid. It just has to be planned before anything moves, rather than discovered afterwards.
How I work on it
Process
Adjusted to the job, but this is the shape it usually takes.
-
Inventory
Write down everything the current host does, not just the website. The forgotten cron job is the classic post-migration bug.
-
Build and test in parallel
The new environment is fully working and verified before any public change.
-
Cut over in a quiet window
With TTLs already low, the switch happens when traffic is lowest and both of us are available.
-
Watch for a week
Logs and mail queues monitored afterwards, because some issues only appear on the first weekly cron run or the first invoice email.
Questions
Things people ask
For a typical site, minutes, usually just the final database sync. The DNS propagation window does not have to mean downtime, because both servers can serve the site while records update, provided the plan accounts for it.
It should not be. Mail is migrated first and both servers accept delivery during the transition, so messages arriving at either one are retained and reconciled.
A same-domain host change should be invisible to search engines if URLs, redirects and response codes are preserved. I crawl the old site before the move and compare afterwards to confirm nothing quietly started returning a 404 or a 302 where it used to be a 301.