WordPress migrations have a way of looking simpler than they are. The basic idea is straightforward — move the files and the database from one place to another, point the domain at the new location, done. In practice, the gap between “moved” and “actually working as well as it did before” is where most migrations go wrong. Small oversights become big problems. Things that should not have changed mysteriously have. Rankings drop, forms stop working, images break, and the team that was promised a smooth transition is now reverse-engineering whatever the migration plan was supposed to be.
The good news is that migrations are not actually mysterious. They follow a small number of predictable failure modes, and most of those failure modes are preventable with a calm, ordered approach. What follows is the version that tends to work, broken into the phases that determine whether the migration goes smoothly.
Before you touch anything: planning
The most expensive migration mistakes are made before the migration starts, in the form of decisions that were not actually decisions but unexamined assumptions. The planning phase is where those assumptions get surfaced.
What exactly is being migrated? A WordPress site is a collection of files, a database, and a set of dependencies on external services. Files include the active theme, all plugins, the uploads directory, and any custom code. The database includes posts, pages, comments, users, settings, and a substantial amount of plugin data. Migration plans that forget any of these tend to discover the gap at the worst possible moment.
What is the migration trying to achieve? Different goals call for different approaches. Moving from one host to another is different from changing domain. Changing PHP versions is different from upgrading to a new server architecture. Combining a migration with a redesign is different from a like-for-like move. Knowing exactly what the migration is doing — and is not doing — keeps the work scoped.
What does the destination look like? Confirming, before any migration begins, that the destination has the right PHP version, the right database engine, the right memory limits, the right SSL setup, and the right email-sending configuration prevents most of the post-migration investigations.
What is the rollback plan? Migrations sometimes have to be reversed, either because something has gone wrong or because the business decision changes. A migration without a rollback plan is a one-way trip. The plan can be simple — keep the original site running until the new one is verified — but it has to exist.
The backup that is actually a backup
Before any migration step, a complete backup of the source site is non-negotiable. “Complete” here means files and database, stored somewhere not on the source server, recent enough to capture any last-minute changes.
This is the moment to test the backup. An untested backup is a hopeful guess. The test is straightforward: spin up a local environment or a staging server, restore the backup into it, and verify that the restored site works. If it does not, the backup is not a backup, and the migration is not safe to proceed. Finding this out before the migration costs an afternoon. Finding it out after the migration costs days.
The same applies to the destination. Before any data is migrated, the destination should have its own initial backup taken. This protects against any errors during the migration that might affect the new environment.
The actual move
With planning done and backups verified, the migration itself is mechanical. The order of operations matters less than the discipline of doing each step deliberately.
Files first or database first is a matter of preference, as long as both are moved in their entirety. For files, the uploads directory tends to be the largest piece — sometimes several gigabytes — and is worth confirming has been copied completely before proceeding. For the database, the export needs to capture every table, including any that plugins have created in their own naming convention.
The database is where the most subtle migration issues hide. URLs stored throughout the database — in post content, in widget configurations, in plugin settings, in serialized data — refer to the old domain. After the migration, these references need to be updated to the new domain. Tools like WP-CLI’s search-replace command, or plugins like Better Search Replace, handle this safely by understanding serialized data. A naive find-and-replace on the SQL dump will corrupt serialized fields and produce a site that is broken in ways that are very hard to diagnose later.
If the domain is changing, the URL update is essential. If the domain is not changing — say, a host-to-host migration of the same site — it is still worth verifying that nothing in the database hardcodes the old host or path.
Testing before pointing the domain
One of the most useful migration techniques is to verify the new site is working before any visitor sees it. There are several ways to do this: modify the local hosts file on your own machine to point the domain at the new server, use a staging URL provided by the host, or configure a temporary domain for testing.
Whatever the method, the testing phase is when the things that broke during the migration get caught. Common items on the checklist:
Every key page loads and looks correct. Not just the homepage — sample pages from across the content types, including pages with embedded forms, complex layouts, and dynamic elements.
Forms actually submit and deliver. Filling in a contact form on the new site and confirming the email arrives at the correct address is the kind of test that uncovers SMTP configuration issues before users do.
Logins work. Test as an administrator, an editor, and any custom role that is in use.
The admin area loads cleanly. No PHP warnings or notices, no plugin errors, no missing assets. WordPress logs at WP_DEBUG level are worth checking even if everything looks fine in the browser.
External integrations function. Payment gateways, email delivery services, analytics, and CDN connections should be verified individually.
Performance is acceptable. A quick PageSpeed Insights run on a few key pages confirms the new server is performing as expected.
Skipping any of these checks before going live is what produces the post-migration emergency. Doing them properly takes an hour.
The DNS switch and the watching period
When the new site has been verified, the actual move-over happens at the DNS level. The domain’s records are updated to point at the new server. DNS propagation usually takes minutes to hours, depending on the previous TTL values. During this window, some users will be hitting the old server and some the new one.
This is an argument for lowering the DNS TTL a day or two before the migration, so that the switch happens quickly. It is also an argument for keeping the old site running, in read-only state if possible, until you are confident the new site is handling all traffic correctly.
The first few days after migration are a watching period. Errors that did not appear in testing sometimes appear under real traffic. Caching issues sometimes surface only after real visitors arrive.
This is the moment to verify that analytics is still tracking, that email delivery is still working, that scheduled tasks are still firing, and that monitoring is in place. A site that has just been migrated needs more attention, not less, for the first week.
Protecting search rankings
A clean migration usually has minimal impact on search rankings, but a sloppy one can cost significantly. The key protections:
URLs that existed before migration should still exist at the same paths, or should be redirected with permanent (301) redirects to the new locations. Search engines, and users with bookmarks, are pointing at the old URLs. Any that returns a 404 is lost value.
The robots.txt file should permit the new site to be indexed. Migration environments sometimes have a “discourage search engines” setting enabled for testing, which can survive the move into production if not explicitly checked.
SSL must work on the new site, with no mixed-content warnings.
None of these are complicated. All of them are easy to overlook in the rush of the actual move.
The short version
WordPress migrations are not mysterious, but they reward discipline. Most failures come from skipped steps: incomplete backups, untested rollback plans, environment mismatches between source and destination, naive URL replacement that corrupts serialized data, going live without verification, and forgetting redirects that protect rankings. A calm, ordered approach — plan thoroughly, back up rigorously, test before pointing the domain, watch carefully after the switch — produces migrations that go uneventfully. Uneventful is what success looks like in this work. The migrations that get talked about are usually the ones where something went wrong.
