Hosting Migration Checklist — 6 Things to Check So Your Site Never Goes Down

A hosting migration sounds like simply "copying files from one place to another." But sites that go down after a move, email that disappears for hours, or half your customers still seeing the old site — they all come from the same cause: nobody checked the settings before the move, and once it was done there was nothing to compare against. This article covers the 6 things to check before, during and after a migration so your site never skips a beat.

Why hosting migrations usually break

Most problems aren't in the website files or database — they're in the surrounding configuration people forget: the many existing DNS records, the email MX record, the SSL certificate, and the TTL value that makes changes slow to take effect. When you move only the files without moving all of these, the site ends up "half-and-half" — some visitors see the new site, others are still stuck on the old one.

The 6 things to check in a hosting migration

1 — Record every DNS entry on the old host

Before touching anything, open the DNS panel on your old host and write every record down to a file — A, AAAA, CNAME, MX, TXT (including SPF/DKIM), plus SRV and CAA if present. The most commonly missed items are small subdomains and TXT records used to verify other services. Miss one and email or some service can stop working.

2 — Check MX records and email carefully

Email is the part that breaks most silently. If the old host also stored your mail, decide whether to migrate it too or use a separate provider. Record every MX entry, its priority, and the TXT records (SPF/DKIM/DMARC). Missing a single SPF line will send every post-migration email straight to spam.

3 — Set up SSL on the new host before switching DNS

Install SSL on the new host before pointing DNS at it. If you switch DNS first and issue SSL afterwards, visitors in the gap will hit a "Not secure" warning. Most modern hosts issue Let's Encrypt automatically, but you should always confirm it succeeded first.

4 — Check WHOIS, nameservers and TTL

Check WHOIS to confirm the domain isn't near expiry during the migration window, and note which nameservers are in use. Then lower the TTL of important records to 300 seconds (5 minutes) at least 24–48 hours before the actual move, so DNS changes take effect quickly.

5 — Check DNS propagation after the switch

After pointing DNS at the new host, don't assume you're done. DNS propagation takes anywhere from a few minutes to several hours. Check from multiple locations that the world sees the new IP consistently before shutting down the old host.

6 — Compare before vs after, then retire the old host

The most overlooked step — confirm that every record on the new host matches what you recorded from the old one: DNS, MX, SSL. Don't cancel the old plan until at least 3–7 days have passed and you've confirmed everything works normally.

Preparing Files and Database Before the Migration

Beyond DNS and mail records, your website files and database are the core of any migration. Following the right order matters:

Take a full backup before you start

Back up everything from the old host in one pass: all website files (HTML, CSS, JS, PHP, images, uploads) and every MySQL/MariaDB database. If you're on DirectAdmin, the built-in Backup feature exports everything as a .tar.gz archive in a single click.

Test the new host via your hosts file before switching DNS

After uploading files and restoring the database on the new host, do not switch DNS yet — test the site first by temporarily editing your local hosts file to point your browser to the new server's IP:

# Windows: C:\Windows\System32\drivers\etc\hosts
# macOS / Linux: /etc/hosts
# Add this line (replace with the real IP of your new host)
1.2.3.4   yourdomain.com
1.2.3.4   www.yourdomain.com

Browse the site and confirm every page loads correctly, images appear, forms submit, and the SSL lock is green. Once verified, remove the hosts file entry and proceed with the real DNS switch.

Configuration files that commonly need updating

Handling SSL During a Hosting Migration

SSL certificates are tied to the server, not the domain — you always need to issue a new certificate on the destination host. Plan this carefully so users never see a "Not Secure" warning:

Let's Encrypt vs Paid Certificate when migrating

Let's Encrypt (free) is issued automatically on most modern hosts including AsiaGB, but it requires DNS to point to the server first. A Paid SSL certificate can be validated with DNS-01 Challenge without pointing DNS first, letting you install SSL on the new host before you migrate:

• Using Let's Encrypt: set up the new host → switch DNS → SSL is issued automatically within minutes
• Using Paid SSL: complete DNS validation on your current DNS → cert issued → install on new host → then migrate DNS

Check SSL expiry before you migrate

If your current certificate expires within 30 days, renew or reissue it before the migration so you don't have to juggle two tasks at once. You can check SSL expiry free at dnsxray.com/ssl.

Post-Migration Checklist — What to Verify After DNS Propagation

Once DNS propagation is complete and all visitors are hitting the new host, run through this checklist before calling the migration done:

Common Migration Mistakes and How to Fix Them

Based on hundreds of migration assists, these are the most frequent issues and how to resolve them:

1. Mixed Content Warning after the move

The site shows an incomplete or broken SSL padlock because some images or scripts still use http:// instead of https://. Fix this by searching your database (WordPress users can use the Better Search Replace plugin) or inspect the browser DevTools Console tab for mixed-content errors.

2. Outbound email lands in Spam

The main cause is an SPF record that still lists the old host's IP. Update the TXT record for SPF to include the new server, then verify DKIM is properly set up and DMARC is configured. Use dnsxray.com/mailtest to check your domain's email authentication.

3. Database connection error

WordPress or another CMS shows "Error Establishing a Database Connection" — this almost always means the database credentials in your config file haven't been updated. Edit wp-config.php or the equivalent config file with the new host's DB hostname, username, and password.

A tool to compare settings before and after

Recording records by hand one at a time risks omissions. A faster, more reliable way is a centralized domain health tool — run it before the move once to capture the full picture of the old settings, then run it after to compare.

For example, dnsxray.com is a domain health tool that shows DNS, mail servers, SSL and WHOIS in a single lookup, with a save-as-PDF feature — perfect for keeping a "snapshot" of your domain settings before a move to compare against afterwards.

The checklist in short

Phase	What to do
48 hrs before	Record/check all DNS, MX, SSL, WHOIS · lower TTL to 300
Before switching DNS	Get site + database + SSL ready on the new host
At migration	Switch DNS / nameservers to point at the new host
0–48 hrs after	Check propagation · compare before/after · test email
3–7 days after	Confirm all is well → restore TTL → retire the old host

Frequently asked questions

Q: Will my site go down during a hosting migration?

If you do it in the right order — prepare the new host before switching DNS — the site barely goes down at all. Visitors are always routed to one server or the other that has the site. Problems happen when you switch DNS before the new host is ready.

Q: How long does DNS propagation take?

Usually minutes to a few hours if you lowered the TTL ahead of time, but in theory up to 24–48 hours — so don't shut down the old host immediately.

Q: What extra is needed to migrate email too?

You need to move the old mailboxes (e.g. via IMAP sync) and set up MX/SPF/DKIM completely on the new system. Always test by sending mail in and out after the move.

Q: Does AsiaGB migrate sites for me?

Yes — AsiaGB offers free site migration for new customers. The team checks DNS, MX and SSL fully and tests before the real switchover.