How to Migrate WordPress to a New Host Without Losing Anything

Key Takeaways

• Migrating WordPress to a new host means moving three distinct components successfully, your files, your database, and your domain’s DNS pointing, and a migration only genuinely succeeds when all three transfer correctly and in the right sequence.
• The safest approach to any migration is testing the site fully on the new host before changing any live DNS, using either a temporary URL your new host provides or a local hosts file edit, so you can catch and fix problems before any visitor or search engine notices anything changed.
• Lowering your domain’s DNS TTL value 24 to 48 hours before the actual cutover is the single most effective step for minimizing downtime, since it ensures the DNS change itself propagates in minutes rather than potentially taking a full day or more.
• A migration plugin such as All-in-One WP Migration or Duplicator handles the technical complexity of packaging your files and database together automatically, and is the recommended method for most site owners over a fully manual transfer.
• Keeping your old hosting account active and unchanged for at least a week after cutover, rather than canceling it immediately, provides a genuine safety net, since some visitors and search engine crawlers may still reach the old server briefly during DNS propagation.
• Search engine rankings are not automatically lost during a well executed migration, since a domain does not change, but a poorly executed migration involving broken URLs, missing redirects, or extended downtime can absolutely cause a real, measurable ranking impact.
• This guide walks through the complete migration process, the pre-migration preparation, the plugin based and manual transfer methods, the safe DNS cutover sequence, and the specific post-migration checks that confirm nothing was actually lost.

Introduction

Moving a WordPress site to a new hosting provider is one of those tasks that feels considerably more intimidating than it actually needs to be, largely because the potential consequences of getting it wrong, lost content, broken links, extended downtime, or a real hit to search rankings, are genuinely serious enough to warrant real caution. The good news is that a properly planned migration, following the correct sequence and using the right tools, carries very little real risk, and the specific steps that prevent every one of those potential problems are well understood and entirely achievable even for someone who has never done this before.

This guide walks through the complete migration process from start to finish, covering what actually needs to move and why, how to test everything safely on the new host before any visitor is affected, the specific plugin based and manual methods for transferring your site, the safe way to switch your domain’s DNS pointing with minimal downtime, and the post-migration checks that confirm your migration genuinely succeeded rather than just appearing to.

What You Will Learn

In this guide, you’ll learn:

• Understand exactly what components of a WordPress site need to migrate successfully and why each one matters.
• Be able to test your new hosting environment fully before ever touching your live domain’s DNS.
• Know how to migrate WordPress using a dedicated migration plugin, the recommended method for most site owners.
• Understand the manual migration process for situations where a plugin based approach is not suitable.
• Be able to execute a safe, low downtime DNS cutover using proper TTL management.
• Have a complete post-migration checklist to confirm nothing was lost in the process.

What Actually Needs to Migrate

A WordPress site consists of three genuinely distinct components, and a successful migration requires all three to transfer correctly and in the proper sequence, since missing or mishandling any single one results in a broken or incomplete migration regardless of how well the other two went.

Your WordPress files include the entire wp-content directory, containing your themes, plugins, and every media file you have ever uploaded, along with the WordPress core files themselves. Your database contains every piece of actual content, your posts, pages, comments, user accounts, and virtually all of your site’s settings, stored as structured data rather than as files. Your domain’s DNS pointing determines which server visitors and search engines actually reach when they type your domain name, and this is the final piece that needs to change only once everything else has been successfully verified on the new host.

Pre-Migration Preparation

Before touching anything, create a complete, verified backup of your current site using a plugin such as UpdraftPlus, and confirm this backup genuinely completed successfully and includes both your files and your database, since a migration should never begin without a fully verified fallback already in hand.

Set up your new hosting account and take note of the specific access details you will need, your new hosting control panel login, your new database credentials if you plan to migrate manually, and any temporary URL your new host provides for testing the site before your domain officially points there.

Lower the TTL, meaning time to live, value on your domain’s current DNS A record to a short duration such as 300 seconds, ideally 24 to 48 hours before you plan to actually cut over to the new host. This single step is the most effective way to minimize downtime during the actual switch, since a low TTL means any DNS change you make later will be recognized by resolvers around the world within minutes rather than potentially taking up to a full day.

Method 1: Migrating With a Plugin

Using a dedicated migration plugin is the recommended approach for the large majority of WordPress site owners, since it automates the technical complexity of packaging your files and database together correctly, considerably reducing the risk of a manual error along the way.

Step 1: Install a Migration Plugin

Install a plugin such as All-in-One WP Migration or Duplicator on your current, live WordPress site. Both are widely used, well maintained, and handle the packaging process reliably for the large majority of standard WordPress sites.

Step 2: Export Your Complete Site

Within the plugin’s interface, initiate a full site export, which packages your entire database and your complete wp-content directory into a single downloadable file. For larger sites with substantial media libraries, this process can take some time to complete, and it is worth allowing it to finish fully rather than interrupting it partway through.

Step 3: Install a Fresh WordPress Installation on Your New Host

On your new hosting account, install a completely fresh copy of WordPress through your host’s one-click installer, exactly as you would for a brand new site. This fresh installation provides the foundation your migration plugin will then import your actual content into.

Step 4: Import Your Site Into the New Installation

Install the same migration plugin on this new, fresh WordPress installation, and use its import function to upload the export file you created in Step 2. The plugin will handle replacing the fresh installation’s default content and database entirely with your actual site’s files and content.

Step 5: Test the Migrated Site Before Changing DNS

Access your migrated site using the temporary URL your new host provides, commonly a format such as your assigned server IP address followed by a specific path, or a temporary subdomain your host assigns specifically for this purpose. Thoroughly check that your homepage, several individual posts, your media library, and any critical functionality such as contact forms or e-commerce checkout flows are all working correctly on this new server before proceeding any further.

Method 2: Migrating Manually

A manual migration provides more direct control and is useful in situations where a plugin based approach encounters compatibility issues, though it requires more technical comfort with file transfer and database management.

Step 1: Export Your Database

Using phpMyAdmin within your current hosting control panel, select your WordPress database and use the Export function to download a complete .sql file containing your entire database.

Step 2: Download Your WordPress Files

Using an FTP client such as FileZilla, connect to your current hosting account and download your entire WordPress installation, particularly the wp-content directory, to your local computer.

Step 3: Create a New Database on Your New Host

In your new hosting account’s control panel, create a new, empty MySQL database along with a database user granted full privileges on that database, exactly as you would when installing WordPress fresh.

Step 4: Import Your Database

Using phpMyAdmin on your new hosting account, select your newly created empty database and use the Import function to upload the .sql file you exported in Step 1.

Step 5: Update the Site URL Within the Database

If your new site will be accessed via a different temporary URL during testing than the domain your database currently references, you will need to update the site URL values stored within the database itself, commonly done using a dedicated search and replace tool such as the Better Search Replace plugin, since a direct find and replace within a raw SQL file can corrupt certain serialized data structures WordPress uses internally.

Step 6: Upload Your Files and Configure wp-config.php

Upload your downloaded WordPress files to your new hosting account via FTP, and edit the wp-config.php file to reflect your new database’s specific name, username, password, and host, replacing the previous values entirely.

Step 7: Test Thoroughly Before Proceeding

Exactly as with the plugin based method, access your migrated site through a temporary URL or a local hosts file edit, and thoroughly verify every critical piece of functionality before moving forward to the DNS cutover stage.

The Safe DNS Cutover Sequence

Once your site is fully tested and confirmed working correctly on the new host, the final step is switching your domain’s DNS so that visitors and search engines actually reach the new server going forward.

Confirm your domain’s TTL was already lowered well in advance, as described in the pre-migration preparation section, since this is what determines how quickly the following change actually takes effect.

Update your domain’s A record, either at your registrar or your DNS provider, to point to your new hosting server’s IP address, replacing the previous value that pointed to your old host entirely.

Monitor propagation using a tool such as whatsmydns.net, confirming the new IP address is being consistently returned across multiple global locations before considering the migration complete.

Keep your old hosting account fully active and unchanged for at least a week following the cutover, rather than canceling it immediately, since this provides a genuine safety net during the period when some visitors or search engine crawlers with a cached DNS record may still briefly reach the old server.

Post-Migration Checks

Once DNS has fully propagated and your new server is consistently serving your domain, work through a thorough checklist to confirm nothing was actually lost in the process.

Check that your SSL certificate is properly active on the new host, since HTTPS needs to be reconfigured on any new server rather than automatically carrying over from the previous one. Verify your site’s permalink structure is still set correctly under Settings, then Permalinks, and resave this setting even if it appears unchanged, since this action regenerates the server’s rewrite rules on the new host.

Confirm your XML sitemap is still generating correctly and resubmit it within Google Search Console under your verified property, since search engines benefit from an explicit confirmation that your content is still available and properly structured following any hosting change.

Test every contact form, any e-commerce checkout flow, and any other interactive functionality thoroughly, since these are the elements most likely to reveal a configuration issue that a simple visual check of your homepage would not surface.

Review your Google Analytics and Google Search Console data over the following weeks specifically for any unexpected drop in traffic or a sudden rise in crawl errors, since either would signal a migration related issue worth investigating promptly rather than assuming it will resolve on its own.

Frequently Asked Questions

Will migrating to a new host hurt my search engine rankings?
A well executed migration, where your domain itself does not change and all your URLs continue resolving correctly, generally has no lasting negative impact on rankings. A poorly executed migration involving broken links, extended downtime, or missing content can cause a genuine, measurable ranking impact, which is precisely why thorough testing before cutover and careful post-migration verification both matter considerably.

How long does a typical WordPress migration take?
The actual file and database transfer for a typical site usually completes within an hour or two using a migration plugin, though larger sites with substantial media libraries can take longer. The DNS cutover itself, if TTL was properly lowered in advance, typically propagates within 5 to 15 minutes, though allowing up to 24 to 48 hours before fully retiring the old host is a reasonable safety margin.

Do I need to hire a developer to migrate my WordPress site?
Most WordPress sites can be migrated successfully by a site owner following the plugin based method described in this guide, which is specifically designed to minimize the technical complexity involved. A developer becomes more valuable for particularly large, complex sites, or sites with extensive custom code that may require additional testing and verification during the process.

What happens to my email if it is hosted through the same account as my website?
If your email is managed through the same hosting account as your website, migrating to a new host will require setting up your email service again on the new host, and it is worth confirming your specific email setup, whether through your hosting provider directly or a separate service such as Google Workspace, before beginning the migration, so email delivery is not disrupted during the transition.

Should I migrate during a specific time of day?
Scheduling the actual DNS cutover during your site’s lowest traffic period, commonly late at night in your primary audience’s time zone, minimizes the number of visitors who might encounter any brief inconsistency during the propagation window, even though a properly prepared migration with a low TTL should complete this transition in a matter of minutes.

What should I do if something looks broken immediately after migrating?
If you still have access to your old hosting account and DNS has not yet fully propagated, you can revert your DNS A record back to the old host’s IP address, which will similarly propagate quickly if your TTL was kept low, buying you time to diagnose and fix the issue on the new host before attempting the cutover again.

Related Articles

• How to Create a WordPress Child Theme
• What Is Managed WordPress Hosting and Is It Worth the Price?

Final Thoughts

Migrating WordPress to a new host is a genuinely manageable process once broken into its actual components, files, database, and DNS, each handled correctly and in the proper sequence, with thorough testing happening before your live domain ever points anywhere new. The specific steps that prevent every common migration problem, verified backups beforehand, testing on a temporary URL before cutover, a properly lowered TTL, and keeping the old host active as a safety net afterward, are not complicated on their own. They simply need to be followed in order rather than skipped under the pressure to get the migration finished quickly.

Take the time to test fully before your domain’s DNS changes, and resist the temptation to cancel your old hosting account the moment the new one appears to be working. That patience during the final days of a migration is what actually separates a migration that goes smoothly from one that causes a problem nobody notices until it is considerably harder to fix.