Website Down or Broken After Switching Web Hosts? 9 Common Causes and Fast Fixes

You moved your website to a new host, DNS finished switching, and now something’s wrong — the homepage shows a database error, images are missing, the contact form stopped sending, or the site is just slower than it used to be. None of this means the migration failed. It means one of a handful of predictable things didn’t come across, and each one has a five-minute fix once you know where to look.

This is the troubleshooting list we work through with new customers in the first 48 hours after a move. If you haven’t migrated yet, read our 20-point migration checklist first — most of these problems don’t happen if the checklist was followed. This post is for when they happen anyway.

1. “Error establishing a database connection”

This is the single most common message after a move, and it almost always means the site’s files arrived but its database configuration still points at the old server. Open your site’s config file (wp-config.php for WordPress) and check the database name, username, password and host against what the new hosting account actually created — these four values rarely survive a copy unchanged, because most hosts generate a new database name and password automatically rather than letting you keep the old ones.

2. The homepage loads but every other page is a 404

This is a permalinks problem, not a missing-files problem. WordPress writes its URL rewrite rules into the server’s .htaccess file, and that file frequently doesn’t survive a plain file copy because some FTP clients and file managers hide dotfiles by default. Go to Settings → Permalinks in wp-admin and click Save — without changing anything — and WordPress will regenerate the file. If wp-admin itself won’t load, the same fix is one manual edit to .htaccess, which your host’s support can do in a minute.

3. Images, CSS or the whole layout is missing

Two different causes produce the same symptom. First: the wp-content/uploads folder is often the largest part of a site and gets skipped or times out during a rushed copy — check its size against the old server. Second: some sites hard-code the old domain or IP address into the database (common with older page builders and some caching plugins), so the browser is still requesting assets from a server that no longer serves them. A search-and-replace across the database, swapping the old URL for the new one, fixes the second case.

4. Mixed content warnings or “not secure” in the browser

If the padlock disappeared or Chrome shows “not fully secure,” the page is loading over HTTPS but pulling some images, scripts or stylesheets over plain HTTP — almost always because of the same hard-coded old URLs as above, saved with http:// instead of https://. Fixing the URLs also fixes this. If the whole site refuses HTTPS entirely, see point 6.

5. Email has stopped — sending or receiving

Mail is not part of your website files. It’s a separate service, and it moves on its own schedule. If you switched DNS before recreating mailboxes on the new server, incoming mail is being sent to a server with no matching account, and it will bounce until the mailbox exists there. Recreate every mailbox first, then confirm the MX record actually points at the new server (a WHOIS or DNS lookup tool will show you), and give it up to 48 hours to finish propagating everywhere. If sending fails but receiving works, check that the site’s contact form or app is using an SMTP username and password from the new server, not the old one.

6. SSL certificate errors (“your connection is not private”)

Certificates are issued per-server, not per-domain, so a certificate that worked perfectly on the old host does not automatically exist on the new one. Either reissue a free certificate (most hosts, including ours, do this automatically once DNS has fully switched) or install the existing one manually if it was purchased separately. See our guide on what an SSL certificate actually does if you’re not sure which situation applies, or check SSL certificate options.

7. Half the visitors see the new site, half still see the old one

This is normal, expected, and not a fault on either server — it’s DNS propagation. Different networks around the world cache your domain’s DNS records for different lengths of time, so for a window of a few hours (occasionally up to 48) different visitors are directed to different servers depending on which cached copy their network is using. We cover exactly why this happens in what is DNS propagation and why does it take 24 to 48 hours. The fix is patience, not troubleshooting — if it hasn’t resolved after 48 hours, then it’s worth checking the DNS records themselves for a mistake.

8. The site is noticeably slower than before

Check the PHP version first — if the new account defaulted to a different version than the site was built for, some caching or optimisation plugins quietly stop working rather than erroring loudly. Second, confirm any caching plugin was actually re-enabled and its cache rebuilt; a fresh server with no cache warmed up will feel slow for the first day regardless. Third, compare the hosting plan’s resource limits (RAM, CPU) against the old one — a downgrade in specification is the most common honest reason a “successful” migration ends up slower.

9. A contact form or payment gateway stopped working

Forms that rely on the server’s own mail function often fail silently on a new server with different mail settings — test with a real submission, not just loading the page. Payment gateways and some third-party APIs whitelist specific server IP addresses for security; if yours does, you’ll need to update that IP with the provider, which is easy to forget because it isn’t part of the website itself.

If none of this fixes it

Two things are worth checking before anything else: the server’s error log (your control panel has one, usually under “Errors” or “PHP Errors”) will usually name the exact file and line causing a blank page or fatal error, and your backup from before the move is your safety net — if step 19 of the checklist was followed and the old hosting is still live, you always have a working version to compare against or fall back to.

Frequently asked questions

How long should I wait before assuming something is actually broken?

Give DNS-related symptoms (inconsistent behaviour between devices or networks) a full 48 hours. Give everything else — database errors, missing images, broken forms — zero time. Those are configuration problems, not propagation, and they don’t fix themselves.

Is it normal for a migration to have any of these problems?

Minor ones, yes — permalinks and hard-coded URLs are common enough that we check for them on every migration we do. A well-prepared move using a proper checklist should not produce database errors or lost email, because those come from skipped steps, not bad luck.

Can a broken migration hurt my Google rankings?

Extended downtime or a long stretch of 404s and 500 errors can cost you crawl activity and, if it lasts, rankings. A same-day fix to any of the issues above is very unlikely to leave a lasting mark. Keep an eye on Search Console for a couple of weeks either way.

What should I have ready before I even start a migration, to avoid this?

A verified, downloaded backup of files, database and a list of every email account — covered in full in the migration checklist. Almost everything on this page traces back to one of those three being incomplete.

We fix these as part of every migration

When Salasar Hosting migrates a site for you, we test it on the new server before DNS switches — not after — which is exactly the step that catches most of the problems above before they ever reach a visitor. If you’re already mid-move and stuck on one of these, call +91 99620 05753 or send us your error message and we’ll tell you what’s actually wrong.