WordPress migration: what to do before, during, and after

A WordPress migration sounds simple until the site goes live on the new host and half the images are broken, the contact form silently stops sending, and Google starts crawling a duplicate of the old domain. We’ve seen all of it. The good news is that none of it is inevitable.

Why migrations go wrong in the first place

Most failed migrations share one root cause: someone treated “copy the files and database” as the whole job. It isn’t. A WordPress site is a moving system. It has hardcoded URLs baked into the database, server-level dependencies (PHP version, required extensions, memory limits), caching layers, DNS propagation timing, and sometimes third-party integrations like Stripe or a CRM that need updated webhook endpoints the moment the domain resolves differently.

Builders who skip a structured process also skip the part where they verify the new environment actually matches the old one closely enough to matter. A plugin that ran fine on PHP 8.0 can throw fatal errors on 8.2. That’s a five-minute fix when you catch it in staging. It’s a 2 a.m. emergency when you catch it in production.

The pre-migration work that actually saves the project

Before we touch a single file, we do a full environment audit on the destination host. PHP version, max execution time, upload limits, whether the host supports WP-CLI, whether object caching is available. We also export a verified database backup and a full file backup, stored somewhere that isn’t the same server we’re about to touch.

If the migration involves a redesign or platform change, this is also where we run our SEO and technical audit on the existing site. You want a clean record of every indexed URL, every redirect that already exists, and the current Core Web Vitals baseline before you move anything. That data becomes the benchmark that tells you whether the new setup is actually better or just different.

One more thing most guides skip: inventory your active plugins and confirm license keys. Several premium plugins (Elementor Pro, Advanced Custom Fields Pro, Gravity Forms) are domain-locked. Migrating without transferring or re-activating licenses means you lose auto-updates and support on day one.

Search rankings during a migration: the real risk

Organic rankings survive WordPress migrations when the URL structure stays the same. They get damaged when URLs change and no one sets up the redirects. They get destroyed when the new site accidentally goes live with “Discourage search engines” still checked in Settings, which is a checkbox WordPress enables by default in staging environments.

If the URL structure is changing, for example because you’re moving from a poorly structured old site to a custom WordPress build with cleaner permalinks, then a complete 301 redirect map is non-negotiable. Every old URL that had any inbound links or indexed traffic needs a redirect pointing to its closest equivalent. This isn’t optional and it isn’t something you do after launch when you notice traffic dropped.

Google’s own site move documentation is worth reading. The short version: use 301s, update Search Console with the new property, and expect up to a few weeks for full stabilization even when everything is done correctly.

A pre-launch migration checklist

• Full database and file backup verified and stored off-server
• Search-and-replace on hardcoded URLs in the database (we use WP-CLI’s search-replace command with the --dry-run flag first)
• Staging review: all pages, forms, checkout flows, and third-party integrations tested before DNS change
• 301 redirect map in place for any changed URLs, implemented before the old domain stops resolving
• “Discourage search engines” unchecked, SSL active, and correct site URL confirmed in wp-config and Settings

After go-live: the 48-hour window that matters

DNS propagation takes anywhere from a few minutes to 48 hours depending on TTL settings and the registrar. During that window, some visitors hit the old server and some hit the new one. We lower the TTL to 300 seconds about 24 hours before any migration so the switchover is as fast as possible. We also keep the old server live for at least a week after the cut, not just as a backup but because some crawlers and integrations cache IP addresses longer than you’d expect.

Once the new site is fully live, we run a fresh crawl with Screaming Frog to catch any remaining broken internal links, check Core Web Vitals in PageSpeed Insights, confirm Search Console is picking up the new property, and resubmit the sitemap. If you’re on one of our care and maintenance plans, this post-migration monitoring is part of the ongoing work, not a one-time event.

A well-executed WordPress migration is mostly boring, and that’s exactly how it should be. If you’ve got a move coming up and you’d rather not find out what can go wrong, book a free 30-minute call and we’ll scope it out with you.