The details that decide a migration
Inventory first
Before touching anything we list what the site consists of: post types and counts, users by role, media volume, active plugins and where each keeps its data, scheduled tasks, mail configuration and every URL a crawler or the sitemap can find. On a WooCommerce site we note whether orders sit in the posts tables or in WooCommerce's dedicated order tables, because the two are exported differently. This list becomes the checklist the finished migration is measured against.
Search-replace without breaking serialized data
WordPress stores many settings as serialized PHP arrays, where each string is recorded together with its length. Change a domain inside one with a raw SQL replace and the length no longer matches, so WordPress discards the whole value. Widgets empty out and theme options reset. We run replacements with WP-CLI, which unserializes, replaces and repacks each value, and we do a dry run first to see how many rows each table would change. Builders that keep layouts as JSON in post meta need their own handling, since slashes in URLs are escaped there.
Users and passwords
Between two WordPress installs, accounts move with their password hashes and people log in as before. From another CMS the hashes use a different scheme. We can either ask everyone to reset on first visit, or add a small bridge that checks the old hash once and saves a WordPress one, which spares your support inbox. When sites are merged, user IDs collide, so authorship, order ownership and course enrollments are remapped to the new IDs. Role data also depends on the table prefix, a detail that locks administrators out when it is missed.
Redirects are part of the migration
Every old URL gets one of three outcomes: it stays the same, it redirects with a 301 to its closest equivalent, or it is retired on purpose. We build the map from a crawl plus the pages that receive search traffic and backlinks, load the rules at server level where possible, and test the full list on staging. Redirect chains and blanket redirects to the home page are the two shortcuts we refuse to take.
Cutover and the week after
For busy sites we freeze content or place the store in a short maintenance window, run a final delta of orders and signups, switch DNS with a low TTL already in place, and leave mail records untouched. Then we watch. Server logs show any 404s that slipped past the map, Search Console shows crawl errors and indexing, and we confirm the staging noindex flag is off. Pairing the move with a maintenance plan keeps that watch going after the first week.