What to check after a migration

It is tempting to treat the DNS switch as the finish line of a migration. In practice it is closer to the halfway point. Files copied cleanly, the database imported without errors, testing on the new server passed — and then DNS changes, and a slightly different set of problems becomes possible: the ones that only show up under real traffic, from real visitors, spread across a period of days rather than a single test session.

Keep the old hosting running

This is the first and most important thing to get right, and it has nothing to do with how the migration went. DNS does not update everywhere the instant you change it — some networks pick up the new records within minutes, others take hours, and a small number of resolvers hold onto old answers longer than they are supposed to. For roughly a week, both the old and new hosting are effectively live at once, from different visitors' point of view.

Watch for the things a test session cannot catch

• Forms that stop sending. A contact form can look identical and still fail silently if an SMTP setting or a script dependency did not carry across cleanly. Submit a real test message a day or two after the switch, not just once during pre-launch testing.
• Cron jobs and scheduled tasks. These do not travel with a file copy and have to be recreated on the new host. A missed one often shows up days later as "why didn't the newsletter go out" rather than as an obvious error.
• Email arriving at the wrong place. If mail routes through the domain's MX records, some messages may still land on the old server for as long as its DNS records are cached somewhere. Check both mailboxes for a few days.
• Broken images or missing styling on pages that were not part of the original test pass — a large site is rarely tested page by page, and a folder missed in the copy sometimes only turns up once someone visits that specific page.

Check search engine visibility

Changing host does not itself affect search rankings, because the URLs have not changed — see will changing host hurt my search rankings for the full explanation. What is worth checking in the days after a move:

• A sample of pages return a normal 200 response rather than an error, using your browser's developer tools or an online HTTP status checker.
• No page unexpectedly redirects somewhere it should not.
• Search Console (if you use it) is not reporting a sudden spike in crawl errors.

A short-lived dip in crawl activity immediately after a host change is normal and not a sign of a ranking problem — search engines simply notice the server changed and re-verify a few things. It should settle within days, not weeks.

Check email deliverability, not just email arriving

Beyond confirming mail arrives, check that outgoing mail is not landing in recipients' spam folders. If SPF, DKIM or DMARC records referenced the old server in any way, or if the new server sends mail through a different route, deliverability can dip briefly until authentication settles. This is separate from the migration itself but often surfaces around the same time, simply because it is the point when anyone is paying close attention to email.

Confirm SSL is working properly

Most hosts issue a free SSL certificate automatically once DNS points at them, but this can take a short while after the switch. Check the site loads over HTTPS without a browser warning, and that no page is loading any resource — an image, a script — over plain HTTP, which produces a mixed-content warning even when the certificate itself is fine.

When it is genuinely safe to close the old account

After roughly a week with no stray traffic, no misdirected email, and no forms failing, take one final backup of the old hosting account and only then cancel it. That backup costs nothing to keep and is the one piece of insurance against discovering, weeks later, that something was missed.

Keeping a record of what you checked

Note down the date DNS switched, the date you confirmed each item above, and the date you finally closed the old account. If a question ever comes up later — a customer disputing whether an order went through, a search engine ranking query, an argument about when email started arriving somewhere new — having an actual timeline is far more useful than trying to remember it after the fact. This does not need to be formal; a few dated lines in a notes file are enough.