The Week After a WordPress Migration Decides If It Worked

The DNS change propagated on a Friday afternoon. The homepage loaded, the admin worked, and the owner considered the migration finished. On Monday a customer reported that the contact form sent nothing. On Tuesday an editor discovered that scheduled posts had stopped publishing. On Wednesday the old host closed the account for non-payment, which was correct, because the migration had been announced as complete. The new site was up. The business around it was not.

A migration has two halves, and the second one is longer. The first is moving the files, the database, the mail and the DNS. The second is proving that everything still works, finding what the move broke, and only then closing the old account. Most guides stop at the first half because the cutover is the visible event. The week after is where the failures live.

This is the operational checklist for that week. It assumes the cutover itself is done, and it focuses on what to verify, in what order, and what to leave in place until the evidence is in.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. The checklist works with any host; the links at the end are for the migration tooling and the backup that should exist before the first step.

The migration is not finished when DNS resolves

DNS is a pointer. It says where requests should go, and after the change it says so from resolvers that have a mixture of old and new answers cached. Everything that depends on the pointer changes at the same moment: web traffic, mail delivery, cron, API callbacks, CDN origins and the crawlers that decide whether the new site is the old site.

That is why the first day is not a celebration. It is a verification pass. The site may look right because the theme and the content moved correctly, while the parts that are not visible on a homepage, mail, scheduled jobs, form delivery, payment callbacks, search indexing, are the ones that fail quietly.

Write the verification list before the cutover, and work through it with the clock running. The point is not to find something to fix. It is to be able to say, with evidence, that the site is fully operational, and to know which parts were not tested if something surfaces later.

The first 24 hours: verify the site, not the homepage

Open the site in a private window, with the cache disabled, from a network that is not the office. Then walk the list below. It is ordered by how expensive the failure is, not by how easy the check is.

Two checks deserve their own line. The first is mail: a password reset sent to an address on the old mail provider proves nothing, because the delivery path may still be the old one. Use a mailbox at a different provider. The second is cron, because a migrated WordPress site often arrives with wp-cron disabled and no system cron installed in its place, which means backups, scheduled posts and subscription renewals all stop without an error.

curl -sI https://example.com/old-page/ | head -8
wp option get home
wp option get siteurl
wp cron event list --fields=hook,next_run_relative
wp plugin list --status=active --fields=name,version

The option check catches the most common post-migration mistake: a database restored with the staging URL baked in, then patched in one place and not the other. If home and siteurl disagree, redirects and admin links will behave oddly even though the pages render.

Search Console is how you find what broke

Search engines notice migration mistakes before customers do, because they request thousands of URLs and record the status codes. The reports that matter in the first week are the page indexing report, the 404 report and the crawl stats. Open them on day one, day three and day seven.

Submit the new sitemap. If the domain changed, use the change of address tool, which is a specific operation for a domain-level move and not a substitute for redirects. If only the host changed and the domain stayed, there is nothing to submit beyond the sitemap; the URL is the identity, and it did not move.

The 404 report is the migration's early warning system. A spike in 404s usually means the redirect map missed a pattern: paginated archives, search result URLs, old feed paths, attachment pages, or a trailing slash mismatch. Fix the pattern rather than the individual URLs, then re-crawl the sample and confirm the status codes changed.

One report to ignore in week one is rankings. A migration can produce a temporary dip while the new environment is crawled and evaluated. Panicking at day two and changing the structure again adds a second variable to an already noisy measurement. Give it two weeks before drawing conclusions, and change one thing at a time.

The redirect map is the migration's memory

Every URL that existed on the old site and does not exist on the new one needs a decision: redirect it, or let it return 410. Redirecting everything to the homepage is not a decision; it tells search engines that every old page is the same page, and it tells visitors that the link they clicked is broken.

Build the map from evidence, not from memory. The old sitemap, the web server access log, the Search Console pages report and a crawl of the old site if it is still reachable. Then map one-to-one where the content still exists, and to the nearest category or parent page where it does not. Keep the map in a file, so the next migration starts with a list instead of an argument.

Keep redirects in one layer. Rules split between the web server, a plugin and a CDN are hard to reason about and harder to remove. If the site already uses a redirect plugin, put the map there and leave the server rules for the http-to-https and www-to-apex changes that should exist regardless.

Cron, mail and integrations need re-registering

WordPress cron is a function that runs when a request arrives, not a scheduler. On a new host, that distinction becomes visible: a low-traffic site may not trigger the backup job at the expected hour, and a site with DISABLE_WP_CRON set may have no runner at all until one is installed. Check both the constant and the system crontab, then trigger a known event and confirm it ran.

Mail is the second integration that needs a fresh look. The SMTP credentials may have moved, the sending domain may need re-verification, and SPF and DKIM records may still point at the old provider. A site that can receive mail but cannot send a password reset is half-migrated, and the failure is invisible until someone needs it.

Then the outbound integrations: payment webhooks, shipping callbacks, CRM syncs, analytics, the CDN origin, and any API that allowlists the server's IP address. A new host means a new IP, and an allowlist that was never updated rejects requests without telling anyone except the integration's log. Send a test event to each and watch for a 200 at the destination, not at the site.

Decommission the old host without losing the safety net

The old environment is the rollback. Keep it reachable for at least thirty days, read-only if the host allows it, and do not cancel the account on the day the DNS changes. That window is how a missing file gets recovered, how a mail record gets checked, and how a bad decision gets reversed without rebuilding from a backup.

Lower the DNS TTL to five minutes before the cutover, and leave it low for the first week. After the new site has been stable for a week, raise it again and put the TTL change in the calendar so it is not forgotten. A five-minute TTL left in place forever adds query load and is not a problem, but it also masks the fact that nobody reviewed the DNS since the migration.

Before cancelling, confirm four things: the new site has run for thirty days, the mail is fully on the new provider, the zone file is exported and stored, and there is an off-host backup of the new environment. Then cancel, and remove the old staging copies and test installs, which are the doors that outlive migrations and get forgotten for years.

The seven-day close-out list

1. Day one: forms, mail to an external mailbox, login per role, permalinks, media, cron, redirects.
2. Day one: confirm no staging noindex, basic auth or discouraged-search setting survived.
3. Day one: submit the sitemap and open the 404 report.
4. Day three: review 404 patterns, fix the map, re-crawl a sample.
5. Day three: send a test event to every outbound integration and check the destination.
6. Day seven: review crawl stats and indexing, and confirm scheduled posts published.
7. Day thirty: raise the TTL, archive the old zone, take a fresh off-host backup, then cancel the old host.

Tools shorten this rather than replace it. SiteGround includes a migration plugin, staging and a panel restore, which covers the cutover and the rollback window in one place. Jetpack's backup service gives the new environment a restore point outside the account, which is the thing that makes cancelling the old host safe.

Where the tooling is unnecessary: a site moving between two hosts that both provide staging, migration tooling and daily snapshots. There the money is better spent on the redirect map and an hour on day one. The decision rule is simple: the migration is finished when the old host is cancelled, and the old host is cancelled when thirty days of evidence say the new one is doing the job.