Published 17 October 2026
A website migration is not finished just because the new copy loads on your screen. DNS caches can send different visitors to different servers for a time, and overlooked files, email settings or crawler blocks can cause problems after the switch. Before cancelling old hosting, confirm that the new site works for visitors, receives mail as expected and can be crawled.
This checklist is for infrastructure moves where the site keeps the same public URLs. If you are also changing the domain or URL paths, you have a URL migration too, and need to plan redirects and Search Console steps separately. Google distinguishes these two types of move in its guidance.
First, confirm what is moving
Write down which services depend on the old account: website files, databases, mailboxes, scheduled tasks, subdomains, forms, SSL certificates, DNS and backups. A site may load correctly while a contact form still sends through an old mail server or a scheduled task still runs only on the previous account.
- Keep the URLs stable if this is only a hosting change. Avoid combining a server move with a redesign, CMS change or URL restructure unless necessary.
- Record the current DNS configuration, including nameservers, A and AAAA records, MX records and relevant TXT records. Confirm which provider controls the authoritative DNS zone.
- Preserve a rollback route. Keep access to the old hosting and a known-good backup while you verify the new copy.
Lowering DNS TTL well ahead of a planned move can help caches refresh sooner, but it does not make every resolver update simultaneously. Google recommends monitoring both old and new hosting rather than assuming the change is instant.
Test the new site before and after the DNS switch
Before changing DNS, test the new copy using a safe preview method supplied by your host or developer. Check representative pages, not just the home page: product and checkout pages for a shop, forms and downloads for a service site, and login or account areas where relevant. Confirm that the database has current content and that images, CSS and JavaScript load correctly.
- Check important URLs. Open a list of key pages on mobile and desktop. Look for broken links, missing media, error messages, unexpected redirects and mixed-content warnings.
- Test business functions. Submit a contact form, place a test order if appropriate, check account login, and review any integrations. Use a safe test mode for payment providers.
- Check SSL and canonical host behaviour. Confirm HTTPS works for the intended hostname and that HTTP or alternate hostnames redirect as intended. Do not assume a certificate covers every subdomain.
- Review temporary blocks. Remove staging-only password protection, robots.txt disallow rules, noindex tags or HTTP headers that should not remain on the live site.
- Verify Search Console access. Retain the verification file or tag if the site uses one, then inspect key live URLs after launch to check that Google can fetch them.
Google notes that a temporary change in crawl rate can occur after a hosting move. Judge the migration by whether the new server responds reliably and serves the expected pages, not by a brief crawl fluctuation alone.
Do not forget email and background jobs
Website files and email are separate services, even when both used the same hosting account. If mailboxes remain with the old provider, preserve the existing MX records. If mail is moving, plan mailbox data transfer and update DNS only after confirming the destination service and its required records.
- Send a message from the domain to an external mailbox and reply to it. Check both delivery and the ability to receive replies.
- Inspect SPF and DKIM records for the actual services authorised to send mail. Add or review DMARC only with a clear understanding of the policy; a restrictive policy can affect legitimate messages if authentication is not aligned.
- Check application mail separately. A working mailbox does not prove that website forms or order notifications are configured correctly.
- Recreate scheduled tasks, webhook destinations, API allowlists and server-side integrations that depended on the old environment.
In cPanel, Email Deliverability can help identify SPF and DKIM record issues when the feature is available, but DNS changes must be made where the domain’s authoritative nameservers are managed. If a third-party mail provider sends your messages, use that provider’s instructions rather than blindly copying hosting-server suggestions.
Monitor both servers before cancelling
After the DNS change, keep the old account active while caches update. Check the site from different networks and use DNS lookup tools to see whether the domain resolves to the expected destination. Review both providers’ access logs if available: old-server requests should decline while requests reach the new server. Google specifically recommends watching traffic and logs on both sides of an infrastructure move.
Do not cancel the previous hosting account just because your own browser reaches the new site. First establish that visitors, mail and important automated processes no longer depend on it.
Use this final sign-off list:
- Key pages, forms, checkout and SSL pass checks on the new service.
- DNS records are correct at the authoritative DNS provider, including mail records where relevant.
- Search Console verification remains available, and live URL inspection does not reveal an accidental block.
- Backups exist and can be accessed independently of the account being cancelled.
- Old-server logs show no meaningful remaining traffic or essential activity; allow time for normal DNS caching and business cycles before deciding.
When to ask for migration help
For a small brochure site, the checks may be manageable for its owner. A store with orders, a membership site, or an agency managing client email and scheduled integrations has more to coordinate. HostCupid, a Chennai-based provider offering shared and WordPress hosting, website migration assistance and website development, is relevant when an owner needs help planning the transfer and checking the destination. Ask any migration provider to clarify what is included, how mail and DNS will be handled, and what access or testing they need; do not assume these details are identical across providers.
Keep the old hosting until the evidence supports closure. That simple discipline helps protect continuity for customers and gives you a practical chance to resolve overlooked dependencies before the previous account disappears.
Sources
- Changing Your Web Hosting and SEO
- Email Deliverability in cPanel · 2026-07-08
- Site Moves and Migrations
