Migrating WordPress to a new host is one of those tasks that sounds risky mainly because it is done rarely, so few people have built up a confident, repeatable process for it. In practice it follows a clear, well-established order, and the moves that go wrong almost always skipped a step rather than encountered some unavoidable technical problem. This guide walks through that order from first backup to final DNS switch.
Before migrating WordPress: why the order matters
A hosting migration touches three separate things that all need to be correct at the same time for the site to work: the files and database that make up the site, the server configuration that runs them, and the DNS records that tell the internet where to find the site. Doing these out of order, switching DNS before the new server is actually ready, for example, is where most avoidable problems come from. Following the steps below in sequence keeps all three aligned.
Step 1: A full backup and inventory
Start with a complete backup of the current site: every file and the full database, not a partial export. Alongside the backup, note anything specific to the current hosting environment that the new host will need to match or account for, custom PHP settings, cron jobs, SSL certificates, and any server-level redirects that live outside WordPress itself. This inventory prevents the common surprise of a site that looks migrated but is quietly missing a piece of configuration nobody remembered to check.
Step 2: Choosing and setting up the new host
Before moving anything, set up the new hosting account and confirm it meets WordPress's current requirements for PHP version and other server software. This is also the point to check whether the new host offers a staging environment or migration tools, since either can meaningfully simplify the steps that follow.
Step 3: Moving files and the database
Copy the site's files to the new server and import the database, either using a migration plugin built for this purpose or manually via file transfer and a database export and import. Migration plugins handle most standard WordPress sites reliably and are worth using for anything without heavy customisation. Larger or more complex sites sometimes benefit from a manual approach, which gives more visibility into exactly what is being moved and lets problems be caught step by step rather than inside an opaque plugin process.
Step 4: Updating the configuration
Once files and database are on the new server, WordPress's configuration file needs updating with the new database connection details, and any hardcoded references to the old server's specific paths or settings need checking. This is a common place for small mistakes to hide, so it is worth reviewing carefully rather than assuming a migration tool caught everything automatically.
Step 5: Testing on a temporary URL before DNS changes
Before touching DNS at all, test the migrated site on a temporary address, either the new host's provided URL or by editing your own computer's hosts file to preview the new server while the domain still publicly points elsewhere. Check every important page, test forms and checkout if applicable, and confirm images and other media are loading correctly. This step is what actually prevents downtime, since any problem found here gets fixed before the public switch, not after.
Step 6: Lowering the DNS time-to-live in advance
A day or two before the planned switch, lower the time-to-live setting on the domain's DNS records. This setting controls how long the wider internet caches the old DNS information, and lowering it in advance means that when the actual switch happens, it propagates faster and more predictably, minimising the window where some visitors see the old site and others see the new one.
Step 7: The DNS switch itself
With testing complete and the time-to-live already lowered, update the domain's DNS records to point at the new host. Propagation is rarely instant everywhere, so expect a short window, usually a few hours, where DNS is still settling globally, though most visitors will see the new site within a short time if the time-to-live was properly lowered beforehand.
Step 8: SSL, email and other DNS records
Confirm the SSL certificate is correctly installed and working on the new server, since a missing or misconfigured certificate produces a very visible browser warning. If email runs through the same hosting account, check MX records were carried across correctly. Any other DNS records, such as those used for site verification or third-party services, need reviewing too, since they are easy to forget when attention is focused on the main website move.
Step 9: Checking the site after the move
Once DNS has propagated, check the live site again from several devices and, if possible, from a location outside your usual network, since a site that looks correct to you might still be showing an old cached version to others during propagation. Watch analytics and uptime monitoring closely for the first day or two, and keep the old hosting account active for a short overlap period in case anything needs checking against the original before it is cancelled.
Migrating a store, not just a brochure site
If the site being moved runs a shop, a few extra checks matter: confirm payment gateway settings carried across correctly, place a genuine test order on the new server before the public switch, and check that any scheduled tasks, such as abandoned cart emails or stock synchronisation, are running on the new host rather than quietly still pointing at the old one. A shop that looks visually identical after migrating WordPress can still have a broken checkout if these specifics are not verified directly, since a payment gateway misconfiguration does not always produce an obvious visual sign of the problem.
What to tell anyone else who touches the site
If more than one person manages content or plugins, let them know about the migration in advance and confirm they have updated any bookmarked admin login links or saved FTP details once the move is complete. A colleague still logging into the old server's admin panel after the switch, unaware anything changed, is a common and entirely avoidable source of confusion in the days following a migration.
Rolling back if something goes wrong
Keeping the old hosting account active and untouched for a short period after the switch is the simplest rollback plan: if a serious problem appears, DNS can be pointed back at the old host while the issue on the new one is diagnosed properly, rather than trying to fix a live, broken site under pressure. This is precisely why step 9's overlap period matters, and why cancelling the old host immediately after a migration is worth avoiding.
Choosing a migration window that suits your traffic pattern
Beyond avoiding a busy season for the business generally, it also helps to pick a time of day or day of week when the site's own traffic is naturally lower, since DNS propagation and any final checks are easier to manage calmly with fewer visitors actively browsing during the transition. For most business sites, an early morning or late evening switch on a weekday, outside the hours the target audience is most active, gives the smoothest experience with the least visible disruption if anything does need a quick fix.
Working with a host that offers migration support
Many hosts, particularly ones aimed at WordPress specifically, offer to handle parts of the migration themselves or provide a dedicated migration tool built for their platform. Using this support, where available, can remove a meaningful amount of the manual work described above, though it is still worth understanding the steps yourself so you can verify the result rather than simply trusting the process blindly. Ask specifically what the host's migration service does and does not cover before assuming it handles everything in this guide.
Redirect considerations if the URL structure changes
A straightforward hosting move keeps the same domain and URL structure, in which case redirects are not usually needed. If the migration is combined with any change to how the site is organised, moving from a subdomain to the main domain, for instance, redirects become essential and deserve their own careful planning, since that combination turns a simple hosting move into a more involved migration with real search visibility at stake if handled carelessly.
Common mistakes when migrating WordPress
The most common mistake is switching DNS before testing is genuinely complete, treating the temporary URL preview as optional rather than essential. A close second is forgetting email, either not checking whether it needs moving at all, or moving it without verifying it still works afterwards. A third is cancelling the old hosting account too soon, removing the safety net before enough time has passed to be confident the new setup is fully stable.
Timing the migration around the business
Choosing a quiet period for the business, outside a busy sales season or an important marketing campaign, gives more room to catch and fix anything unexpected without the added pressure of live customer traffic depending on the site working perfectly. This is not always possible for every business, but where there is a genuine choice of timing, migrating WordPress during a naturally quieter stretch reduces the stakes of the whole exercise considerably.
A note on caching and CDN services
If the site uses a content delivery network or a third-party caching service sitting in front of the hosting itself, that layer needs its own attention during a migration: it may need pointing at the new server's address, and its own cache may need purging after the switch so it stops serving a cached copy of the old site to visitors. This is easy to overlook because it sits conceptually separate from the hosting account itself, but forgetting it can mean visitors see stale content or errors even though the underlying migration technically succeeded.
A final check before calling it complete
Before considering a hosting migration finished, run through one last pass: confirm the SSL certificate shows no browser warnings, submit the site again in Search Console to prompt a fresh crawl, and check that any scheduled backups on the new host are actually configured and running, since a fresh server does not inherit the old one's backup schedule automatically. Treating migrating WordPress as complete only once this final check is done, rather than the moment the site visually loads correctly, closes the small gaps that otherwise surface weeks later.
Getting a hosting migration done without the risk
Migrating WordPress to a new host is routine, well-understood work when the steps above are followed in order, but it is also exactly the kind of task where a single skipped step can cause a genuinely disruptive outage. Our WordPress development service includes hosting migrations handled this way, and pairs with our broader guide on speeding up WordPress if better hosting is the reason for the move in the first place. Get in touch if you have a migration coming up and want it handled properly.