Skip to content
Website Rescue Rescue

Website Migration

WordPress Migration Failed

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access often needed

Graphic options · pick what to keep

dnsFlow

requestTimeline

decisionTree

serverRack

Direct answer

A failed WordPress migration usually means incomplete files, a partial or wrong database import, mismatched wp-config.php credentials, broken serialized URLs, or DNS still pointing at the old host — so identify which step failed (export, transfer, import, or cutover) before re-running the whole move.

Migration failures show up as database connection errors, blank pages, redirect loops to the old domain, missing media, or a stuck progress bar — often several at once. This guide walks the migration pipeline in order: verify backups, confirm files and database on the destination, align wp-config and URLs, then update DNS and SSL — so you repair the broken stage instead of starting from scratch blindly.

Intermediate

What the error means

Moving WordPress is a sequence: export files and database from the source, transfer them to the destination host, import the database, update wp-config.php with new DB credentials and salts if needed, replace old domain URLs in a serialization-safe way, fix file permissions, then point DNS and SSL at the new stack. Failure at any step mimics unrelated errors — “Error establishing a database connection” is often wrong DB name or user on the new host, not a corrupt site; redirect loops often mean siteurl/home still show the old URL while DNS already moved. Migration plugins can time out on large tables or skip uploads. Manual copies forget wp-content/uploads or .htaccess. Treat the failure message as a clue to which stage broke, and keep the source site untouched until the destination is verified on a temporary URL.

Common symptoms

  • Migration plugin stops below 100% or reports timeout, disk full, or HTTP error
  • Destination shows “Error establishing a database connection” immediately after import
  • Site loads on temporary URL but breaks when DNS switches to the live domain
  • Homepage redirects to the old domain or old host parking page
  • Layout loads but images, CSS, or uploads 404 on the new server
  • White screen or critical error only on the migrated copy
  • wp-admin login fails with correct password or endless redirect
  • Mixed content or “Not secure” warnings after cutover despite SSL on the new host

Most likely causes

  1. 01 Database import incomplete — max packet size, timeout, or wrong charset/collation
  2. 02 wp-config.php still has old database host, name, user, or password
  3. 03 Files missing from wp-content (uploads, plugins, mu-plugins, custom drop-ins)
  4. 04 Naive search-replace broke serialized PHP data in options and post meta
  5. 05 siteurl/home or hardcoded URLs still reference the source domain
  6. 06 DNS A/AAAA or nameservers not updated, or TTL/propagation still serving old IP
  7. 07 File permissions or ownership wrong on the new host so PHP cannot read files
  8. 08 PHP version or extensions on destination incompatible with source site

What changed before the problem started

  • Full or partial migration to a new host, server, or domain
  • Switch from temporary/staging URL to production DNS
  • SSL certificate installed or CDN proxy enabled on the new stack
  • Migration plugin or manual SQL import used for URL replacement
  • PHP version changed during the move
  • Database user credentials recreated on the new hosting panel

Troubleshooting steps

  1. 01

    Confirm you still have a working source backup

    Before retrying, verify you have a fresh file backup and database dump from before the failed attempt. Do not delete the old host until the new site loads correctly on a temp URL. Success signal: restorable archive and SQL export are stored off-server.

  2. 02

    Identify which migration stage failed

    Note whether the error appeared during upload, SQL import, URL replace, or after DNS change. Plugin logs and host import screens usually say “import” vs “connection.” Success signal: you can name the broken stage — files, database, URLs, or DNS.

  3. 03

    Verify database exists and wp-config matches the panel

    In the new host panel, confirm database name, user, password, and host (often localhost). Match every value in wp-config.php exactly. Re-import SQL if tables are missing or partial. Success signal: phpMyAdmin shows complete wp_* tables and the front end connects.

  4. 04

    Confirm wp-content uploaded completely

    Compare sizes of wp-content/uploads and large plugin folders between source and destination. Re-sync via SFTP/rsync if the migration plugin skipped files. Success signal: media URLs return 200 on the temp hostname.

  5. 05

    Update URLs with a serialization-safe tool

    Replace old domain URLs using WP-CLI search-replace, your migration plugin’s built-in replace, or a trusted dedicated tool — not raw SQL on wp_options. Update siteurl and home to the temp or final URL as appropriate. Success signal: no redirects to the old domain on the temp URL.

  6. 06

    Test on temporary URL before changing DNS

    Load the site on the host-provided temp domain or hosts-file override. Fix PHP errors, permalinks, and SSL on the new stack while DNS still points at the old server. Success signal: full browse and wp-admin work on temp URL, then schedule DNS cutover.

When to stop troubleshooting

Hand off when repeated imports fail on large databases you cannot split; when serialized corruption is widespread in builder content; when DNS/registrar access is locked; when the destination host cannot run required PHP extensions; or when ecommerce orders must stay live during cutover. Provide migration tool logs, wp-config redacted screenshot, import error text, and whether temp URL works.

Information to collect before requesting help

  • 01 Migration method (plugin name, manual SFTP, host mover) and failure step
  • 02 Exact error message or plugin log excerpt
  • 03 Whether source site still online and backup timestamp
  • 04 New host database credentials vs wp-config.php (redacted)
  • 05 Table count and size in destination phpMyAdmin
  • 06 Old and new domain URLs; temp URL test result
  • 07 DNS records planned or already changed (A, AAAA, CNAME, MX)
  • 08 PHP version on source vs destination and recent plugin list

How a professional repairs the problem

We map the failure to a pipeline stage, restore from verified backups when needed, and re-import databases with appropriate size limits and charset. We sync missing wp-content, align wp-config and serialization-safe URL replacements, fix permissions and permalinks on the temp hostname, then coordinate DNS/SSL cutover with lowered TTL. Post-cutover we purge caches, verify media and admin login, and scan for mixed content or redirect leftovers to the old domain.

Frequently asked questions

Should I run the migration plugin again from zero? +
Only after you know why it failed. Re-running on a half-imported database can compound errors. Often it is faster to drop partial tables, restore a clean SQL dump, and fix upload limits than to click “retry” repeatedly.
Why does the temp URL work but the live domain fails? +
Usually DNS still points elsewhere, SSL is not installed on the live hostname, or siteurl/home were set to the temp URL and never updated for production. Fix DNS and URLs together.
Is “Error establishing a database connection” always a migration problem? +
On a fresh import, almost always it is wrong credentials, missing tables, or the DB user lacks privileges — not WordPress core corruption. Match wp-config to the host panel first.
Can I change DNS before testing the new host? +
Not recommended. Validate on temp URL or hosts file first. Early DNS changes send live traffic to a broken destination and complicate rollback.
Why are images missing after migration? +
Uploads folder not copied, wrong file permissions, or URLs still pointing at the old domain/path. Re-sync wp-content/uploads and run serialization-safe URL updates.
Do I need new salts in wp-config after migration? +
Salts do not need to change for a straight clone, but regenerating them logs everyone out — acceptable on staging. Never copy wp-config from the wrong environment without updating DB constants.

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.

Written by Website Rescue

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.