Skip to content
Rescue 404
Rescue

Website Migration

Website Works on Old Host but Not New Host

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

When the old host still serves the site correctly but the new host does not, the move usually failed at files, database credentials, PHP/runtime mismatch, document root, or DNS/SSL cutover — compare old vs new on a temporary URL before blaming the domain.

A site that still works on the previous host is good news: you have a known-good copy and a rollback path. The new stack is incomplete, misconfigured, or not receiving traffic yet. This guide isolates whether visitors hit the wrong server, whether the destination app cannot boot, or whether DNS and SSL cutover raced ahead of a working destination — then points you at a migration rescue path instead of endless panel guessing.

Intermediate

Key facts

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

  • WordPress migration docs cover moving files, the database, and updating URLs so the site works on the new host. (Moving WordPress)
  • DNS A and AAAA records map the hostname to the server IPs browsers actually contact. (MDN DNS glossary)
  • wp-config.php holds database connection settings that must match the new host's database credentials. (Editing wp-config.php)

What the error means

“Works on old, broken on new” is a comparison problem. The old host proves files and data were viable in one environment. The new host must receive a complete file set, a usable database (or equivalent app config), matching runtime (PHP version, extensions, Node, whatever the stack needs), correct document root and rewrite rules, and — only after that — DNS and certificates for the live hostname. Failures cluster: wrong docroot shows a default page or 404; wrong DB credentials show connection errors; missing uploads break media; PHP version gaps throw fatals; DNS still on the old IP makes “the new host” look fine locally while the public internet never reaches it. WordPress sites add wp-config and serialized URL quirks; static or other CMS sites fail for the same hosting and DNS reasons without those WP-specific layers.

Common symptoms

  • Old host URL or hosts-file override still loads the full site; new host shows blank, error, or parking page
  • Database connection error, critical error, or 500 only on the destination
  • New host temporary URL works partially; live domain still serves the old host or a registrar page
  • Homepage loads on the new host but images, CSS, or admin assets 404
  • Redirect loop or endless bounce to the old domain after cutover
  • SSL warning or “Not secure” on the new hostname while the old host was fine
  • PHP fatals or missing-extension errors that never appeared on the previous server

Most likely causes

  1. 01 Incomplete file sync — missing document root contents, uploads, vendor folders, or hidden configs (.htaccess, env files)
  2. 02 Database not imported, partial import, or app config still pointing at old DB host/user/password
  3. 03 Document root or subdomain pointed at the wrong folder on the new account
  4. 04 PHP (or other runtime) version or extensions on the new host incompatible with the site
  5. 05 DNS A/AAAA or nameservers never updated, or propagation still hitting the old IP
  6. 06 SSL not issued for the live hostname on the destination, or CDN origin still aimed at the old server
  7. 07 Rewrite rules, nginx config, or permalinks not rebuilt for Apache vs nginx differences
  8. 08 File ownership/permissions blocking the web user from reading the migrated tree

What changed before the problem started

  • Files and/or database copied to a new hosting account or VPS
  • DNS A/AAAA, CNAME, or nameserver change toward the new host
  • Temporary URL testing followed by production domain cutover
  • SSL certificate installed or CDN proxy enabled on the destination
  • PHP version or handler selected differently than on the old host
  • Migration plugin, host mover, or manual SFTP/SQL used for the transfer

Troubleshooting steps

  1. 01

    Prove which host the public actually hits

    From your machine and a public DNS checker, resolve the live domain and compare the IP to the old vs new host. If the public IP is still the old server, the “new host broken” report is a DNS cutover problem, not an app bug. Success signal: you know whether visitors reach old IP, new IP, or a CDN.

  2. 02

    Keep the old host online as the rollback

    Do not cancel or wipe the source account until the destination passes full checks on a temp URL and after cutover. Export a fresh backup from the old host if you have not already. Success signal: you can still load the known-good site and restore from a dated archive.

  3. 03

    Test the destination on temporary URL or hosts file

    Use the host’s temporary hostname or a local hosts-file override to the new IP so you can debug without depending on public DNS. Note exact errors (connection, blank, 403, redirect). Success signal: you can reproduce the failure on the new stack alone.

  4. 04

    Match app config to the new database and paths

    Confirm the database exists with expected tables and that connection settings in wp-config, .env, or CMS config match the new panel exactly (host is often localhost or a remote hostname). Re-import SQL if tables are missing. Success signal: the app connects and no longer shows a DB error on the temp URL.

  5. 05

    Verify document root and file completeness

    Compare folder sizes (especially media/uploads and large vendor trees) between old and new. Confirm the domain’s document root points at the folder that contains the real index. Fix permissions so the web user can read files. Success signal: static assets return 200 on the temp hostname.

  6. 06

    Align runtime, then cut DNS and SSL deliberately

    Set PHP (or stack runtime) close to the old host’s working version, enable required extensions, regenerate rewrites/permalinks, install SSL on the destination hostname, then update DNS with a plan to roll back A records if needed. Success signal: temp URL is healthy before public DNS changes.

When to stop troubleshooting

Hand off for migration rescue when you cannot get a clean temp-URL build after matching DB and files, when ecommerce or membership data must stay live during cutover, when DNS/registrar access is locked, when the destination cannot run required runtimes, or when serialized/builder content is widely corrupted. Bring both host panel access, DNS screenshots, and the exact temp-URL error.

Information to collect before requesting help

  • 01 Old and new hosting providers, plans, and whether the old site still loads
  • 02 How the move was done (plugin, host mover, SFTP + SQL, other CMS tools)
  • 03 Temporary URL test result vs live domain behavior
  • 04 Public DNS resolution (A/AAAA) vs new host IP
  • 05 Exact error text, HTTP status, or blank-page screenshot on the new host
  • 06 PHP or runtime versions on old vs new; required extensions if known
  • 07 Whether database tables exist on the destination and config credentials were updated
  • 08 CDN/Cloudflare status and SSL mode if a proxy is in use

How a professional repairs the problem

We treat this as a controlled hosting move: keep the old host as rollback, rebuild a verified destination on a temporary hostname (files, database, runtime, docroot, rewrites), fix URL and SSL layers without guessing, then cut DNS with measured TTL and origin checks. Post-cutover we purge caches, verify media and forms, and only then recommend retiring the old account — the commercial path is a migration rescue / hosting move, not a vague “speed plugin” detour.

Frequently asked questions

Why does the old host still work if I already “migrated”? +
Migration copies data; it does not automatically remove the old site. Until DNS points elsewhere, visitors (and you) may still hit the working source. That is useful for rollback — leave it up until the new host is proven.
The new host temp URL works — why is the live domain broken? +
Usually DNS still points at the old IP, SSL is missing for the live name on the new stack, or app URLs still encode the temp hostname. Fix DNS and hostname config together after the temp URL is solid.
Is this always a WordPress problem? +
No. Any site can fail a host move for docroot, files, database, runtime, or DNS reasons. WordPress adds wp-config and URL-replace pitfalls, but the comparison method is the same for other stacks.
Should I delete the old hosting account to “force” the new one? +
No. Deleting the source removes your rollback and can take email or forgotten subdomains with it. Prove the destination first, then cancel on purpose.
Can PHP version alone explain “works on old, fails on new”? +
Yes. A site stable on PHP 8.1 can fatal on 8.3 or on an older 7.x image missing extensions. Match a known-good version on the destination before rewriting application code.
Do I need a full migration rescue or can I fix one setting? +
If only DNS or SSL is wrong and the temp URL is healthy, a focused cutover fix may be enough. If files, database, and runtime are all uncertain, a structured migration rescue saves time versus random panel toggles.

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.