WordPress migration means moving a site’s files, database and configuration from one server or domain to another without losing content, functionality or rankings. There isn’t one right way to do it. The right method depends on your technical comfort, whether you have SSH access, and how complex the site is. Below are the four real options and which one fits which situation, followed by the step-by-step process, a full migration checklist and the post-migration checks I run on every move.
Which type of WordPress migration are you doing?
Most WordPress migrations fall into one of five types: moving to a new host, changing the domain, switching from HTTP to HTTPS, pushing a local build live, or pushing staging to production. The core process is the same for all of them. What changes is how much URL replacement, redirect work and DNS work you have to plan.
| Migration type | What changes | Extra work to plan for |
|---|---|---|
| Host to host | The server only; domain and URLs stay the same | DNS cutover and a server that matches your PHP and database needs |
| Domain change | Every stored URL | Full database search-replace and a 301 redirect from every old URL |
| HTTP to HTTPS | The protocol | SSL certificate, search-replace from http:// to https://, and a redirect from HTTP |
| Local to live | Server and URL (for example a .local address to your real domain) | Search-replace for the local URL and any absolute file paths |
| Staging to production | Content or code tested on staging | Deciding what overwrites live data, especially orders and form entries on a store |
Moving from another platform such as Wix, Squarespace or Joomla is a different job, because the content has to be exported and rebuilt. The guide to migrating a website to WordPress covers that, and the Wix to WordPress migration case study shows how one of those projects ran.
Method 1: A Migration Plugin
Duplicator, All-in-One WP Migration and UpdraftPlus all package your files and database into a single archive you can restore on the new host. Install the plugin on the source site, generate the backup package, install a fresh WordPress on the destination, then restore the package there.
Best for: most site owners and small-to-medium sites. It’s the lowest-technical-skill option that still handles the database URL replacement automatically, which is the step manual migrations most often get wrong. Watch for: free-tier size limits on some plugins. A large media library or a big WooCommerce order history can exceed what the free version handles in one package.
Method 2: Host-to-Host Migration Tools
Many hosts provide a built-in migration tool for moving a site onto their platform, sometimes handling the entire process (files, database, DNS guidance) with a few clicks. Check whether your destination host offers one before doing anything else, since it’s often the fastest option when it’s available.
Best for: moving specifically to a host that supports it. Watch for: it only works one direction (into that host), and it’s a black box. If something goes wrong mid-migration, you have less visibility into what happened than with a manual or WP-CLI approach.
Method 3: WP-CLI Over SSH
If you have SSH access to both servers and are comfortable on the command line, WP-CLI gives you the most control and, for a technical user, the fastest process:
# On the old server, from the WordPress root
wp db export backup.sql
rsync -avz ./ user@newserver:/path/to/destination/
# On the new server, after updating wp-config.php with the new database details
wp db import backup.sql
wp search-replace 'https://oldsite.com' 'https://newsite.com' --skip-columns=guid --dry-run
wp search-replace 'https://oldsite.com' 'https://newsite.com' --skip-columns=guid
rm backup.sqlThe --dry-run pass shows how many replacements would happen without saving anything, so you can sanity-check before the real run. wp search-replace handles PHP serialized data correctly. A plain SQL find-and-replace breaks it: change the length of a string inside a serialized array and WordPress can no longer read it. Skipping the guid column follows the official migration guidance, since GUIDs are meant to stay fixed. If you’re keeping the same domain, you can skip the search-replace entirely. Delete the SQL file afterwards so it isn’t left in a public folder.
Best for: developers who already work in the command line and want precise control over exactly what moves and when. Watch for: no safety net if you skip a step. This method assumes you already know what a correct migration looks like, since there’s no plugin UI catching missing pieces for you.
Method 4: Manual (FTP + phpMyAdmin)
Download files via FTP, export the database, create a new database on the destination, import it, and update wp-config.php and the site URL by hand through phpMyAdmin. For the URL replacement, use the Better Search Replace plugin once the site loads, because it handles serialized data the same way WP-CLI does. This is the fallback when a host doesn’t support the other three methods.
Best for: restrictive hosting environments with no SSH and no migration plugin support. Watch for: it’s the most error-prone method by a wide margin. A missed URL replacement or a wrong file permission is easy to overlook and hard to diagnose afterward.
Which Method Should You Use?
Check for a host-to-host tool first: it’s free speed if it exists. If not, a migration plugin is the right default for most people, since it handles the URL replacement step that manual migrations get wrong most often. Reach for WP-CLI only if you’re already comfortable with SSH and want more control than a plugin gives you. Manual FTP is the last resort, reserved for hosting setups that block everything else.
| Method | Skill needed | Needs SSH? | Handles URL replacement? | Best for |
|---|---|---|---|---|
| Migration plugin | Low | No | Yes, automatically | Most small and medium sites |
| Host migration tool | Low | No | Usually, handled by the host | Moving onto a host that offers one |
| WP-CLI | High | Yes, on both servers | Yes, with wp search-replace |
Developers and large sites |
| Manual FTP + phpMyAdmin | Medium to high | No | No, you add a tool for it | Hosts that block everything else |
How to migrate a WordPress site step by step
A safe WordPress migration follows the same order whichever method you use: back up, audit, prepare the new host, move the files and database, update wp-config.php, replace URLs, test on the new server, then switch DNS. Testing before the DNS switch is the step that keeps visitors from ever seeing a half-moved site.
- Back up everything. Take a full file backup and a database export, keep copies in two places (local and cloud), and test-restore the backup if you can.
- Audit the current site. Write down active plugins and versions, the theme and child theme, integrations (payments, email, analytics), PHP and MySQL versions, and any custom
.htaccessrules. - Prepare the new host. WordPress.org currently recommends PHP 8.3 or greater and MySQL 8.0 or MariaDB 10.11 or greater. Create the database and database user, and install the SSL certificate if the site will run on HTTPS.
- Lower the DNS TTL. 24 to 48 hours before cutover, drop the TTL on your domain’s A record to 300 seconds (5 minutes) so the switch reaches visitors quickly.
- Move the files and database. Using your chosen method, transfer
wp-content(plugins, themes and uploads) and import the database on the new server, then check that every table came across. - Update wp-config.php. Set
DB_NAME,DB_USER,DB_PASSWORDandDB_HOSTfor the new database, and replace the security keys with fresh ones from the WordPress salt generator. - Replace URLs if the domain or protocol changed. Use WP-CLI or Better Search Replace so serialized data survives, and leave the
guidcolumn alone. - Test on the new server before DNS changes. Point your own computer at the new server’s IP through your hosts file, log in, resave permalinks under Settings > Permalinks, and click through the key pages, forms and checkout.
- Switch DNS and monitor. Update the A record (or the origin IP in Cloudflare), then watch the site, error logs and uptime for 24 to 48 hours. Keep the old hosting for 7 to 30 days before cancelling, in case you need something from it.
- Work through the post-migration checklist below.
WordPress migration checklist
A WordPress migration checklist splits into three stages: before the move (backups, audit, new host ready), during the move (files, database, configuration, URLs and DNS), and after the move (testing, SEO, performance and security). Work through it in order and tick each item off. The post-migration checks have their own section below.
Before the migration
- Full file backup and database export, stored in two places
- Backup restore tested on a local or staging copy
- Active plugins, theme, child theme and integrations documented
- Screenshots or exports of key plugin settings, including your SEO plugin
- New hosting account ready, with PHP and database versions checked
- New database and database user created
- SSL certificate installed on the new host if the site uses HTTPS
- DNS TTL lowered to 300 seconds 24 to 48 hours ahead
- Low-traffic window chosen, team told, maintenance page ready
During the migration
- Plugins, themes and uploads folders transferred, folder sizes compared
- File permissions set (755 for folders, 644 for files)
- Database imported with no errors, table count matching the original
- wp-config.php updated with new database credentials and fresh salts
- Search-replace run for the old domain or protocol (WP-CLI or Better Search Replace)
- Site tested through the hosts file before DNS changes
- A record updated, plus CNAME and MX records if email or subdomains move too
Post-migration checklist: what to test after moving WordPress
After a WordPress migration, test the things that cost money first: forms, checkout and email. Then check logins, media, permalinks, SEO settings such as robots.txt and the sitemap, performance and security. Run the list on the new server before DNS switches, and again once real traffic arrives.
Forms, email and logins
- Every contact and signup form submits, and the email arrives in an inbox
- Password reset emails send (if they don’t, set up SMTP with a plugin such as WP Mail SMTP)
- Existing users can log in, new users can register, and roles are intact
WooCommerce checkout (if you run a store)
- Add to cart and complete a full checkout with the payment gateway’s test mode
- Order confirmation email sends and the order appears in WooCommerce admin
- Stock is deducted, and tax and shipping options calculate correctly
Pages, media and permalinks
- Inner pages load (if only the homepage works, resave permalinks)
- Images, featured images, galleries and file downloads all display
- New media uploads work in the admin
- Menus, search and mobile layout work on a real phone
SEO and analytics
- Settings > Reading does not have “Discourage search engines” ticked (a common leftover from staging)
- robots.txt allows crawling and the XML sitemap loads
- Meta titles and descriptions are intact in your SEO plugin
- 301 redirects work for every old URL if the domain changed
- Analytics is recording visits and the sitemap is resubmitted in Google Search Console
Performance and security
- Speed tested with PageSpeed Insights and compared with your pre-migration numbers
- Caching and CDN configured on the new server
- HTTPS padlock showing with no mixed content warnings
- Core, plugins and themes updated, admin password changed
- Backup schedule running on the new host
Cleanup
- Maintenance mode off and all caches cleared
- Migration plugins and leftover backup files deleted
- Old hosting kept for 7 to 30 days, then cancelled
For the wider launch checks beyond the migration itself (structured data, analytics events, redirect validation), see the WordPress site launch checklist.
How to migrate WordPress without downtime
To migrate WordPress without downtime, keep the old site live until the new server is fully tested, then make the switch fast. Lowering the DNS TTL shrinks the changeover window. Routing the domain through Cloudflare’s proxy removes most of it, because you only change the origin IP behind Cloudflare and visitors keep resolving to the same address.
Low TTL and a quick cutover
Lower the TTL to 300 seconds 48 hours ahead, finish and test the migration on the new host through your hosts file, then update the A record. Most visitors move over shortly after the old TTL expires. Watch both servers for a day, since a few cached visitors may still reach the old one.
Cloudflare proxy
With the domain’s A record set to Proxied in Cloudflare, visitors connect to Cloudflare, which forwards traffic to your server. Migrate, test the new host directly by its IP, then change the origin IP in Cloudflare’s DNS settings. This is the method I use for stores and busy sites, and the free plan is enough.
Staging to production push
Many managed hosts let you build a staging copy on the new server, test it fully, and push it live in a short maintenance window. If your host doesn’t offer this, the guide to creating a WordPress staging site covers the setup.
One catch for WooCommerce: any order placed on the old server after you export the database won’t exist on the new one. Schedule the cutover in a quiet window, or briefly put the store in maintenance mode between the final export and the DNS switch.
What can go wrong during a WordPress migration?
The problems that show up most after a WordPress migration are database connection errors, broken images, 404s on every page except the homepage, mixed content warnings, emails that stop sending, a slower site and lost rankings. Each has a predictable cause, and most take minutes to fix once you know where to look.
| Problem | Usual cause | Fix |
|---|---|---|
| “Error establishing a database connection” | Wrong credentials or DB_HOST in wp-config.php, or a database user without privileges | Check the values against your host’s control panel, confirm the user has all privileges on the database, and temporarily set WP_DEBUG to true to see the exact error |
| Broken images or empty media library | Incomplete uploads transfer, wrong permissions, or old URLs still in the database | Re-upload wp-content/uploads, set permissions to 755/644, and rerun search-replace |
| 404 on every page except the homepage | Permalinks not regenerated, .htaccess missing, or mod_rewrite off |
Go to Settings > Permalinks and click Save Changes, then ask the host about mod_rewrite if that doesn’t fix it |
| Mixed content or “Not Secure” warning | Hard-coded http:// URLs left after an HTTPS move | Search-replace http:// to https://, redirect HTTP to HTTPS, and check the theme and plugins for hard-coded assets |
| Emails stop sending | PHP mail() blocked on the new host, or SPF and DKIM records not updated | Send through an SMTP service with a plugin like WP Mail SMTP and update SPF and DKIM |
| Site is slower than before | Older PHP version, no object cache, or caching not configured on the new server | Move to a current PHP version, enable Redis or Memcached if offered, and set up page caching and a CDN |
| Rankings drop | Missing 301 redirects after a domain change, robots.txt or the Reading setting blocking crawlers, or canonicals pointing at the old domain | Add the redirects, unblock crawling, resubmit the sitemap in Search Console and request indexing of key pages |
For a domain change, this rule in the old domain’s .htaccess sends every old URL to the same path on the new domain with a 301:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldsite\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.oldsite\.com$
RewriteRule (.*)$ https://newsite.com/$1 [R=301,L]The guide to 301 redirects with .htaccess covers other redirect patterns. If the new server feels slow on a store, the WooCommerce performance guide covers object caching and page caching setup.
If you’d rather not run the migration yourself, especially for a WooCommerce store where downtime has a real cost, WordPress migration services cover the process end to end with zero downtime and no lost SEO.
