10 checks before shutting down old hosting after migration

Your site has moved, the new hosting is responding, and now comes the question nobody wants to get wrong: when can you shut down the old server without leaving someone stranded—a client, a search engine, a forgotten cron job? Powering down too early means lost emails and 404 pages for months. Keeping it running too long only costs a monthly fee, but it has to come off eventually. Here's the checklist to follow in order, as of 1 November 2026.

1. DNS: don't just check if it resolves, check the TTL

It's not enough that dig dominio.it +short returns the new IP on your machine: you need to know how much time remains before all resolvers worldwide have discarded the old one. To check the TTL of an existing record use dig: dig dominio.it A +noall +answer, where the returned number is the remaining TTL in seconds. On Windows you get the same information with nslookup using the -debug option to see the verbose output containing TTL values. Until that number has dropped to the low value set before the migration (ideally 300 seconds or less, lowered a few days before the move), some resolver somewhere in the world is still serving the old IP.

2. Email: check the old MX logs, not just the inbox

If the MX records still point to the old server, emails arrive there. Verify with dig dominio.it MX +short and compare the destination IP.

3. Valid SSL certificate on the new server

Check expiry and chain with openssl s_client -connect dominio.it:443 -servername dominio.it.

4. 301 redirects active and working

Test with curl -I https://dominio.it/pagina and verify the status code and Location header.

5. Google Search Console free of new crawl errors

In the Pages section of the new property check for 404, 5xx and redirect errors: information about crawl errors and warnings is found in the Pages section of Google Search Console, and in some cases, such as a 404 or 5xx error, Google was unable to crawl and will likely remove the page from results.

6. Cron jobs and backups re-enabled on the new environment

Verify with crontab -l that jobs aren't still running on the old server in parallel, generating data against two different databases.

7. Contact forms tested end-to-end

Sending isn't enough: verify that the email actually arrives, doesn't end up in spam because of outdated SPF.

8. CDN pointed to new origin

Check the origin server configuration in the CDN control panel, not just the public CNAME.

9. Sitemap updated and submitted

Regenerate sitemap.xml with current URLs and resubmit from Google Search Console.

10. Old server logs: the final check before shutdown

This is the point that really decides it. Analyse the access logs of the old hosting for 7–14 consecutive days: if requests still appear with real user-agents (not just bots), DNS hasn't fully propagated for someone yet.

One more option for domain changes

If the migration also involved a domain change, the Address Change tool in Google Search Console tells Google to intensify crawling of the new site and abandon the old one, forwards signals and suggests the new site as canonical—actions carried out within 180 days of starting the migration. Be careful not to disable redirects too early: removing 301 redirect instructions from the server prematurely means that on the next crawl, Google may continue following the old instructions, or lose the connection between the two sites. Only when all ten points have been verified, and the old hosting logs show no more human traffic, is shutdown safe.