Information checked: 21 July 2026.
Hosting migrations usually fail at the boundaries between services: DNS, email, certificates, databases, scheduled jobs and third-party integrations. A copied set of website files is only one part of the move.
In brief: Most migration failures are dependency failures. Inventory and test every service that touches the website before cancelling the old host.
Problems that appear after a “successful” copy
| Symptom | Likely cause | First safe check |
|---|---|---|
| Old content still appears | DNS or CDN cache points to the old origin | Compare authoritative DNS and response headers |
| Forms stop arriving | Mail routing, SPF or application sender changed | Inspect form logs and destination mail logs |
| New orders are missing | Database changed during the copy window | Compare transaction records before final switch |
| HTTPS warning | Certificate or hostname coverage incomplete | Test every public hostname and redirect |
| Scheduled tasks stop | Cron or queue workers were not recreated | Compare the old and new job inventory |
| Search traffic drops | URLs, status codes or robots rules changed | Crawl old and new URL lists and inspect Search Console |
Protect changing data
Shops, bookings and membership sites need a defined content-freeze or final synchronisation. Do not restore an old database over a live service without reconciling changes made after the copy.
Keep the old service available briefly
Do not cancel the previous host immediately. Retain access long enough to compare logs, recover missed files and roll back safely. Prevent new traffic from reaching it, but do not destroy evidence during the validation period.
Close the migration properly
- Confirm DNS, HTTPS, email, forms, login, search, payments and scheduled tasks.
- Compare database counts and recent transactions.
- Run an external crawl and check important status codes.
- Update monitoring, backups and supplier records.
- Revoke temporary access and document the new recovery process.
- Cancel the old service only after the agreed validation window.
Escalation rule
Stop the migration when data is diverging, mail routing is uncertain or the rollback path is no longer clear. A controlled delay is cheaper than silently losing business records.
Example: the invisible email failure
The website appears correctly after a nameserver change, but the new DNS zone omitted DKIM and an old verification record. Staff receive mail, yet website notifications start landing in spam and a connected service stops working. A migration checklist must compare the entire old and new zone, not only A and MX records.
What the business should retain
- Pre-migration DNS export
- Application and scheduled-job inventory
- Final database synchronisation record
- Old-to-new environment comparison
- Signed acceptance and cancellation date
Sources and date checked
Technical and product information was checked against the following primary sources on 21 July 2026. Plans, interfaces and provider terms can change, so recheck them before purchase or migration.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.