ServMask Inc.

The most expensive moment of any WordPress disaster: discovering the daily backup you have been relying on for months does not actually restore. A backup you have never restored is not a backup. Run a restore drill quarterly. Time it. Document the gaps.

The most expensive line of text in a WordPress migration: Disallow: / Staging sites are often configured to block all search engines. Copy that robots.txt to production. Or copy the WordPress "Discourage search engines" toggle. Watch organic traffic disappear in a week. Check both after cutover.

Premium WordPress plugin licenses are usually bound to the site URL. Migration to a new domain invalidates the license. Plugin loads, but updates stop and premium features disable. Reactivate every premium plugin after cutover. Elementor Pro, ACF Pro, Yoast Premium, WP Rocket, Gravity Forms.

After WordPress migration, media uploads fail with "Unable to create directory" and plugin updates fail silently. The file owner on the new host is wrong. WordPress runs as one user (www-data, apache, nginx) but the extracted files belong to another (root, ftp). chown -R the right user on wp-content.

Homepage loads. Every inner page 404s after migration. The cause is not WordPress. It is the web server. Apache needs .htaccess + mod_rewrite. Nginx needs try_files in the server block. Rewrite rules do not travel with files. Reconfigure on destination.

Every WordPress migration that went badly skipped the pre-flight phase. PHP version match. MySQL match. Extension parity. SMTP credentials confirmed. DNS TTL lowered. Backup verified. Rollback owner named. Half an hour of prep prevents most migration disasters. Skip it at your own risk.

WordPress migration fails to import? Check PHP extensions on the new host. ZipArchive missing means archive imports fail. gd or imagick missing breaks image regeneration. mysqli missing means WordPress cannot connect at all. phpinfo() on both hosts. Compare. Match.

After migration, padlock icon broken? Browser console shows you exactly which resource is loading over HTTP. Each line is one fix. Most common: hardcoded http URLs in old post content. Run wp search-replace to fix them in bulk.

Migration to a new host without reconfiguring SMTP means contact form emails, password resets, and order confirmations either disappear or land in spam. The new server has no sender reputation. Plugin SMTP credentials may not match the new host's relay restrictions. Test every transactional email path before declaring the migration complete.

Never run a raw UPDATE ... REPLACE on a WordPress database to change domain names. PHP serialized data has length prefixes (s:5:"hello"). A naive replace breaks them and silently corrupts widget settings, plugin options, and user capabilities. Use wp-cli search-replace. It deserializes properly.

WP-Cron is not real cron. It runs only when someone visits the site. Low-traffic site? Scheduled tasks fire late or not at all. Backup that should have run at 2 AM runs at 9:30 AM when the first visitor shows up. Replace with a real cron job after migration. Once.

If your WordPress database is older than 2015, check its charset. SHOW CREATE TABLE wp_posts; If you see utf8 instead of utf8mb4, your site silently truncates rows containing emoji or 4-byte Unicode. Fix during migration since downtime is already planned.

If the old WordPress host had Redis or Memcached and the new one does not, expect performance to crater. Object cache hides hundreds of redundant queries on every page. Without it, you are hitting MySQL for data that used to come from RAM. Confirm the cache layer before DNS cutover.

PHP version is the silent variable in most failed WordPress migrations. Old host: PHP 7.4. New host default: PHP 8.2. Plugin written in 2019: dynamic property warnings on every page load. Audit PHP versions on both ends before cutover. The fix is simple before. Hard during.

After a WordPress migration, transactional emails send from a new IP. Check it immediately at mxtoolbox.com/blacklists.aspx If the IP is on a blocklist (rare but happens with shared hosts), every password reset, order confirmation, and contact form lands in spam for weeks before anyone notices.

Manual backups get skipped during the exact weeks they matter most. The week of a product launch, the week of a migration, the week of a security incident. Nobody remembers to click "Export" when the site is on fire. Scheduled backups eliminate the human variable. Set the cadence once, never think about it again.

The 3-2-1 backup rule for WordPress: 3 copies of the data 2 different storage media 1 copy off-site A backup file in /wp-content/ai1wm-backups/ on the same server as the site is one copy on one medium with zero off-site. That is not a backup. It is a hope.

WP_HOME and WP_SITEURL in wp-config.php override the database values. If a developer hardcoded these for the old domain, the migrated site stays pointed at the old URL no matter what you change in admin. Check wp-config.php first when URL settings refuse to update.

After a WordPress migration, re-save Permalinks (Settings then Permalinks then Save) even if you did not change anything. It regenerates the WordPress section of .htaccess for the new host's Apache config. Without this step, you may get 404s on every page except the homepage.

If a WordPress site uses Redis or Memcached, the object cache survives the database export but not the host change. The new host has a different cache server (or none). Plugins read stale cached values until you flush. Run: wp cache flush First step on every cache-enabled migration.