How to Move WordPress to a New Host Without Breaking Anything (2026)

Published October 19, 2026

Moving WordPress hosts is routine — thousands of sites migrate daily. The process is well understood; breakage comes from skipping steps, not from difficulty. Here’s the full playbook.

Before you touch anything

1. Audit the current site. Note the WordPress version, PHP version, active plugins, and theme. Screenshot the plugins list — you’ll compare after.
2. Check the new host’s PHP version. If the new host runs a newer PHP than the old one, outdated plugins can break. Update everything on the old host first, where it’s safe.
3. Lower DNS TTL to 300 seconds at least 24 hours before the move. This makes the final cutover propagate in minutes instead of a day. (See the own-your-internet checklist for DNS basics.)
4. Full backup. Files + database, downloaded to your own computer — not just sitting on the old host. Verify the backup files aren’t empty.

Method 1: Migration plugin (recommended for most)

Plugins like Duplicator, All-in-One WP Migration, or Migrate Guru package your entire site — files, database, settings — into a bundle you deploy on the new host.

1. Install the plugin on the old site and create a full backup package.
2. On the new host, do a fresh WordPress install (or use the plugin’s installer).
3. Upload/import the package on the new host and run the installer.
4. The installer rewrites URLs from old to new — verify it caught everything (see testing below).

Watch out: free tiers of migration plugins often cap package size (commonly ~512MB). Media-heavy sites exceed this fast — either pay for the pro tier or use the manual method.

Method 2: Manual migration (full control)

1. Export the database via phpMyAdmin (or wp db export if you have WP-CLI). Download the .sql file.
2. Download all files via SFTP: wp-content at minimum; the full WordPress root is simpler.
3. Upload files to the new host’s web root via SFTP.
4. Create a database on the new host; note the name, user, and password.
5. Import the .sql into the new database via phpMyAdmin or command line.
6. Edit wp-config.php with the new database credentials.
7. Search-replace URLs in the database: old domain → new domain (or same domain, if DNS hasn’t cut over yet — use the host’s temporary URL for testing). Use WP-CLI’s search-replace or the Better Search Replace plugin — never a raw SQL find/replace on serialized data; it corrupts widget and plugin settings.

The staging test (do not skip)

Before pointing DNS at the new host, test the migrated site on the new host’s temporary URL or a hosts-file override:

• Homepage and 5–10 inner pages load
• Images and media display (broken images = incomplete file transfer)
• Forms submit (contact forms, checkout if WooCommerce)
• Login works (/wp-admin)
• No PHP errors in the debug log
• SSL certificate is active on the new host

Fix everything here. This is the entire point of the staging step — problems found now are free; problems found after DNS cutover are downtime.

The DNS cutover

1. Point DNS (A record, and AAAA if IPv6) to the new host’s IP. If you lowered TTL earlier, propagation takes minutes.
2. Keep the old site live for 48 hours. Don’t cancel the old hosting yet — some visitors and email-adjacent services resolve the old IP from cache.
3. Freeze content changes during the cutover window. If it’s a blog or store taking orders, put the old site in maintenance mode after the final backup so no orders/comments land on the old copy after you’ve migrated.
4. Verify globally with a DNS propagation checker — confirm the new IP is resolving everywhere before touching the old host.

After the cutover

• Re-check SSL (mixed-content warnings are common — run a search for http:// references)
• Confirm scheduled posts and cron jobs run (WP-Cron depends on traffic; verify)
• Reconnect uptime monitoring to the new IP
• Update any hardcoded IPs: firewall allowlists, API callbacks, CDN origins
• After 7 clean days: cancel the old hosting

Special cases

Multisite. WordPress multisite migrations add subdomain/subdirectory mapping complexity. The search-replace must handle each subsite’s tables (wp_2_posts, etc.). Test every subsite individually — multisite failures are per-site and easy to miss.

WooCommerce / membership sites. These have orders, user accounts, and sessions — data that changes constantly. Plan the cutover for the lowest-traffic window, put the old site in maintenance mode before the final backup, and verify order data matches after migration. A 10-minute gap can mean lost orders.

Huge media libraries. Sites with tens of GB of uploads make plugin-based migration painful (package size caps, timeouts). Use the manual SFTP method, or rsync if you have shell access on both ends — resumable and far faster.

Email on the old host. Say it again because it’s the #1 post-migration surprise: moving the website doesn’t move email. If MX records pointed at the old host, decide where email lives before cutover day — ideally moved earlier, on its own schedule.

The rollback plan

Hope for the best, plan for the worst. Before cutover, decide:

• Rollback trigger: what specifically sends you back? (Checkout broken, site down >30 min, data loss.) Define it before you’re stressed.
• Rollback method: DNS back to the old IP. That’s it — which is why you keep the old host live and the old site untouched for a week.
• Communication: if the site matters to customers, have a holding message ready. “Brief maintenance” beats a broken store.

Most migrations never need the rollback. Having one is what makes the migration low-stress instead of terrifying.

Common failures and fixes

• White screen: usually a PHP version mismatch or a plugin incompatible with the new PHP. Rename the plugins folder via SFTP to disable all plugins, then reactivate one by one.
• Database connection error: wrong credentials in wp-config.php — recheck name, user, password, host (some hosts don’t use localhost).
• Broken images/links: incomplete search-replace. Re-run it, including serialized data handling.
• Redirect loops: conflicting .htaccess rules or SSL settings. Check the new host’s SSL mode vs WordPress’s site URL protocol.
• Email stopped working: if email was bundled with old hosting, migrating the website doesn’t migrate mail. Sort email separately before the move.

Bottom line

Backup, migrate, test on staging, cut DNS over, keep the old host warm for a week. Every WordPress disaster story you’ve heard skipped one of those steps. The migration itself is straightforward — the discipline around it is the whole job. Do it once carefully and you’ll never fear moving hosts again; the freedom to leave a bad host is worth more than any single feature.

Keep reading: when to upgrade from shared to VPS if the migration is part of an upgrade, or the own-your-internet checklist to audit everything else while you’re at it.