Moving a WordPress site to a new host sounds scary. I get it. Your whole business lives on that site, and the fear is that you flip a switch and everything breaks. Lost posts, broken images, dead contact forms, email that stops arriving. That fear keeps a lot of people stuck on slow, overpriced hosting for years.
Here is the good news. If you follow a real process, a WordPress migration is pretty boring. I have been building websites and online stores since 2010, and I run several WordPress sites for my own businesses. Every move that went smoothly had the same thing in common: a full backup, a test on the new server before DNS changed, and the old host left running until everything checked out.
In this guide I am going to walk you through the exact steps to migrate a WordPress site to a new host in 2026. We will cover the pre-migration inventory, 3 different migration methods, testing on a temporary URL or your hosts file, lowering your DNS TTL, switching DNS, SSL, and a full post-migration checklist. If you have not picked your new host yet, start with my web hosting for beginners guide so you know what you actually need before you move.
By the end you will have a printable checklist, a rollback plan, and a clear idea of which method fits your site. Small blog or busy WooCommerce store, the process is the same. The stakes are just higher on the store. So let’s get into it.
Quick note: some links on Web Hosting Paradise may become affiliate links down the road. You can read our affiliate disclosure for the details. Everything here is research-based, and I never claim hands-on testing we did not do.
What Actually Moves When You Migrate WordPress
Before you touch anything, it helps to understand what a WordPress site really is. It is 2 things working together. First, the files. Second, the database. Miss either piece and the site will not work on the new server.
The Files
The files include WordPress core, your theme, your plugins, and the wp-content/uploads folder with every image and PDF you have ever added. There is also the wp-config.php file, which tells WordPress how to connect to the database, plus an .htaccess file on Apache servers that handles permalinks and redirects.
Core files are the easy part. You can always download a fresh copy of WordPress. The uploads folder is usually the biggest piece, and it is the piece that takes the longest to copy.
The Database
The database holds your posts, pages, comments, users, settings, menus, widget settings, and most plugin data. On a WooCommerce site it also holds orders and customers. This is the part you cannot recreate if it goes missing, which is why it gets the most attention in this guide.
The database also stores your site address in a lot of places, often inside serialized data. That detail matters a lot if your domain or URL changes during the move. The official Migrating WordPress handbook page warns that a plain find and replace can break serialized values, because they store the length of each string.
The Stuff Outside WordPress
This is where people get burned. Your domain registration, your DNS records, and your email are usually not part of WordPress at all. They might live at your registrar, at your old host, or at a third party like Google Workspace or Microsoft 365. A migration plan has to account for all of them, or you will move the website and accidentally break your email.
Step 1: Do a Pre-Migration Inventory
I always start with a simple inventory. It takes 30 minutes and it saves hours of panic later. Open a spreadsheet or a notes doc and write down the following.
- Your WordPress version, PHP version, and database version (find these under Tools, then Site Health, then Info).
- The total size of your site files and database, so you know whether a plugin or a manual move makes more sense.
- Every active plugin and your active theme, including any premium licenses that are locked to a domain.
- Where your domain is registered and who controls the nameservers.
- Every DNS record you currently have: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, site verification), and any SRV records.
- Where your email is hosted, and whether it is tied to the old hosting account.
- Any cron jobs set in the old host’s control panel.
- Any custom server rules: redirects in .htaccess, PHP settings in .user.ini or php.ini, and IP allowlists.
- Third party services that whitelist your server IP, like payment gateways, SMTP services, or APIs.
If you are not sure who your registrar is, run your domain through ICANN Lookup. It shows the registrar and the current nameservers. That tells you exactly where you will need to log in on switch day.
The DNS records are the part people skip. Screenshot or export the full zone from wherever DNS is managed today. If the old host is also your DNS provider and you close that account, those records vanish. That is how email goes down after a move.
Check the New Host Matches Your Requirements
Make sure the new server runs a PHP version your theme and plugins support. Also confirm the storage, PHP memory limit, and upload limit are big enough for your site. If you are still comparing options, my roundup of the best WordPress hosting covers what to look for. The cheap WordPress hosting guide shows how to compare real renewal prices.
Step 2: Take a Full Backup You Can Actually Restore
Never start a migration without a fresh, complete, off-server backup. Not the backup your host says it takes. Your own copy, downloaded to your computer or sent to cloud storage you control.
A full backup means both the files and the database. I go through the whole process, including how often to back up and where to store copies, in my guide on how to back up a WordPress site. The official WordPress handbook also has a solid page on WordPress backups if you want the technical version.
What a Good Pre-Migration Backup Looks Like
- A database export (.sql or .sql.gz file) taken right before you start.
- A copy of the full wp-content folder, at minimum, and ideally the whole site root.
- A copy of wp-config.php and .htaccess, since they hold settings you may need to recreate.
- Stored in at least 2 places, and neither of them is the old server.
Then do the step almost everyone skips. Open the backup and make sure it is not empty. Check the .sql file has your posts table in it. Check the uploads folder has your images. A backup you never verified is just a hope.
If you want a plugin to handle this, my list of the best WordPress backup plugins compares the free and paid options.
Freeze Content Changes
Pick a migration window and stop publishing during it. On a blog, that just means no new posts or comment moderation for a day. On a WooCommerce store it is a bigger deal, because orders keep coming in on the old server after you copy the database. Plan the move for your slowest sales hours, and be ready to copy any orders placed during the gap.
Step 3: Choose Your Migration Method
There are 3 realistic ways to move a WordPress site. Which method you pick depends on your site size, your comfort with technical tools, and whether your new host will do it for you.
| Method | Best for | Skill level | Typical cost | Main risk |
|---|---|---|---|---|
| Host’s free migration service | Most small and mid-size sites | Beginner | Usually included with a plan | Waiting in a queue, less control over timing |
| Migration plugin | Sites up to a few GB, DIY owners | Beginner to intermediate | Free tiers available, paid add-ons for large sites | Upload size limits and server timeouts |
| Manual (SFTP plus database export/import) | Large sites, developers, unusual setups | Intermediate to advanced | Free, costs your time | Human error in search-replace or config |
Method 1: Use Your New Host’s Free Migration Service
This is the easiest path, and it is the route I point most beginners toward. Lots of hosts will move your site for free when you sign up, either with their own plugin or with a support team doing it by hand.
For example, SiteGround offers a free SiteGround Migrator plugin that uses a migration token from your new account. Hostinger says on its website migration page that migrations are free once you buy a hosting plan, with a separate request for each site. Terms change, so always confirm the current policy on the host’s own page before you buy.
A few things to ask before you rely on a free migration:
- Do they migrate the whole site or only WordPress files and the database?
- Do they move email accounts? Most do not.
- Will they give you a temporary URL to test before you switch DNS?
- How long is the queue right now?
- Do they handle a domain change, or only same-domain moves?
Even when the host does the work, you still own the backup, the testing, and the DNS switch. Do not hand over the keys and walk away.
Method 2: Use a WordPress Migration Plugin
Migration plugins package your site into an archive on the old host and unpack it on the new server. Most of them also rewrite URLs and handle serialized data for you, which is the hardest part of a manual move.
The big names are All-in-One WP Migration, Duplicator, Migrate Guru, UpdraftPlus, WPvivid, BlogVault and WP Migrate. Each has different free tier limits, so I broke them all down in my guide to the best WordPress migration plugin for your situation.
The general plugin workflow looks like this:
- Install a fresh copy of WordPress on the new host (some plugins, like Duplicator, can install onto an empty server instead).
- Install the same migration plugin on both the old site and the new site.
- Export or package the old site.
- Import the package on the new site, or connect the 2 sites and push the data across.
- Let the plugin run search-replace if the URL is changing.
- Log in again on the new site, since your old users and passwords come across with the database.
The most common problem is size. Shared hosts cap upload sizes and script run times, so a 5 GB site can time out halfway. Plugins that run the transfer on their own servers, or that let you upload the archive by SFTP, get around this.
Method 3: Migrate Manually With SFTP and the Database
The manual method gives you full control. It is also the method that still works when every plugin fails. It is not hard, but it does need care. Here is the process I would follow.
1. Download the files. Connect to the old server with an SFTP client like FileZilla, or use SSH, and download the full WordPress folder. If you have SSH, compress it first so you are moving 1 file instead of thousands.
2. Export the database. In phpMyAdmin, select your database, click Export, and save the .sql file. If you have SSH and WP-CLI, the wp db export command does it in 1 line:
wp db export backup-before-migration.sql3. Create a new database on the new host. Make a new database and a database user with full privileges on it. Write down the database name, user, password, and host. Some hosts use localhost, others use a separate hostname.
4. Import the database. Use phpMyAdmin’s Import tab on the new server, or the wp db import command:
wp db import backup-before-migration.sqlLarge databases often fail in phpMyAdmin because of upload limits. If that happens, ask the new host’s support to import it for you, or use WP-CLI over SSH.
5. Upload the files and update wp-config.php. Upload everything to the new server’s web root. Then edit wp-config.php so DB_NAME, DB_USER, DB_PASSWORD and DB_HOST match the new database. The wp-config.php documentation explains each setting if you get stuck.
6. Run search-replace if the URL changed. If you are keeping the same domain, you can usually skip this. If you are changing domains, or moving from http to https, you need to update every old URL in the database safely.
Search and Replace URLs the Safe Way
WP-CLI is my go-to here. The wp search-replace command handles serialized data properly and has a dry run mode so you can see what will change before it saves anything. Run the dry run first:
wp search-replace 'https://oldsite.com' 'https://newsite.com' --skip-columns=guid --dry-runIf the report looks right, run it for real by removing the dry run flag:
wp search-replace 'https://oldsite.com' 'https://newsite.com' --skip-columns=guidNotice the skip columns part. The WordPress handbook is very clear that you should never change the GUID column, because feed readers use it to track which posts they have already seen. Change it and old posts can show up as new to every RSS subscriber.
No SSH access? A plugin like Better Search Replace does the same job from the dashboard. Just never run a raw find and replace on the .sql file in a text editor. That is how serialized widget and theme settings get corrupted.
Step 4: Test the New Site Before You Touch DNS
This is the step that separates a calm migration from a stressful migration. Your domain still points at the old host, so visitors see nothing different. Meanwhile you can check the new copy in private. There are 2 good ways to do that.
Option A: Use a Temporary URL
Many hosts give you a temporary domain or staging URL for each new site. It is quick, but there is a catch. WordPress expects to load on its real domain, so links and images may point back to the live site. Some hosts handle this for you. If not, the hosts file method below is cleaner.
Option B: Edit Your Hosts File
Your computer’s hosts file lets you tell your own machine to load your real domain from the new server’s IP address. Nobody else is affected. You see the new site on the real URL, with no URL changes needed.
On Windows the file lives at C:\Windows\System32\drivers\etc\hosts. On Mac and Linux it is /etc/hosts. Open it with admin rights and add a line with the new server’s IP and your domain:
203.0.113.10 example.com
203.0.113.10 www.example.comSwap in your new host’s real IP address. Save the file, clear your browser cache, and visit your domain. You are now looking at the new server. Remove those lines when you are done testing, or you will keep seeing the new server after the switch and miss any DNS problems.
What to Test
- The homepage, a few posts, a few pages, and your most visited URLs.
- Images and media from different years in the uploads folder.
- Logging into wp-admin and saving a draft.
- Every contact form, including whether the email actually arrives.
- Search, menus, widgets, and any sliders or page builder layouts.
- Cart, checkout and a test order on WooCommerce sites, in test mode.
- Any membership, login, or gated content.
- Page speed compared to the old host, as a rough sanity check.
Fix everything here, before DNS changes. Once real visitors land on the new server, every problem becomes public.
Step 5: Lower Your DNS TTL a Day or 2 Before the Switch
TTL stands for time to live. It is a number on every DNS record that tells resolvers around the world how long to cache that record before asking again. If your A record has a TTL of 86400 seconds, some visitors may keep hitting the old server for up to a full day after you change it.
Cloudflare’s documentation on TTL sums up the trade-off: a longer TTL means updates to your records take longer to go into effect. So the trick is simple. Lower the TTL ahead of time.
- At least 24 to 48 hours before the switch, lower the TTL on your A, AAAA and www CNAME records to 300 seconds (5 minutes) or the lowest your DNS provider allows.
- Wait for the old TTL to expire. If it was 86400, wait a full day.
- Make the switch. Now caches refresh within minutes instead of hours.
- After everything is stable for a few days, raise the TTL back up to something like 3600 or higher.
This single habit removes most of the “half my visitors see the old site” confusion. It costs nothing and takes 2 minutes.
Step 6: Switch DNS or Nameservers
There are 2 ways to point your domain at the new host. Which option you use depends on where you want DNS to be managed going forward.
Option 1: Change Only the A Record
If your DNS is managed somewhere you are keeping, like your registrar or Cloudflare, you just update the A record (and AAAA if you use IPv6) to the new server IP. Update the www record too. Everything else, including your MX and TXT records, stays exactly as it is. This is the lowest risk option and my default.
Option 2: Change the Nameservers
If you want the new host to manage DNS, you change the nameservers at your registrar to the ones the new host gives you. This moves the entire DNS zone. Before you do it, recreate every single record from your inventory inside the new host’s DNS panel. Missing MX or TXT records is the number 1 way migrations break email.
Nameserver changes also tend to take longer to settle than an A record change, because the delegation records at the registry have their own caching. Expect anything from a few minutes to a couple of days.
Leave Email Alone
Your MX records tell the world where to deliver email for your domain. Cloudflare’s explainer on what a DNS MX record is is a good primer. Unless you are deliberately moving email too, those records should not change during a website migration. Same with SPF, DKIM and DMARC TXT records.
If your email was hosted on the old web host, you have a bigger decision. You can recreate mailboxes on the new host and move the messages over IMAP, or use the move as the push to finally switch to a dedicated email provider. Either way, plan it as its own project.
Step 7: Set Up SSL on the New Host
Your SSL certificate usually does not come with you. The new host needs to issue a fresh certificate. Most hosts use Let’s Encrypt, which proves you control the domain before issuing. The Let’s Encrypt explainer on how it works explains the validation process.
That validation is the catch. Many automatic SSL tools can only issue the certificate once your domain points at the new server. So you might see a brief certificate warning right after the switch. Some hosts support DNS validation, which lets you issue the certificate before the switch. Ask your new host which they use.
After SSL is active, check for mixed content. That is when a page loads over https but pulls an image or script over http. The browser console will flag it. A search-replace from http to https on your own domain usually clears it up.
Step 8: Post-Migration Checklist
Once DNS points at the new host and SSL is live, run through this checklist. I like to go through it twice, once right after the switch and again the next day.
| Check | What to do | Done? |
|---|---|---|
| Permalinks | Go to Settings, then Permalinks, and click Save without changes to rebuild rewrite rules | ☐ |
| Homepage and top pages | Load them logged out, on desktop and mobile | ☐ |
| Forms | Submit every form and confirm the email arrives | ☐ |
| Transactional email | Test password reset and WooCommerce order emails, set up SMTP if needed | ☐ |
| MX and email records | Confirm MX, SPF, DKIM and DMARC records are unchanged and mail still flows | ☐ |
| SSL | Padlock shows on all pages, no mixed content warnings | ☐ |
| Caching | Clear plugin cache, server cache and CDN cache, then re-enable caching | ☐ |
| Cron | Confirm scheduled posts and plugin tasks run, recreate server cron jobs | ☐ |
| Backups | Set up and test a fresh backup schedule on the new host | ☐ |
| Search Console | Check for crawl errors and resubmit your sitemap | ☐ |
| Redirects | Test old redirects from .htaccess or your redirect plugin still work | ☐ |
| Third party IP allowlists | Update payment gateways, SMTP or APIs that whitelist the server IP | ☐ |
| Performance | Compare load times and Core Web Vitals to the old host | ☐ |
Permalinks
On a new server the rewrite rules sometimes do not carry over, and every page except the homepage returns a 404. The fix is usually just re-saving your permalink settings. The WordPress Permalinks settings documentation covers what each option does.
Forms and Transactional Email
Contact forms that sent fine on the old host may stop delivering, because the new server’s mail setup is different. I always route WordPress email through a proper SMTP service so it does not depend on the host at all. Test a form, a password reset, and on a store, a test order email.
Caching
Old cache files can serve stale pages or even point at the old server. Clear every layer: your caching plugin, the host’s server cache, and any CDN. If the new host has its own built-in caching, you might not need your old caching plugin at all. My guide to speeding up a WordPress site explains how the layers fit together.
Cron Jobs
WordPress runs scheduled tasks through WP-Cron, which fires when people visit the site. Many hosts recommend turning that off and using a real server cron job instead. The WordPress Cron documentation explains how it works. If you used a server cron on the old host, recreate it on the new server, then confirm scheduled posts and backups actually run.
Step 9: Keep the Old Host Active for at Least 1 to 2 Weeks
Do not cancel the old hosting account the day you switch. This is the best insurance you have, and it usually costs less than a month of hosting.
Keep it running until DNS has fully settled, you have gone through the checklist twice, a few days of real traffic have passed without problems, and you have a verified backup from the new host. On a store, also wait until you are sure no orders landed on the old server during the switch.
When you do cancel, download a final full backup from the old account first. Some hosts delete data quickly after cancellation, so treat that final download as non-negotiable.
Step 10: Have a Rollback Plan
Every migration plan needs a way back. Here is the simple version.
- Keep the old server untouched and running during the whole window.
- Write down the old IP address and old nameservers before you change anything.
- Keep the TTL low until you are confident, so a rollback also propagates quickly.
- Decide in advance what counts as a rollback trigger, such as checkout failures or a site that will not load.
- If you roll back, point DNS back at the old IP, then copy any new content or orders from the new server back to the old server.
Most of the time you will never use the rollback plan. But knowing it is there makes the switch feel a lot less stressful, and that calm helps you make better decisions in the moment.
Special Cases to Plan For
Changing Domains at the Same Time
If you are moving hosts and changing your domain in the same project, do them as 2 steps if you can. Move hosts on the same domain first, confirm everything works, then do the domain change. When you change domains, set up 301 redirects from every old URL to its new address and use the change of address tool in Google Search Console.
WooCommerce Stores
Stores have live data that changes every minute. Put the store in maintenance mode during the final database copy, or move during your slowest hours and manually reconcile any orders placed in the gap. Double check payment gateway webhooks still point at the right URL. If you are choosing a host for a store, my guide to the best WooCommerce hosting covers what matters for checkout performance.
Moving From Shared to Managed Hosting
Managed WordPress hosts often block certain plugins, handle caching at the server level, and run their own backups. Read their disallowed plugin list before you migrate. My comparison of managed WordPress vs shared hosting explains those trade-offs in more detail.
Moving to a Cloud Platform
Cloud platforms give you more control over the server, which also means more settings to check after the move. If you are considering that route, read my Cloudways review for an example of how a managed cloud setup handles migrations, backups and pricing.
Common Migration Problems and Quick Fixes
- Error establishing a database connection: the database details in wp-config.php do not match the new database. Recheck the name, user, password and host.
- Every page except the homepage is a 404: re-save permalinks, and check that .htaccess was uploaded.
- Images missing: the uploads folder did not fully copy, or file permissions are wrong. Re-upload and check permissions.
- Redirect loop to the old domain: the siteurl and home values in the wp_options table still hold the old URL.
- White screen of death: often a PHP version mismatch or a plugin that needs a missing PHP extension. Turn on debugging in wp-config.php to see the error.
- Forms not sending: set up SMTP and test again.
- SSL warnings: the certificate has not issued yet, or there is mixed content.
Frequently Asked Questions
How long does it take to migrate a WordPress site to a new host?
The hands-on work for a small site is usually a couple of hours. Bigger sites with many GB of uploads take longer to copy. DNS changes can take minutes or up to a day or 2 to reach everyone, which is why lowering your TTL first helps so much.
Will migrating my WordPress site hurt my SEO?
Moving hosts on the same domain with the same URLs should not hurt rankings if the site stays up and loads properly. Problems come from downtime, broken pages, or changed URLs without redirects. Test before the switch and you avoid all 3.
Do I need to reinstall WordPress on the new host?
It depends on the method. Most migration plugins need a fresh WordPress install on the new server first. Duplicator can install onto an empty server. With the manual method you upload your existing files, so no fresh install is needed.
Will my email stop working when I switch hosts?
Not if you leave your MX and email TXT records alone. Email breaks when people change nameservers without copying their DNS records, or when email was hosted on the old web host and the account gets cancelled.
Is it better to use a plugin or my host’s free migration service?
If your new host offers free migration and gives you a test URL, that is usually the easiest route for beginners. Plugins are great when you want control over timing. My comparison of WordPress migration plugins covers which ones handle large sites best.
When can I cancel my old hosting?
Wait at least 1 to 2 weeks after DNS has switched and the site has run without issues. Download a final backup from the old account before you cancel.
Wrapping Up
A WordPress migration really comes down to 4 habits. Inventory everything, back up and verify, test on the new server before DNS changes, and keep the old host as a safety net. Do those and the actual switch is just a few minutes of updating records.
If you are still deciding where to move, head to the Start Here page and write your requirements sheet first. Then come back to this guide when you are ready to make the move. You have got this.
Related Articles
- Best WordPress Migration Plugins Compared
- How to Back Up a WordPress Site the Right Way
- Best WordPress Hosting Picks
- Bluehost Alternatives Worth Moving To
- Web Hosting for Beginners
Trevor Fenner publishes Hosting Paradise and Ecommerce Paradise. His guides cover web hosting, website migration, backups, and software for online businesses.