DNS now reaches the new server, but visitors see mixed redirects, missing images, and intermittent 500 errors. wp-admin opens only through the host's temporary URL, while checkout callbacks continue arriving at the old environment.
This guide shows how to determine which server is answering, isolate the first failed layer, and decide whether to repair the new environment or send traffic back to the old one.
What “broken after migration” means
A migrated site is broken when its copied WordPress data and the new hosting environment no longer agree. The fault may occur before WordPress, in DNS or TLS; inside WordPress, in configuration, stored URLs, files, or the database; or around WordPress, in caches, mail, cron, webhooks, and external storage.
- Identify the server that produced each response before interpreting redirects or error logs.
- Treat the public site, administration area, background jobs, and external callbacks as separate test paths.
- Decide which host is allowed to accept new data while troubleshooting continues.
A realistic WordPress example
A customer on mobile data reaches the new server and receives a valid certificate, but product images still point to an old uploads path. An administrator on the office network follows a cached redirect to the former host, and the payment provider continues sending webhooks there. These are not one intermittent WordPress error: they are a media-path problem, a cached routing problem, and an external callback that was never updated.
Why it matters and when to use it
Begin diagnosis as soon as visitors reach a host that cannot serve a critical path, or when orders, accounts, or form submissions are being written to both environments. A cosmetic problem can often be repaired in place; split writes require an immediate choice of the authoritative server. If the new host cannot be stabilized within the cutover window, route traffic back before the two databases diverge further.
A straightforward route for beginners
- Preserve the new server logs and configuration, confirm the responding IP and certificate, and compare with the old host before clearing evidence.
- Check home and siteurl, wp-config.php, database credentials, table prefix, rewrite rules, and the active document root against the migration record.
- Use a serialization-aware tool for required URL changes, regenerate permalinks through supported controls, and purge only relevant cache layers afterward.
- Correct the first evidenced fault and retest from a clean client; do not combine DNS, database, permissions, and plugin changes in one trial.
- Test from more than one network and verify pages, media, wp-admin, login, REST, cron, email, forms, payments, webhooks, search, and redirects.
The advanced route
Resolve the domain through more than one public resolver and record the IP, certificate, response headers, and redirect chain. Correlate each failing request with the new server's web and PHP logs. Compare PHP versions and extensions, filesystem ownership, case sensitivity, proxy headers, object-cache configuration, and cron execution with the source host.
- Enable WordPress debugging only long enough to capture the fault; keep logs outside public access and disable on-screen errors afterward.
- For a changed domain or path, use a serialization-aware WordPress replacement tool and check both core and plugin-managed values.
- Test webhooks and scheduled jobs in a way that prevents the old and new hosts from processing the same event.
Risks, common mistakes, backup, and rollback
- Purging every cache can hide which layer supplied the bad response; identify the responding host first.
- Changing DNS, database credentials, permissions, and plugins together makes a successful fix impossible to attribute.
- Do not enable live mail, cron, or payment callbacks on both environments during diagnosis.
- Keep the pre-migration package and the old host intact until the new site passes acceptance tests.
Rollback is safe only while one environment remains authoritative. If the new site has already accepted unique orders or accounts, preserve them and plan reconciliation before returning traffic to the old host.
How AIOWS helps
AIOWS Backup Manager
AIOWS Backup Manager can keep the verified pre-migration package available while the destination is diagnosed. Use that package to compare the expected files and database with the new host, or to restore the affected WordPress layer when the migrated copy is incomplete.
The module does not control DNS, certificates, server permissions, mail routing, or third-party callbacks. Those checks remain part of the hosting cutover. After any supported restore, verify the same visitor, administrator, media, cron, and transaction paths that exposed the problem.
Do not replace the last known-good package until the corrected site has passed its observation period. If rollback is required, the preserved package and old environment provide the recovery point; any data accepted by the new host must be handled separately.
Related AIOWS articles
- WordPress Migration: Move a Site to a New Host Safely
- WordPress Migration Checklist: Before and After Moving
- Change WordPress URLs After Migration: Safe Guide
Conclusion and recommended route
Identify which server answered and which boundary failed before changing anything else. Repair one evidenced layer, retest the corresponding user path, and continue outward through integrations. If the cutover window expires, use the pre-agreed routing rollback rather than leaving visitors and new data divided between two environments.
