Skip to content
Rescue 404
Rescue

Website Migration

Move WordPress Website to New Host (WordPress Repair)

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

Moving WordPress to a new host means copying files and the database, pointing wp-config.php at the new database credentials, updating URLs with a serialization-safe replace when needed, verifying the site on a temporary URL, then changing DNS (and SSL) — in that order. Do not flip DNS until the destination works on a temp hostname, and keep the old host online until cutover is proven.

This is WordPress Repair for a planned host change, not panic downtime: a clean move is a checklist (backup → transfer → import → config → URLs → test → DNS), while most “migration disasters” are skipped steps. This guide walks a safe production cutover so you land on the new server with working admin, media, and permalinks — then only update DNS when the destination is ready. If the move already failed, use the migration-failed guide; this page is how to run the move correctly the first time.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • WordPress migration docs describe moving files and the database, then updating the site URL (including via `WP_HOME` / `WP_SITEURL` or the options table) so the site works in the new location. (Moving WordPress)
  • wp-config.php holds the database name, user, password, and host values that must match the destination database you create on the new host. (Editing wp-config.php)
  • WP-CLI search-replace updates strings across selected tables while handling PHP serialized data and skipping primary keys. (WP-CLI search-replace)
  • Cloudflare’s full setup docs cover pointing the domain’s nameservers at Cloudflare after the site is ready on the new host, so DNS cutover stays controlled. (Cloudflare full zone setup)

What the error means

WordPress is portable because content lives in MySQL and files under the web root, but the pieces must stay consistent. On the new host you create a database and user, upload WordPress files (especially `wp-content`), import the SQL dump, and set `DB_NAME`, `DB_USER`, `DB_PASSWORD`, and `DB_HOST` in wp-config.php to match the panel. Site URLs in options (and serialized theme/builder data) must match the hostname you are testing — temp URL first, live domain at cutover — using WP-CLI search-replace or a migration tool that understands PHP serialization. DNS A/AAAA (or nameserver) changes send browsers to the new IP; SSL must exist for the live hostname there. Email MX records are separate — leave them alone unless you intentionally move mail.

Common symptoms

  • You need the site on a new host with minimal downtime and a clear cutover plan
  • Temporary URL on the new host shows the site before customers are pointed there
  • After DNS change, some regions still hit the old host until TTL expires
  • Post-move checklist items fail: missing uploads, wrong URLs, or permalink 404s
  • wp-config still has old database credentials until you update them on the destination
  • SSL warning on the live domain until a certificate is issued on the new server
  • Migration plugin progress bar completes on staging/temp but live cutover still needs DNS and cache purge

Most likely causes

  1. 01 Incomplete file sync — especially `wp-content/uploads`, mu-plugins, or drop-ins
  2. 02 Partial database import from timeout, max packet size, or wrong charset
  3. 03 wp-config.php database constants not updated for the new host
  4. 04 Naive search-replace corrupting serialized options and page-builder data
  5. 05 DNS changed before the destination was verified on a temporary URL
  6. 06 PHP version or missing extensions on the new host incompatible with the site
  7. 07 SSL, CDN, or cache still pointing at the old origin after cutover

What changed before the problem started

  • Hosting provider or server plan is changing by choice (not an emergency restore)
  • A staging or temporary URL was created on the destination for pre-DNS testing
  • DNS TTL may be lowered ahead of cutover to shorten propagation
  • SSL will be re-issued or re-validated on the new host for the live domain
  • Optional: PHP version upgrade planned as part of the move

Troubleshooting steps

  1. 01

    Inventory access and take a verified backup on the old host

    Confirm SFTP/SSH, host panel, DNS registrar, and wp-admin access. Export a full file backup and a complete database dump; restore-test or at least verify archive size and table count. Do not cancel the old host until the new site is verified live.

  2. 02

    Prepare the new host: app, database, PHP, and temporary URL

    Create the site/app, empty database + user with full privileges, and a PHP version equal to or newer than production (within what your plugins support). Note the temporary hostname the host provides for testing before DNS moves.

  3. 03

    Copy files and import the database

    Transfer WordPress core files and all of `wp-content` (uploads included) via SFTP/rsync or a trusted migration tool. Import SQL with CLI or panel tools that can handle the dump size. Success signal: phpMyAdmin shows a full set of `wp_*` tables and uploads are present on disk.

  4. 04

    Point wp-config.php at the new database and test the temp URL

    Set `DB_*` constants to the new host’s values. Load the site on the temporary URL (or hosts-file override). Fix connection errors here — not after DNS — and confirm wp-admin login works on the destination.

  5. 05

    Run serialization-safe URL updates if the hostname changes for testing

    If the temp URL differs from the old live domain, use WP-CLI `search-replace` or your migration plugin’s replace — not raw SQL on serialized rows. Update `siteurl` and `home` appropriately. Success signal: no redirects back to the old host on the temp URL.

  6. 06

    Cut over DNS and SSL only after a full temp-URL checklist

    Lower TTL ahead of time when possible, issue SSL for the live domain on the new host, update A/AAAA (or nameservers) to the new IP, purge CDN caches, and keep MX unchanged. Verify with public DNS lookups and browse as a logged-out user after propagation.

When to stop troubleshooting

Hand off if the database is too large for your import path, page-builder serialization is already corrupt, DNS/registrar access is locked, the new host cannot meet PHP/extension requirements, or ecommerce orders must stay continuous through cutover without a maintenance window. Provide dump size, temp-URL test results, and whether the old host remains available for rollback.

Information to collect before requesting help

  • 01 Old and new host names; whether a temporary URL exists
  • 02 Migration method planned (plugin, manual SFTP + SQL, host migrator)
  • 03 Approximate database size and `wp-content/uploads` size
  • 04 Current PHP version and target PHP version
  • 05 DNS where the domain is managed (registrar vs Cloudflare, etc.)
  • 06 Whether email/MX stays on the old host or a third party
  • 07 SSL/CDN in front of the site today
  • 08 Ecommerce or membership plugins that use webhooks

How a professional repairs the problem

We stage the site on the destination with matched files and a clean database import, align wp-config and serialization-safe URLs on a temp hostname, fix permalinks and media, then schedule DNS/SSL cutover with a rollback path on the old host. Post-cutover we verify admin login, forms, payments/webhooks if present, and purge caches so visitors are not stuck on the previous origin.

Frequently asked questions

Should I change DNS before uploading files? +
No. Build and test on the new host’s temporary URL (or a hosts-file override) first. Early DNS changes send live traffic to an unfinished server and make rollback harder.
Will moving hosts change my domain name? +
Not by itself. You can keep the same domain and only change the A/AAAA target (or nameservers). Moving to a new domain is a separate URL-replacement project.
Do I need to reinstall WordPress from scratch on the new host? +
Only if you prefer a clean core and then copy `wp-content` + database. Many moves copy the full site. Either way, the database and `wp-content` must come from the source site.
How long does DNS propagation take? +
Often minutes to a few hours when TTL was lowered; globally it can take longer if old TTLs were high. Keep the old host until public resolvers show the new IP consistently.
What about email on the same domain? +
Website hosting and email hosting are often separate. Leave MX (and related mail records) untouched unless you intend to move mail in the same project.
Can I upgrade PHP during the move? +
Yes, but test on the temp URL first. A PHP bump can surface plugin fatals that look like a “bad migration” if you change hosting and PHP in the same untested cutover.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.