Quick answer: Nine out of ten migration problems fall into a short list: version mismatches, file permissions, hardcoded paths and IPs, missed cron jobs, DNS caching, SSL issued too late, database charset drift, forgotten email, and cancelling the old server too early. Each has a standard fix — find yours below.
Overview
This is the troubleshooting companion to the migration checklist: the recurring failure patterns we see in tickets, with the quickest diagnosis for each. Skim the bold lines; your symptom is probably here.
Before you start
- Know which stage failed: copy, test, cutover or post-switch — the fixes differ.
- Have logs handy: web server error log on the new machine answers most "site broken after move" cases.
Step-by-step guide
- Site renders wrong / 500 errors: check PHP or runtime version vs the old server; install missing extensions; read the error log, not the browser page.
- 403/permission errors: webroot owned by the wrong user after upload —
chown -Rto the web server user and re-check. - Redirect loops or wrong URLs: hardcoded domain/IP in app config or database; also check proxy-header settings if SSL terminates differently now.
- Half the visitors see the old site: DNS caching working as designed — wait out the TTL; never shut the old server down during propagation.
- Broken text encoding: database dumped/imported through mismatched charsets — redo the dump forcing utf8mb4 end to end.
- Scheduled things stopped: cron jobs and queue workers were not migrated — copy crontabs and systemd units, then verify with
crontab -l. - Mail vanished: MX switched before mailboxes moved, or SPF/PTR not updated — see email migration.
- Certificate warnings: SSL issued after cutover instead of before — issue on the new server while testing via hosts file.
Common issues
- Debugging on the wrong server: confirm which machine you are actually hitting (
dig +short, response headers) before touching anything. - Fixing symptoms in production: if the new server misbehaves badly, roll back first, fix calmly, re-cut later.
When to contact support
Send the failing URL, what stage you were at, and the last 50 lines of the relevant log — with those three things most migration tickets are resolved in one reply.
Frequently asked questions
The site worked before the move and shows 500 errors now — why?
Usually a PHP or runtime version difference or a missing extension on the new server. The web server error log names the exact cause; match versions first, then upgrade deliberately.
Why do some visitors still see the old website?
Their resolvers cached your old DNS records. It resolves itself as the TTL expires; keep the old server running until the traffic drains to avoid errors for them.
Text shows broken symbols after the database move — the fix?
A charset mismatch during dump or import. Redo the transfer forcing utf8mb4 on both export and import so Cyrillic text and emoji survive intact.
Related articles
Need a hand with your move? Contact Cloud2Y support →
