Post-Migration Verification Checklist: 50+ Things to Check After Moving Your WordPress Site

Yani I
Yani I Apr 3, 2026 ยท 16 min read
Post-Migration Verification Checklist for WordPress

You ran the migration. The site loads. The admin dashboard works. Migration complete, right?

Not yet. A site that loads is not the same as a site that works. After 60 million+ migrations, we have seen every kind of post-migration surprise: forms that silently stop sending emails, cron jobs that never fire, payment gateways that reject transactions, images that load on desktop but break on mobile, and SEO rankings that quietly disappear because a robots.txt file got reset.

Most of these problems are invisible on the surface. The homepage looks fine. But three layers deep, something critical is broken, and you only find out when a customer complaint arrives or your search traffic drops.

This checklist covers 50+ verification steps across 10 categories, ordered from the fastest checks to the deepest. Work through it top to bottom after every migration. Each section includes what to check, how to check it, and what to do if something fails.

Before You Start: Clear Everything

Before running any verification, purge every cache layer. Stale cached content will make you think things are working when they are not, or make you chase phantom issues that do not actually exist.

  1. Browser cache: Hard refresh with Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (Mac). Better yet, open an incognito/private window.
  2. WordPress caching plugin: WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache. Go to the plugin’s settings and clear all caches.
  3. Server-level cache: Many managed hosts run Varnish, Redis, or their own caching layer. Clear it from the hosting dashboard or ask support.
  4. CDN cache: Cloudflare, StackPath, BunnyCDN, KeyCDN. Purge everything from the CDN dashboard. Cloudflare users: Development Mode temporarily bypasses the cache entirely, which is useful during verification.
  5. Object cache: If you use Redis or Memcached for WordPress object caching, flush it. Most object cache plugins have a “Flush Cache” button, or you can use WP-CLI:
wp cache flush

Now every page load is hitting the actual server with fresh data. Start checking.

1. Quick Sanity Checks (2 Minutes)

These take seconds and catch the most obvious failures:

If any of these fail, stop here and fix them before continuing. A wrong Site URL or broken admin means deeper checks are pointless until the foundation is solid.

2. Content Verification

Your content is the whole point of the migration. Verify nothing was lost or corrupted.

Pages and Posts

Media Library

If images are broken: The most common cause is hardcoded URLs pointing to the old domain or server path. A migration tool like All-in-One WP Migration handles URL replacement automatically during import, but if you migrated manually, you may need to run a search-and-replace on the database. The Better Search Replace plugin can update old URLs to new ones across all database tables.

Widgets and Sidebars

3. Functionality Testing

A site can look perfect and still have broken functionality underneath.

Forms

Forms are the number one silent failure after migration. They look fine visually, but the submissions go nowhere.

User Accounts and Login

Comments

4. E-Commerce Verification

If you run WooCommerce, Easy Digital Downloads, or another e-commerce plugin, this section is critical. A broken checkout is lost revenue.

For a full walkthrough of WooCommerce-specific migration concerns, see our WooCommerce migration guide.

5. Email Verification

Email failures are invisible. Nobody tells you “I did not receive your email.” They just leave.

URL problems cause 404 errors, broken internal links, and SEO damage.

If many URLs are returning 404: Your .htaccess file may be missing or the server may not have mod_rewrite enabled. Go to Settings > Permalinks, click Save Changes, and WordPress will attempt to regenerate the file. If that does not work, ask your host to verify that Apache mod_rewrite is enabled, or if you are on Nginx, that the correct rewrite rules are in your server configuration.

For a deep dive on protecting your search rankings during any kind of migration, see our WordPress SEO migration checklist.

7. SSL and Security

For detailed steps on SSL migration, see our guide on moving WordPress from HTTP to HTTPS.

8. Performance and Caching

Your site may work perfectly but load slowly on the new host if caching and performance tools are not reconfigured.

9. Cron Jobs and Scheduled Tasks

This is the silent killer. Broken cron jobs cause failures that you do not notice for days or weeks: backups that never run, scheduled posts that never publish, subscription renewals that never process.

If WordPress cron is unreliable on the new host, you can disable it and use a real server cron. Add this to wp-config.php:

define('DISABLE_WP_CRON', true);

Then create a server cron job:

*/15 * * * * wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

10. SEO and Analytics

Losing SEO visibility after migration is the most expensive mistake, and it is entirely preventable.

For the complete SEO migration playbook covering six different migration scenarios, see our WordPress SEO migration checklist.

11. Third-Party Integrations

Integrations with external services often break silently because they rely on API keys, webhooks, or domain whitelists.

When Can You Decommission the Old Host?

Do not cancel your old hosting account the day after migration. Keep it active as a fallback:

Before decommissioning, take one final full backup from the old host. Store it somewhere independent (your local computer, cloud storage) as an archive. Once the old host is gone, that data is gone.

Printable Checklist Summary

Here is the complete checklist in condensed form. Bookmark this page or print this section for quick reference during your next migration.

Pre-check:

Quick sanity (2 min):

Content:

Functionality:

E-commerce:

Email:

URLs:

Security:

Performance:

Scheduled tasks:

SEO:

Integrations:

Decommission timeline:

FAQ

How long should the full verification take?

For a simple blog or brochure site, 30-45 minutes. For an e-commerce site with payment processing, forms, and third-party integrations, plan for 1-2 hours. It is worth the time. Finding a broken checkout two weeks after migration is far more expensive than spending an extra hour checking everything on day one.

What if I did not record pre-migration counts?

If you did not document your post/page/media counts before migrating, use the Wayback Machine (web.archive.org) to check your old sitemap or use a crawl tool to estimate. For future migrations, our guide on how to migrate WordPress to a new host includes a pre-migration preparation section that covers exactly what to document.

My site looks fine but something feels off. Where should I look first?

Check the error log. Go to Tools > Site Health > Info > Server and note the error log path, then review it for PHP warnings or errors. Many post-migration issues generate errors that do not show on the frontend but indicate problems: deprecated function calls, missing files, failed database queries. If your host provides an error log viewer in the control panel, start there.

Do I need to redo this checklist if I only migrated to a staging site?

Yes, but you can skip the SEO and decommissioning sections. Everything else applies equally to staging environments. In fact, running through this checklist on staging is exactly how you should validate a migration before doing it on production.

What is the most commonly missed item on this checklist?

Email. Every time. Forms look fine visually, but the email delivery chain is broken because SMTP credentials reference the old host, SPF records have not been updated, or the new server’s IP is not authorized to send mail for the domain. Always send a real test email and verify it arrives.

I used All-in-One WP Migration. Do I still need this checklist?

Yes. All-in-One WP Migration handles the technically complex parts of migration automatically: serialized data replacement, URL updates across the database, file transfer integrity. That eliminates an entire class of problems. But it cannot verify that your payment gateway accepts transactions on the new host, that your email provider’s SPF records include the new server, or that your CDN is pointing to the right origin. Those are environment-specific checks that only a human can verify.