Development
The migration checklist nobody publishes
Fail quietly, in order.
Most WordPress migrations don't blow up dramatically. They fail quietly, in a predictable order. The site moves, everyone signs off, it looks great. Then three weeks later traffic is down 40 percent and nobody can say why.
We've been moving sites for 21 years and the order barely changes. Here's the sequence things actually break in, so you can check for each one before it costs you the quarter.
The most common failure is not technical. Under Settings, Reading sits Discourage search engines from indexing this site. You tick it on staging so Google does not crawl half-finished work. Then on launch day, in the rush, nobody unticks it. The site goes live invisible.
Raw database find-and-replace looks right until it silently destroys half your settings. WordPress stores data as serialized PHP, which records each string's exact byte length. Change the URL but not the length marker and PHP refuses to read the value. Widgets vanish, layouts go blank.
If the URL structure changed at all, every address Google indexed now hits a 404. You need a 301 redirect map. Building it is tedious and it is the first thing cut when a deadline tightens, which is exactly why it lands third.
The database moves cleanly as one tidy export. The actual image and PDF files live in a separate directory, copied by hand. Miss some and you get broken-image icons across exactly the pages people look at most.
If the old site was HTTP and the new one is HTTPS, some image or script still requests the old insecure address from inside a secure page, right where trust matters most.
What actually checking looks like.
Two failures share one habit: verify the invisible. Confirm the discourage-search-engines box is off before you call it live, and swap URLs with WP-CLI search-replace, which unpacks each serialized value, changes the string, and repacks it at the correct length. Always dry-run first.
If any address changed, build the 301 map before launch, not after the 404s roll in. Every old URL Google indexed should land somewhere on purpose.
Copy the uploads directory across on its own and spot-check the pages people visit most. Then force HTTPS everywhere so no image or script phones home to the old insecure address. The database is only half the move; the files and the scheme are the other half.
The worst one is a checkbox, not a fault.
It isn't a server, a database, or a line of code. It's a single tick in Settings, Reading, left on from staging. Pages fall out of Google over the following weeks, and the first signal you get is a traffic graph bending down, long after the cause is buried.
The site looks fine while every one of these is happening, which is exactly why a migration needs a checklist and not a memory. Run the same sequence every time and none of these five get the chance to hide. It's the same discipline that sits behind our pre-launch checklist, and it's the reason Keystone exists as an ongoing check, not a one-time favor.