Moving your WordPress site to a new host is one of those tasks that sounds simple until you actually do it. Export, import, done, right? In practice, there are dozens of things that can go wrong: broken links, missing images, database errors, email that stops working, and SEO rankings that quietly disappear.
We have seen it all across 60 million+ site migrations with All-in-One WP Migration. This guide is everything we have learned, condensed into one resource.
It covers three migration methods (plugin, hosting provider tools, and manual), but more importantly, it covers the preparation and post-migration steps that most guides skip entirely. Those steps are where migrations actually succeed or fail.
Which Migration Method Should You Use?
Before diving in, here is a quick comparison to help you choose the right approach:
| Plugin Migration | Hosting Provider Tool | Manual Migration | |
|---|---|---|---|
| Difficulty | Easy | Easy | Advanced |
| Best for | Most sites | New hosting customers | Large or complex sites |
| Time | 15-30 minutes | 1-48 hours | 1-3 hours |
| Control | High | Low | Full |
| Cost | Free (or from $69) | Usually free | Free |
| Handles large sites | Yes (with extension) | Varies | Yes |
| Requires technical knowledge | No | No | Yes (FTP, SQL, SSH) |
For most WordPress sites, using a migration plugin is the fastest and safest option. Manual migration is better for sites with unusual server configurations or very large databases where you need granular control.
Migration Timeline: The Big Picture
Here is the complete migration process at a glance. The actual migration (exporting and importing your site) is the easy part. The preparation and verification around it is what makes the difference between a smooth migration and a broken site.
48 hours before migration:
- Lower DNS TTL to 300 seconds
- Audit email/MX records
- Check PHP version compatibility
Day of migration:
- Create a fresh backup
- Disable caching and security plugins
- Export/migrate your site to the new host
- Test the site on the new host (before switching DNS)
- Update DNS records
- Set up SSL certificate
After going live:
- Work through the post-migration checklist
- Monitor for errors over the next 7-14 days
- Keep the old host active as a safety net
7-14 days after migration:
- Cancel old hosting account (if everything is stable)
- Raise DNS TTL back to normal (86400)
Now let’s walk through each step in detail.
Before You Start: Pre-Migration Preparation
Skipping preparation is the number one reason migrations fail. Before you touch anything, work through this checklist.
1. Back Up Your Current Site
This is non-negotiable. Create a full backup of your files and database before making any changes. If something goes wrong during migration, you need a way to restore your original site.
You can use All-in-One WP Migration to create a complete backup with one click, or use your hosting provider’s backup tools. Store the backup somewhere other than your current hosting account, such as your local computer or cloud storage.
Not sure whether to use cloud or local storage? Read our comparison of cloud storage vs. local backup for WordPress.
2. Lower Your DNS TTL (Critical)
This is the step that almost every migration guide skips, and it is one of the most important for avoiding downtime.
TTL (Time to Live) tells DNS servers how long to cache your domain’s IP address. When you change your DNS to point to the new host, every DNS server in the world needs to pick up the new address. If your TTL is set to 86400 (24 hours), that process can take up to a full day. During that time, some visitors see the old server and some see the new one.
What to do: Log into your domain registrar or DNS provider (Cloudflare, Namecheap, GoDaddy, etc.) and lower the TTL on your A record and CNAME records to 300 seconds (5 minutes). Do this 24-48 hours before you plan to migrate, because the old TTL value needs to expire first.
Here is what this looks like in practice:
- 48 hours before migration: Lower TTL from 86400 to 300
- Migration day: Move site, test on new host, then update DNS
- DNS propagation: Takes ~5 minutes instead of ~24 hours because the TTL is low
- After everything is stable (24-48 hours later): Raise TTL back to 86400
This one change is the difference between a seamless migration and hours of “some people can see the site and some can’t” confusion.
3. Check PHP Version Compatibility
Your new host might run a different PHP version than your old one. If your site uses PHP 7.4 and the new host defaults to PHP 8.2, some plugins or themes may break.
What to do:
- Check which PHP version your current site uses (Settings > Site Health > Info > Server in your WordPress dashboard)
- Check which PHP versions your new host supports
- If the versions differ, install the PHP Compatibility Checker plugin on your current site and run a scan to identify potential issues
- Either match the PHP version on the new host to your current one, or fix compatibility issues before migrating
4. Audit Your Email Setup
If your current host also handles your email (yourname@yourdomain.com), migrating to a new host can silently break email delivery. This catches a lot of people off guard because the website works perfectly on the new host, but emails stop arriving.
This happens because your MX records (which control email routing) may be tied to your old hosting server. When you update your DNS A record to point to the new host, the MX records may also need to change.
What to do:
- Check your current MX records using a tool like MXToolbox. Enter your domain and look at where your MX records point.
- If your MX records point to your hosting provider (e.g.,
mail.youroldhost.com), you have two options:- Set up matching email accounts on the new host before switching DNS, and update MX records to point to the new host
- Move to a third-party email service like Google Workspace, Microsoft 365, or Zoho Mail. This is the recommended long-term solution because your email becomes independent of hosting and will never break during future migrations.
- If your MX records point to a third-party email service (e.g.,
aspmx.l.google.comfor Google Workspace), you are fine. Your MX records are separate from your hosting, and email will continue working without any changes.
Important: If you are managing DNS at your domain registrar (not through your host), make sure you only update the A record and CNAME for the website. Leave the MX records untouched unless you are intentionally changing email providers.
5. Document Your Current Setup
Take note of the following before you start:
- Active plugins and their versions
- Current theme and version
- Custom code in wp-config.php, .htaccess, or php.ini
- Cron jobs (both WordPress cron and server cron)
- Any server-level redirects
- SSL certificate type and provider
This information will help you verify everything is working correctly after migration.
6. Disable Caching and Security Plugins
Caching plugins (WP Super Cache, W3 Total Cache, WP Rocket) and security plugins (Wordfence, Sucuri) can interfere with the migration process. Deactivate them before exporting your site, and reactivate them after migration is complete.
Method 1: Using a Migration Plugin (Recommended)
A migration plugin handles the heavy lifting for you: exporting files, database, themes, plugins, and media into a single package, then importing it on the new host. This is the easiest and safest method for most sites.
We will use All-in-One WP Migration for this walkthrough. It is the most widely used WordPress migration plugin with over 5 million active installations.
Step 1: Install All-in-One WP Migration on Your Current Site
Go to Plugins > Add New in your WordPress dashboard, search for “All-in-One WP Migration,” and click Install Now, then Activate.
Step 2: Export Your Site
Go to All-in-One WP Migration > Export in the dashboard. Click Export To and select File. The plugin will package your entire site into a single downloadable .wpress file, including:
- Your entire WordPress database (posts, pages, comments, users, settings)
- All themes and plugins (including their settings and configuration)
- The entire media library (images, videos, documents)
- Custom code files (mu-plugins, custom functions)
The export also automatically handles serialized data in the database, so URL references are updated safely without corruption. This is a critical detail that manual migration often gets wrong.
Download the .wpress file to your computer when the export completes.
For larger sites: The free plugin has no import limit of its own, but your hosting provider may enforce upload size restrictions through PHP settings (upload_max_filesize, post_max_size). The Unlimited Extension bypasses these hosting limits entirely, so you can import sites of any size regardless of your server configuration.
Step 3: Set Up WordPress on the New Host
On your new hosting account:
- Install a fresh copy of WordPress using your host’s one-click installer or manual installation
- Log into the new WordPress dashboard
- Go to Plugins > Add New, search for “All-in-One WP Migration,” and install and activate it
The fresh WordPress installation is temporary. It will be completely overwritten by the import in the next step.
Step 4: Import Your Site
Go to All-in-One WP Migration > Import on the new WordPress installation. Upload the .wpress file you exported in Step 2. The plugin will:
- Unpack all files (themes, plugins, media)
- Import the entire database
- Update any URL references if the domain or path has changed
- Preserve all settings and configurations
Important: After the import finishes, you will be logged out (because the database now contains the user accounts from your old site). Log back in with the username and password from your old site, not the one you created during the fresh WordPress installation.
Then go to Settings > Permalinks and click Save Changes to flush rewrite rules (you don’t need to change anything, just click save).
Step 5: Verify Before Going Live
Before changing your DNS, verify the site works on the new host. See the “Testing Before Going Live” section below.
Method 2: Using Your Hosting Provider’s Migration Tool
Most hosting providers offer free migration tools or services. These are typically handled through their control panel and may include:
- cPanel Migration Wizard (available on cPanel-based hosts)
- Host-specific tools (SiteGround Migrator, Bluehost Migration, etc.)
- Managed migration services (many hosts will migrate your site for free if you ask)
How It Works
- Sign up for your new hosting account
- Provide your old hosting credentials (FTP details, cPanel access, or WordPress admin login)
- The host’s migration tool copies your files and database to the new server
- You verify the site and update DNS
Pros and Cons
Pros: Hands-off, often free, handled by the host’s team
Cons: You have less control over the process, it may take 24-48 hours for managed migrations, and some hosts only offer this for new customers
If you choose this method, still follow the pre-migration preparation steps above and the post-migration checklist below. The hosting provider handles the file transfer, but DNS, email, and verification are still your responsibility.
Method 3: Manual Migration
Manual migration gives you full control but requires more technical knowledge. Use this method if the plugin method is not an option (very large sites, non-standard server configurations, or restricted hosting environments).
Step 1: Export Your Database
Log into phpMyAdmin on your current host (usually accessible through cPanel or your hosting dashboard). Select your WordPress database, click Export, choose Quick export method with SQL format, and download the file.
For large databases, use WP-CLI instead:
wp db export backup.sql
Step 2: Download Your Files
Connect to your current host via FTP or SFTP (using FileZilla, Cyberduck, or a similar client). Download your entire WordPress directory, including wp-content (themes, plugins, uploads), wp-config.php, and .htaccess.
For large sites, use SSH with rsync for faster transfers:
rsync -avz user@oldhost:/path/to/wordpress/ /local/backup/
Step 3: Upload Files to the New Host
Upload all WordPress files to the new host using FTP/SFTP or rsync. Place them in the correct document root directory (usually public_html or www).
Step 4: Create a Database on the New Host
In your new host’s control panel:
- Create a new MySQL database
- Create a new database user
- Assign the user to the database with full privileges
- Note the database name, username, and password
Step 5: Import the Database
Import your SQL file into the new database using phpMyAdmin (upload the .sql file via the Import tab) or WP-CLI:
wp db import backup.sql
Step 6: Update wp-config.php
Edit wp-config.php on the new host and update the database connection details:
define('DB_NAME', 'new_database_name');
define('DB_USER', 'new_database_user');
define('DB_PASSWORD', 'new_database_password');
define('DB_HOST', 'localhost');
Your new host may use a different DB_HOST value. Check their documentation.
Step 7: Update URLs in the Database
If your site URL changes (different domain or from HTTP to HTTPS), you need to update URLs in the database. Do not use a simple find-and-replace on the SQL file. WordPress stores some data in serialized format, and a naive search-and-replace will corrupt it.
Use WP-CLI’s search-replace command, which handles serialized data safely:
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables
If you don’t have WP-CLI access, use the Better Search Replace plugin instead.
Changing your domain? Read our detailed guide on changing your WordPress domain name.
Step 8: Fix File Permissions
Different hosts use different permission configurations. If you see “forbidden” errors or a white screen after migration, file permissions are the likely cause.
Standard WordPress permissions:
- Directories: 755
- Files: 644
- wp-config.php: 600
You can fix permissions via SSH:
find /path/to/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/wordpress/ -type f -exec chmod 644 {} \;
chmod 600 /path/to/wordpress/wp-config.php
Testing Before Going Live
Never switch your DNS before testing the site on the new host. There are two ways to preview your site on the new server before making it public.
Option 1: Edit Your Hosts File
Your computer’s hosts file lets you override DNS locally, so your browser loads the site from the new server while everyone else still sees the old one.
On Mac/Linux, edit /etc/hosts:
123.456.789.0 yourdomain.com www.yourdomain.com
On Windows, edit C:\Windows\System32\drivers\etc\hosts with the same format.
Replace 123.456.789.0 with your new server’s IP address. Save the file, clear your browser cache, and visit your site. You will see the version on the new host.
After testing, remove the line from your hosts file.
Option 2: Use a Temporary URL
Most hosting providers give you a temporary URL to access your site before DNS is configured (something like youraccount.server123.hostingprovider.com). Check your hosting dashboard for this URL.
Note that some things may not work perfectly on a temporary URL (images with hardcoded domain names, SSL certificates, etc.), but it is good enough to verify the basic structure of your site.
What to Test
Before switching DNS, go through this verification checklist carefully. It is much easier to fix issues now, before the site is live, than after.
Core functionality:
- Homepage loads correctly with the right content and styling
- Several interior pages and blog posts load correctly
- All images and media display properly (no broken image icons)
- Navigation menus work and link to the right pages
- Sidebar widgets display correctly
- Footer content and links are intact
Interactive features:
- Contact forms submit successfully and emails are delivered
- Search functionality returns results
- Comment forms work (if enabled)
- User registration and login work (visit /wp-admin)
- Password reset emails are delivered
Technical checks:
- All plugins are active and functioning (check the Plugins page for any deactivated plugins)
- Theme looks correct with no broken CSS, missing fonts, or layout issues
- No PHP errors visible on the front end (if you see warnings, enable WP_DEBUG to diagnose them). Learn more about debugging WordPress the right way.
- Check the browser’s developer console (F12) for JavaScript errors or failed resource loads
- Verify the site loads over HTTPS if you have set up SSL
For WooCommerce sites:
If you run an online store, you need to test the full purchase flow. See our complete WooCommerce migration guide for a detailed checklist covering payment gateways, order processing, and subscription continuity.
Keep Your Old Host Active
Do not cancel your old hosting account immediately after migration. Keep it active for at least 7-14 days after going live on the new host. Here is why:
- Rollback safety net: If you discover a problem on the new host days after migration, you can quickly revert DNS back to the old server
- DNS propagation overlap: Even with a low TTL, some ISPs and corporate networks cache DNS longer than the TTL specifies. During this overlap period, some visitors may still reach the old server
- Email delivery: If any email was in transit to the old server during the DNS switch, it will be delivered there. You can check the old server’s email inbox for any messages that arrived after the switch
- Verification period: Some issues only become apparent after a few days of real traffic (cron failures, email delivery problems, performance under load)
Once you are confident everything is working on the new host, you can cancel the old hosting account.
Going Live: DNS and SSL
Once testing looks good, it is time to point your domain to the new host.
Update DNS Records
Log into your domain registrar or DNS provider and update:
- A record: Point to your new host’s IP address (your new host will provide this in their welcome email or dashboard)
- CNAME (www): Point to your new host’s domain or the same IP (check your host’s documentation for the recommended setup)
- Leave MX records alone unless you are intentionally changing email providers (see the email audit section above)
If you lowered your TTL in the preparation step, propagation will happen within minutes. You can verify propagation using a tool like whatsmydns.net, which checks DNS servers around the world to show you where propagation has completed and where it is still in progress.
If you did not lower your TTL, propagation can take up to 24-48 hours. During this period, some visitors will see the old site and some will see the new one.
Set Up SSL
Most hosts offer free SSL certificates through Let’s Encrypt. The installation process varies by host:
- cPanel hosts: Use the “SSL/TLS” section or “Let’s Encrypt” tool in cPanel
- Managed WordPress hosts (SiteGround, Bluehost, etc.): Usually auto-install SSL certificates when you add your domain
- VPS/dedicated servers: Use Certbot to install Let’s Encrypt from the command line:
sudo certbot --apache -d yourdomain.com -d www.yourdomain.com
After SSL is active, verify your WordPress settings:
- Go to Settings > General and make sure both “WordPress Address (URL)” and “Site Address (URL)” use
https:// - Check for mixed content warnings in the browser’s developer console (F12 > Console). Mixed content means some resources (images, scripts, stylesheets) are still loading over HTTP on an HTTPS page.
- If you find mixed content, use the Better Search Replace plugin to update any remaining
http://URLs tohttps://in the database.
For a detailed walkthrough, read our guide on moving WordPress from HTTP to HTTPS.
Post-Migration Checklist
This is the section most migration guides leave out entirely. After your site is live on the new host, work through every item on this list.
Cache and Performance
- Clear your browser cache
- Clear any WordPress caching plugin cache (WP Rocket, W3 Total Cache, etc.)
- Clear server-side cache (if your host uses Varnish, Redis, or a built-in cache)
- Clear CDN cache (Cloudflare, StackPath, etc.)
- Reactivate caching and performance plugins
Permalinks and URLs
- Go to Settings > Permalinks and click Save Changes to flush rewrite rules
- Check that all pages and posts load at the correct URL
- Verify that old URLs redirect properly (no 404 errors for existing content)
- Test internal links across the site
SSL and Security
- Verify SSL certificate is active (look for the padlock in the browser)
- Check for mixed content warnings using your browser’s developer console
- Reactivate security plugins (Wordfence, Sucuri, etc.)
- Verify firewall rules are configured on the new host
- Send a test email from your site (use a contact form or the WP Mail SMTP test function)
- Verify that WordPress notification emails are being delivered (registration, comments, etc.)
- Check that transactional emails work (WooCommerce order confirmations, password resets)
- Confirm MX records are correct if you changed DNS providers
Cron Jobs and Scheduled Tasks
This is a silent failure that most people don’t notice for days or weeks. After migration, verify:
- WordPress cron is working: Go to Tools > Site Health and check for cron-related warnings
- Scheduled posts publish on time (create a test scheduled post)
- Backup plugin schedules are running
- Any custom cron jobs defined at the server level are recreated on the new host
- WooCommerce scheduled actions are processing (if applicable)
If WordPress cron seems unreliable on the new host, you can disable it and use a real server cron instead. Add this to wp-config.php:
define('DISABLE_WP_CRON', true);
Then set up a server cron job to trigger WP-Cron:
*/15 * * * * wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
SEO and Analytics
- Verify Google Analytics or other tracking scripts are firing (check real-time reports)
- Re-verify your site in Google Search Console (if the IP changed, Google may flag it)
- Submit your sitemap to Google Search Console
- Check robots.txt is accessible and correct
- Verify that your site is not accidentally blocking search engines
- Monitor 404 errors in Search Console for the first few weeks
Functionality
- Test all forms (contact, signup, checkout, etc.)
- Test payment processing if you run an online store
- Verify user registration and login work correctly
- Check that file uploads work (media library, user avatars, etc.)
- Test any third-party integrations (CRM, email marketing, social sharing)
Handling Large Sites
If your WordPress site has a large database (500MB+) or a large media library (several GB), standard migration methods may time out or fail. Here are strategies for each scenario.
For Large Databases (500MB+)
Large databases are the most common cause of migration failures. phpMyAdmin typically times out on databases larger than 100-200MB, and plugin-based imports may hit server memory limits.
Solutions:
- WP-CLI is the fastest and most reliable option for large databases. Export with
wp db exportand import withwp db import. WP-CLI runs directly on the server and is not subject to web server timeout limits. - Command-line mysqldump gives you fine-grained control:
mysqldump -u username -p --max_allowed_packet=512M database_name > backup.sql
- Split large SQL files if your new host has import size limits. Tools like
csplitcan break a large SQL dump into smaller chunks that phpMyAdmin can handle. - Ask your new host about their MySQL import limits. Most hosts will temporarily increase
max_allowed_packetandwait_timeoutvalues if you open a support ticket and explain that you are migrating.
For Large Media Libraries (5GB+)
FTP transfers for large media libraries are painfully slow and prone to disconnection. A 10GB media library can take hours over FTP and will likely fail at least once.
Solutions:
- rsync over SSH is the best option. It is fast, can resume interrupted transfers, and only copies files that have changed:
rsync -avz --progress user@oldhost:/path/to/wp-content/uploads/ /path/to/wp-content/uploads/
- Offload media to cloud storage before migration. If you move your media library to Amazon S3, Google Cloud Storage, or DigitalOcean Spaces before migrating, the media is no longer tied to any hosting provider. This makes the migration much faster (you are only moving the database and code) and makes future host changes trivial. Plugins like WP Offload Media can handle this.
- Exclude thumbnails and regenerate. WordPress creates multiple sizes of every image you upload. You can skip transferring the generated thumbnails and regenerate them on the new host using the
wp media regeneratecommand. This can reduce the media transfer size by 50-70%. - Using All-in-One WP Migration: The Unlimited Extension handles exports and imports of any size without timeouts, and can export directly to cloud storage destinations like Google Drive, Dropbox, Amazon S3, and more.
For High-Traffic Sites
Migrating a site that receives thousands of visitors per hour requires extra planning to avoid any visible disruption.
- Schedule the migration during your lowest traffic window. Check your analytics to find the time when traffic is at its lowest (typically 2-5 AM in your primary audience’s timezone).
- Use a maintenance mode plugin to show a professional “we’re upgrading” page during the DNS switch window. This is better than visitors seeing a half-configured site.
- Consider a staged migration: Move the files first. Test thoroughly on the new host using the hosts file trick. Only switch DNS once you are 100% confident the new site is ready. With a low TTL, the switch will take minutes.
- Warm up caches on the new host before switching DNS. Visit key pages to populate the caching layer so the first real visitors get fast page loads instead of uncached responses.
What to Do If Things Go Wrong
Rollback Plan
If the migration fails or you discover issues after going live:
- Revert DNS immediately. Change your A record back to the old host’s IP address. If you lowered the TTL beforehand, this will take effect within minutes.
- Restore from backup on the old host if any data was modified during the migration attempt.
- Diagnose the issue on the new host while the old site is serving traffic. Fix the problem, test again using the hosts file trick, and retry the DNS switch.
Common Issues
Something broken after migrating? White screen, 404 errors, missing images, or login loops are all common and fixable. See our guide to 15 common WordPress migration errors and how to fix them for step-by-step solutions.
When to Ask for Help
If you are dealing with a complex migration (see our WordPress multisite migration guide for network-specific instructions), very large database, or custom server configurations, consider reaching out to your hosting provider’s support team. Many hosts offer assisted migration for free, and their team knows the specific server configuration requirements.
FAQ
How long does a WordPress migration take?
For a small to medium site (under 1GB), the actual migration takes 15-30 minutes using a plugin. DNS propagation can add a few minutes to a few hours depending on your TTL settings. Plan for a total of 1-2 hours including testing.
Will my site go down during migration?
Not if you follow this guide. Your old site stays live while you set up the new one. The only potential gap is during DNS propagation, which is minimal if you lowered your TTL beforehand.
Do I need to reinstall my plugins and themes on the new host?
No. Both the plugin method and manual method transfer your entire WordPress installation, including all plugins, themes, and their settings. You will need to reactivate caching and security plugins that you disabled before migration.
What happens to my SEO rankings after migration?
If you keep the same domain and URL structure, your rankings should not be affected. Make sure to re-verify your site in Google Search Console, submit your sitemap, and monitor for 404 errors. For a deeper dive, read about preserving SEO during migration.
Can I migrate from one host to another without changing my domain?
Yes, this is the most common migration scenario. Since your domain stays the same, you only need to update your DNS A record to point to the new host’s IP address. All your URLs, internal links, and SEO settings remain unchanged.
What if my new host uses a different PHP version?
Check PHP compatibility before migrating (see the pre-migration preparation section above). If your site needs an older PHP version, most hosts let you select the PHP version in the control panel. Long-term, you should update your plugins and themes to support the latest PHP version for security and performance.
Should I migrate my staging site or my live site?
Always migrate your live (production) site. A staging site may have test content, disabled features, or a different database state. Export directly from your live site to ensure you capture the current state of everything, including recent posts, comments, orders, and settings.
What if my old host has already expired?
If you still have a backup file (.wpress export, SQL dump, or file backup), you can restore from that. If you do not have a backup, contact your old host immediately. Many hosts retain account data for 30-90 days after expiration. The sooner you act, the better your chances of recovery.
Can I migrate a WordPress.com site to a self-hosted WordPress.org site?
Yes, but this is a different process than a host-to-host migration. WordPress.com offers a built-in export tool (Tools > Export) that creates an XML file of your content. You can then import this into a self-hosted WordPress.org installation using the WordPress Importer plugin. Note that themes, plugins, and some customizations will not transfer and will need to be recreated manually.
Running a WooCommerce store? E-commerce migrations require extra steps for payment gateways, order handling, and subscription continuity. Read our complete WooCommerce migration guide for a detailed walkthrough.
