Troubleshooting guide · migration-hosting · Published 2026-08-16 · 3 min read
Migrating without a plan, the risk signs
Warning signs that a site migration lacks a plan, from no backup test to a missing redirect map, and how to make the move safe.
- ·Why moves fail
- ·Read the warning signs
- ·Recover into a plan
A migration is a set of ordered, reversible steps: back up, copy files and data, stage, validate, then cut over and roll back if needed. When teams skip that order, the same handful of failures repeat. The risk signs are visible before cutover, and catching them early is the cheapest fix you will get, because an unplanned move fails at the point of least preparation.
Why unplanned moves fail
Most migration outages are not server failures. They are planning failures that appear as a few recurring symptoms:
- files or database moved but never tested together,
- no tested restore, so a bad copy cannot be undone,
- redirects forgotten, so URL and SEO weight is lost,
- DNS cut over before the new host is ready,
- a config (PHP version, environment values, permissions) that only works on the old box.
Handled in the right order each is small. Handled out of order, one compounds the next until the site is down and the old host is already released.
Read the warning signs
Check these before you touch cutover. Each one present is a reason to stop and plan:
| Warning sign | What it means |
|---|---|
| No tested backup | A restore attempt has never succeeded, or a backup was never made |
| No record of email, cron, subdomains | Items outside the site folder will be lost at panel freeze |
| No redirect map | Old URLs will 404 and existing rankings drop |
| DNS not TTL-reduced | The cutover propagates slowly and the site flutters |
| Database refreshed only once | Stale data overwrites new content made before cutover |
| No rollback decision | There is no defined earlier state to return to |
The host migration checklist is the ordered reference these signs protect against, and the rollback plan article covers the escape hatch every move needs before it starts.
Recover into a plan
If you are mid-flight on an unplanned move, do not push through; turn it into a controlled one:
- Stop the DNS cutover until the basic gates pass. The domain is the only user-visible switch, and it is the last step, not the first.
- Make and test a restore on the destination host, from the exact backup you will rely on. A failed test now is far cheaper than a failed production restore.
- Write the URL change list. Diff the old and new URL sets and map every moved or removed URL to a 301, per the URL migration planning guidance.
- Fix a single signed-off runtime on the new host (PHP, permissions, environment values) and verify the site and admin both work there before switching DNS.
- Reduce DNS TTL early so the final flip propagates in minutes rather than days, then schedule the cutover for a low-traffic window.
The moment it goes wrong anyway
If the site is already down after an unplanned cutover, first undo to the known-good state instead of debugging forward under pressure: reactivate the old host or restore the last tested backup. Only when the site returns should you diagnose what the move missed. The site not loading guide orders that diagnostic, and the rollback plan defines exactly how to define and rewind a bad move.
The pattern to internalise: a migration fails at cutover only when the person responsible has never tested the new host in isolation and has no reversible fallback. Plan the reverse path before you plan the forward one, and the unplanned move stops being risky.