Migration
WordPress migration validation: test the new host before changing DNS
WordPress migration validation is the final proof that the destination behaves like the source before and after DNS cutover. Files and a database import are only the transport step; runtime versions, URL handling, mail, cron, cache, certificates, and changing user data determine whether the move is actually safe.
Test the destination before DNS
Use a temporary hostname or hosts-file override to load the real destination while public users still reach the source. Compare important pages, admin login, media, PHP version/extensions, database connectivity, permalinks, plugin features, and error logs.
Fix destination-specific absolute paths or environment configuration before cutover.
Identify data that changes during the migration
Orders, comments, users, form submissions, uploads, memberships, and scheduled jobs can change after the initial database copy. Choose a maintenance window, replication/sync method, or final delta copy appropriate to the site.
Do not rely on DNS TTL to prevent lost writes.
Validate external dependencies
Check SMTP/email, payment sandbox/credentials, APIs, webhooks, cron, DNS records, redirects, SSL, analytics, search verification, and any source-IP allowlists. A new server IP can affect providers even when WordPress itself works.
Keep source logs available during the cutover for comparison.
Monitor after DNS and retain rollback
Verify multiple resolvers, real user paths, new writes, cron, mail, and logs. Keep the source intact until traffic has converged and the new database is unquestionably authoritative.
- Private-test destination.
- Plan changing-data sync.
- Check external integrations.
- Retain source through convergence.