A migration copies an application into a different operating environment. The files and database can be intact while PHP, paths, permissions, DNS or server rules make the new copy fail. Treat “it worked on the old host” as useful evidence, not proof that the transfer was complete.
Keep the old site available
Do not cancel the old hosting or overwrite its last working copy. Put the new installation behind a hosts-file or curl --resolve test so the public domain can remain on the old server while diagnosis continues.
Record the old and new PHP versions, web server, document root, database version and enabled extensions. Take a fresh database export before accepting new content on both copies.
Confirm the request reaches the intended server
A browser may still use cached DNS, an old AAAA record or Cloudflare. Test the hostname against the new IP while preserving the real Host header and TLS name:
curl -I --resolve example.com:443:203.0.113.20 https://example.com/Compare the response certificate, headers and body with the old host. IP-only browsing is unreliable because virtual hosts and WordPress redirects depend on the hostname.
Verify the migration set
Confirm the new document root contains WordPress core, wp-content, hidden files such as .htaccess, and the intended wp-config.php. Compare file counts and transfer logs rather than assuming a green progress bar means every file arrived.
Check that the database import includes the expected table prefix and recent posts or orders. A valid but old database often looks like a broken migration.
Check database configuration and URLs
Verify DB_NAME, DB_USER, DB_PASSWORD and DB_HOST against the new hosting account. Test the database user directly with a read-only query. Do not grant global privileges merely to make the error disappear.
Inspect home and siteurl. If staging or temporary URLs entered the database, correct them deliberately. Serialized values require a WordPress-aware search-and-replace; raw SQL replacement can corrupt stored lengths.
Compare PHP, extensions and limits
Match the old PHP version first when practical, then upgrade in a controlled test. Confirm required modules such as mysqli, curl, mbstring, XML, ZIP, GD or Imagick. Compare memory_limit, upload limits, execution time and disabled functions.
Enable private logging without displaying errors:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Reproduce one failure, save the relevant log lines, then disable verbose logging when finished.
Repair ownership, permissions and generated paths
Files uploaded as the wrong system user can be readable by the web server but unwritable by WordPress. Correct ownership through the hosting panel or provider; avoid blanket 777 permissions.
Clear only reproducible caches and generated CSS after backing up. Review absolute paths in cache, security and backup plugins, cron commands, must-use plugins and server configuration.
Review web-server rules
Apache .htaccess directives may not be supported on the new plan. Nginx does not interpret .htaccess at all. Look for old PHP handler lines, forced domains, hard-coded paths, access restrictions and proxy headers.
Regenerate normal WordPress permalink rules only after preserving custom directives. A 500 on every page and a 404 only on inner pages are different faults.
Validate before DNS cutover
Test homepage, login, editor, media, REST, scheduled tasks, forms, email and any transaction path relevant to the site. Check HTTP-to-HTTPS and root-to-www redirects as a complete chain.
After DNS changes, monitor both IPv4 and IPv6, certificate issuance and error logs. Keep the old environment read-only for an agreed rollback window.
When urgent repair becomes recurring care
Repeated migration failures usually reveal missing environment records or untested backups. Recurring maintenance should retain a hosting specification, off-server backups, restore tests, expiry dates and a cutover checklist. The goal is not merely to make the new homepage load; it is to prove that the whole application survived the move.