The migration checklist that survives contact with a live site

A move that goes badly is almost never technically difficult. It is one step nobody did, discovered at the point where the site is already half moved.

Before

• Inventory what is really running: plugin versions, PHP version, cron jobs, anything customised directly on the server.
• Lower the DNS TTL to five minutes at least 48 hours ahead. Do this early or the cutover window is a day instead of minutes.
• Take a backup and restore it somewhere. An unrestored backup is a hypothesis.
• Rehearse the whole migration into the new environment and check it properly.

Serialised data

This is where sites break. WordPress stores serialised arrays with the length of each string recorded inside them. A plain search and replace across the database changes the strings without changing the recorded lengths, and everything holding that data — widget settings, theme options, page builder layouts — fails to unserialise. Use tooling that understands serialisation. WP-CLI’s search-replace does; a SQL query does not.

Redirects

If any URL changes, map it. Export the old URL set, map it to the new one, and put the redirects in place before the switch rather than after somebody notices the traffic drop. Include the ones nobody thinks about: feeds, sitemaps, uploaded files, and the paths your email campaigns point at.

After

• Submit an order or send a form, on the live site, with real details.
• Send mail and check the headers, because SPF and DKIM records follow the domain and not the server.
• Confirm scheduled tasks are firing on the new host.
• Watch the error log for a full day rather than glancing at it once.
• Keep the old environment running for a week. It is the rollback plan.

None of this is clever. It is just the list, written down before the day rather than remembered during it.