WordPress migrations go wrong most often in one of two ways: moving too fast and breaking something, or getting paralyzed by the complexity and waiting too long. Here's the correct sequence that avoids both.
When Do You Need to Migrate?
Common migration scenarios:
- Moving to better/faster hosting
- Moving from a subdomain to a root domain after launching
- Changing domain names (rebranding)
- Moving from a development environment to production
- Consolidating sites or moving to a multisite setup
Step 1: Full Backup Before Touching Anything
Before anything else: a complete backup of your current site. This means:
- All WordPress files (download via FTP or your host's file manager)
- Complete database export (from phpMyAdmin or WP-CLI:
wp db export backup.sql)
Store the backup off-site — not on the server you're migrating from. If something goes wrong at any point, this backup is your recovery option.
Step 2: Set Up the New Environment
Before touching DNS, get the new environment fully operational using a temporary URL or staging domain. Most hosts provide this — a URL like yourdomain.temp.host.com or an IP address.
Install WordPress on the new server and configure it. Don't touch your live site's DNS yet.
Step 3: Move Files and Database
The most reliable migration method:
- Install the Duplicator plugin on your current site
- Create a package (Duplicator bundles your files + database into a portable archive)
- Download the package and installer to your computer
- Upload both to your new server's web root
- Run the installer via the temporary URL (yourdomain.temp.host.com/installer.php)
- Follow the installer — it handles database import and URL replacement
Alternative: All-in-One WP Migration does the same thing with a simpler interface. Both tools handle serialized data correctly (a common source of migration errors when done manually).
Step 4: Update URLs and Verify
After migration, verify the site works correctly on the new server's temporary URL:
- Browse the site on the temporary URL — pages, menus, images
- Test any forms and checkout (if WooCommerce)
- Log in to WordPress admin and check all settings
- Check that plugins activate and function correctly
- Verify SSL is working (if the new host uses a different certificate)
Do not cut over DNS until the site is working perfectly on the staging URL.
Step 5: Lower Your DNS TTL
Before changing DNS, lower your domain's DNS TTL (Time To Live) to 300 seconds (5 minutes). This means DNS changes propagate faster when you make the cutover. Do this 24–48 hours before your planned cutover, since the old TTL needs to expire first.
Step 6: DNS Cutover
Update your domain's DNS A record (or nameservers if moving to a new registrar) to point to the new server's IP address. With a low TTL, this propagates within 5–15 minutes for most users.
During this window, some visitors will hit the old server and some will hit the new one. Both should be working. This is normal and expected.
Step 7: Verify on the Live Domain + Post-Migration
Once DNS has propagated:
- Verify the site loads on the real domain
- Check SSL certificate is valid on the real domain
- Submit the new sitemap to Google Search Console
- If changing domains: set up 301 redirects from all old URLs to new ones
- Keep the old server running for 48 hours as a fallback
Frequently Asked Questions
How long does a WordPress migration take?
A straightforward host-to-host migration (same domain) takes 2–4 hours including verification time. A domain change migration with redirect setup takes 4–8 hours. A complex multisite or custom configuration migration can take longer.
Will Google rankings be affected by a migration?
A same-domain host migration with no URL changes: minimal effect. A domain name change: temporary ranking fluctuation (301 redirects pass ~99% of link equity, but Google takes time to process them). Properly done migrations recover rankings within weeks.
What's the most common migration mistake?
Changing DNS before verifying the site works on the new server. This takes the live site down during the move. Always verify on the staging URL first.
Should I migrate myself or hire a developer?
If you're comfortable with FTP, phpMyAdmin, and DNS settings, a basic migration is DIY-able. If any of those terms are unfamiliar, it's worth hiring a developer — a botched migration can mean significant downtime.