First time in the same room since 2017. 6,000,000 million sites still running on what we built in 2013.

Post-migration smoke test: Homepage Key pages Login/admin save Media upload Forms Checkout/lead capture Transactional email Scheduled jobs SSL redirects Cache/CDN purge Search for old domain Analytics/Search Console Do it before the team moves on.

Before any risky WordPress change, define rollback in concrete terms. Not “we have backups.” Which archive? Stored where? Restored how? Who can access it? How long will it take? What data will be lost if we roll back? A rollback plan is specific or it is a wish.

A migrated WooCommerce site can look fine while Action Scheduler is stalled. Pages load. Admin works. But renewals, webhooks, cleanup jobs, and emails stop running. After migration, check pending/failed scheduled actions and confirm wp-cron or server cron is actually firing.

A backup folder with 400 old archives is not a strategy. It is delayed cleanup. Good retention answers three questions: How often do we back up? How long do we keep copies? How many restore points can we afford to store and test? Backups need policy, not hoarding.

After migrating a site with HSTS, SSL mistakes hurt more. Browsers remember “HTTPS only.” If the new origin cert, proxy SSL mode, or redirect chain is wrong, users do not fall back to HTTP. They hit a hard failure. Validate cert + proxy mode + redirects before DNS cutover.

If a 3GB WordPress import keeps dying in the browser, stop retrying the same path. Upload the archive by SFTP/SSH or place it in cloud storage, then import server-side. You bypass browser timeouts, flaky networks, upload_max_filesize, and a lot of WAF pain.

A WordPress import can fail even when wp-content has plenty of free space. Check the temp path. PHP upload_tmp_dir, /tmp, open_basedir, and plugin temp folders all need writable space during restore. “Disk space available” does not always mean “restore workspace available.”

Multisite migrations fail in ways single-site moves never do. You are not moving one domain but a network: per-site siteurl/home, domain mapping, wildcard DNS, sunrise.php, uploads paths, and SSL for every mapped domain. Audit the network, not just the main site.

After DNS cutover, purge CDN cache. Otherwise some visitors may still get HTML, redirects, or assets cached from the old origin. The A record is correct, but the edge is serving yesterday’s site. Migration checklist: DNS flip → CDN purge → verify from another network.

Never run raw SQL search/replace on a WordPress site unless you like corrupting serialized data. Serialized strings include length counts. Change the URL length without updating the count and PHP cannot unserialize the value. Use a serialization-aware tool. Always.

Large WordPress restores should not depend on a browser tab staying alive. Upload limits, WAFs, flaky Wi-Fi, and PHP timeouts all sit in the browser-upload path. For large archives, put the backup in cloud storage or on the server and import from there. Remove the weakest link.

WordPress migrated cleanly but still shows old settings? Check persistent object cache. Redis/Memcached can keep stale options, transients, and plugin state from the old environment. Flush object cache at cutover and confirm WordPress points at the new cache endpoint.

The migration mental model that saves you every time: WordPress data transfers (database + files). Infrastructure does not: DNS, email auth, TLS certs, nginx rules, server cron, PHP limits, offloaded media. The tool moves the site. You reconfigure the environment. Checklist both.

AIO vs UpdraftPlus, the honest version: UpdraftPlus is backup-first and splits a backup into separate component zips, further split at 400MB. A 2GB site can be 7-10 files. All-in-One WP Migration is migration-first: one .wpress file, whatever the size, restored by drag-and-drop.

Before you migrate a media-heavy WordPress site, ask one question: are the uploads actually on the server? If a plugin offloads media to S3 or a CDN, your archive may capture nothing while the database still points at the old bucket. Migrate the media supply chain, not just the site.

If your backup archive contains your full database, it contains your users' data in plain form to anyone who gets the file. Pro backups can be password-protected and encrypted, so a leaked or stolen archive is not a breach. Worth it before you push backups to third-party cloud storage.

Migrating Apache to nginx? Your .htaccess is dead weight on the new server. nginx does not read it. Every 301 redirect, every security block, every rewrite in that file has to be re-implemented as nginx server block directives by hand. Nothing warns you they are gone.

Free migration plugin comparison, honestly: Duplicator free caps the archive at 500MB and needs FTP plus a manual database setup step. All-in-One WP Migration free has no archive size cap and restores by drag-and-drop, no FTP, no manual DB. Different workflow entirely.

Two failure modes after a manual WordPress move, two different lines in wp-config.php: "Error establishing a database connection" means wrong DB_NAME / DB_USER / DB_PASSWORD / DB_HOST for the new server. Install screen or white screen means table_prefix in the file does not match the imported tables.