To move a business website without disrupting email, first inventory every DNS record, test the new hosting environment, lower relevant DNS TTLs in advance, and change only the records that actually need to move. After cutover, verify the website, business mail, contact forms, SSL, redirects and search visibility from outside your own network. Do not assume that a working homepage means the migration is complete.
This domain and DNS migration checklist for 2026 is designed for business owners and developers using WordPress, Shopify, WooCommerce, React or Next.js. It is particularly useful for service businesses across Delhi NCR that depend on contact forms, staff email and local search enquiries. The goal is a controlled migration with a clear rollback path, not an unsupported promise of zero downtime.
Quick answer: How do I migrate a website without losing email?
- Export the current DNS zone and identify its authoritative nameservers.
- Document the website’s A, AAAA and CNAME records separately from email’s MX, SPF, DKIM and DMARC records.
- Prepare the new website, SSL certificate, forms, redirects and backups before editing public DNS.
- Lower the TTL for records you will change sufficiently early for old cached answers to expire.
- Prefer changing only the necessary web records when your email provider and DNS host are staying the same.
- Test web and mail services after cutover using external networks and real end-to-end submissions.
- Keep the old environment available for a defined rollback and monitoring period.
If your current problem is specifically that WordPress notifications land in spam, follow our separate WordPress email deliverability guide. That article diagnoses message authentication and inbox placement; this guide covers infrastructure and DNS cutover so the website and mail continue working when hosting or domain settings change.
What is the difference between a hosting migration and a domain migration?
A hosting migration moves a website to a different server or deployment platform while keeping the same public domain and URLs. In a simple case, only the website’s DNS target changes. A domain migration changes the public hostname, such as moving from an old company domain to a new one. That adds redirects, canonical changes, updated internal links and Search Console work. A DNS provider migration changes the authoritative nameservers, so the entire zone must be reproduced accurately at the new provider.
| Change | What typically moves | Primary risk |
|---|---|---|
| Hosting only | Web server, deployment, A/AAAA or CNAME target | Site or API downtime |
| DNS provider | Nameservers and complete DNS zone | Missing mail, verification or service records |
| Domain name | Public URLs, redirects, canonical, analytics, email identity as applicable | SEO and communication disruption |
| Email provider | Mailboxes, MX, authentication and client settings | Lost or delayed mail |
These changes are related but not interchangeable. Avoid moving the domain, redesigning the site and switching email providers in the same release unless a carefully tested plan requires it. Google’s site-migration guidance recommends limiting simultaneous changes where possible.
Know your DNS records before changing anything
DNS is a directory of services, not a single switch that controls only the website. A business domain can power its public site, inbound email, transactional mail, verification tokens, subdomains and third-party integrations at the same time.
| Record | Typical purpose | Cutover check |
|---|---|---|
| A / AAAA | Points a hostname to an IPv4 / IPv6 address | Confirm the new hosting target |
| CNAME | Aliases a hostname to another hostname | Check www, app, blog and vendor aliases |
| MX | Routes incoming email for a domain | Preserve the current mail service unless migrating it |
| TXT / SPF | Domain verification and authorized mail senders | Retain verified values and one valid SPF policy |
| DKIM | Publishes keys or selectors for signed email | Preserve every active sender’s selectors |
| DMARC | Defines domain-alignment policy and reporting | Keep the correct _dmarc record |
| CAA | Restricts certificate authorities allowed to issue certificates | Confirm the new SSL provider can issue certificates |
| NS / DS | Delegation and DNSSEC chain of trust | Coordinate carefully when changing DNS providers |
Do not copy example MX or DKIM values into production. Use the exact values issued for your domain by its provider. Microsoft’s Microsoft 365 DNS reference explains how MX, Autodiscover and SPF serve different purposes.
1. Create a complete pre-migration inventory
Before touching DNS, export or screenshot the entire current zone, including TTLs and priorities. Record the registrar, DNS host, website host, CDN, mail provider, transactional email provider, SSL setup, redirects and any active DNSSEC configuration. List all subdomains, not just the apex and www hostnames.
Include operational dependencies: contact forms, payment webhooks, order notifications, CRM APIs, staff mailboxes, calendar invitations, login emails, analytics, Search Console verification and domain ownership TXT records. For a WordPress site, back up the database and uploads. For Next.js or React, preserve environment variables, build settings, API endpoints and deployment rollback instructions. Keep secrets in a secure password manager, not in a public migration spreadsheet.
Assign a technical owner and a business owner. The business owner should know which lead forms and inboxes must work before the migration is considered successful. A practical website development plan treats the domain, backend, frontend and conversion journey as one system.
2. Lower DNS TTL in advance, not at the last minute
TTL, or time to live, controls how long recursive resolvers may cache a DNS answer. A shorter TTL can help planned changes be observed sooner, but it does not instantly clear records that were already cached at a longer TTL. Cloudflare’s official TTL documentation explains this behavior and notes that its proxied records use a managed automatic TTL.
For a scheduled cutover, inspect the existing TTL and reduce it in advance where the provider permits. If the old TTL was 24 hours, a change made only five minutes before migration cannot force every resolver to forget the old answer. After the new environment is stable, review whether the temporary lower TTL should return to your normal operational value. Nameserver delegation and DNSSEC have their own considerations.
3. Test the new hosting environment before public DNS changes
Deploy the site to its new server or platform and test using a staging hostname, preview URL or a controlled hosts-file override. Avoid publishing a public duplicate of the full production website without appropriate indexing controls. Check the homepage, important service pages, blog articles, images, API routes, mobile navigation, forms, checkout if applicable, and the real customer confirmation flow.
Verify that SSL can be issued for every required hostname. Check that the new host accepts the domain, redirects HTTP to HTTPS appropriately, and supports the required www or non-www preference. Confirm that contact-form entries reach their storage system even if the notification email is delayed. If the project uses a React frontend with WordPress as a CMS, test both the public React route and the backend content API independently.
Use our React, Next.js and WordPress indexing checklist to review server responses, canonicals, robots directives and rendered HTML before the move.
4. Choose the safest cutover method
When only the website host changes
Keep the current authoritative DNS provider and email records in place. Update only the A, AAAA or CNAME records that the new web host requires. Make sure an obsolete IPv6 AAAA record does not continue sending some visitors to the old server while IPv4 points to the new one. Confirm CDN proxy settings and origin certificates before the change.
When the DNS provider changes
Recreate and validate the full zone at the destination first. Compare record names, types, values, priorities, TTLs and proxy modes. Then change the nameserver delegation at the registrar. If DNSSEC is enabled, coordinate DS and signing-key changes according to the DNS providers’ migration instructions; a broken chain of trust can make the entire domain fail to resolve for validating resolvers.
When the public domain changes
Build a one-to-one URL map and implement server-side 301 or 308 redirects from old pages to their most relevant new pages. Update canonicals, sitemap URLs, internal links, hreflang where used, analytics settings and verified Search Console properties. Google’s official site-move guide recommends keeping redirects for at least a year and generally as long as possible. A new domain does not automatically inherit search visibility overnight.
5. Protect business email while DNS is changing
Changing a website’s hosting does not require changing MX records when mail remains with the same provider. If a DNS-zone transfer omits MX, email can be routed incorrectly even though the homepage works. Preserve the correct MX targets and priorities, Autodiscover records where relevant, SPF TXT policy, DKIM selectors and DMARC policy. Review vendor verification records for services that send invoices, OTPs or transactional notifications.
Test both directions: send from a staff mailbox to an external account and reply from that account to the business domain. Test the exact aliases and shared mailboxes used for enquiries. For Google Workspace, follow the official MX setup instructions; for Microsoft 365, use the domain-specific records shown in its admin center rather than generic placeholders.
If you are also migrating the email service, provision and test destination mailboxes before switching MX. Plan how old messages, contacts and calendars will be moved, and coordinate the cutover with the email administrator. An MX update does not itself migrate historical mail. Do not delete old mailboxes until delivery, data migration and retention requirements are checked.
6. Validate the website and lead journey after cutover
Use at least two independent networks or DNS resolvers to check the new records. Confirm the intended host responds over HTTPS, the certificate is valid, the site returns appropriate HTTP statuses, and the public homepage and key landing pages load correctly. A successful ping or DNS lookup does not prove the application is healthy.
Submit a real controlled test enquiry and verify its journey: accepted by the website, saved in the correct database or CRM, notification sent, notification received, and reply path working. Do not rely on a green thank-you screen alone. For staff response workflows, the separate speed-to-lead guide explains owner assignment and follow-up after a genuine enquiry is captured.
| Check | Pass condition | Failure signal |
|---|---|---|
| DNS | Correct authoritative answers for all active hostnames | Old IP or missing records |
| HTTPS | Valid certificate, no unexpected redirects | Certificate warning or loop |
| Application | Important pages and APIs return expected responses | 404, 5xx or broken assets |
| Inbound and outbound tests succeed | Rejected or misrouted messages | |
| Leads | Test enquiry stored and available to the team | Missing CRM entry or alert |
| SEO | Correct canonical, redirects, robots and sitemap | Old host, noindex or broken route |
7. Monitor and keep a rollback plan
For the first several days, watch uptime, 5xx errors, SSL renewal, DNS answers, mail delivery, form submissions and Search Console reports. Review old-host traffic to see whether users or services are still reaching it. Keep a documented rollback option, including old hosting access, backups, DNS values and a named decision-maker. A rollback is not simply changing one record if the new site has already accepted orders or form data; reconcile any new records before reversing.
For Delhi, Noida, Gurugram and Ghaziabad service businesses, test high-intent local landing pages and enquiry channels used by real customers. A migration that leaves the home page healthy but breaks the quote form or a city page can still damage operations. Ongoing website maintenance should include routine backups, monitoring and a documented recovery procedure.
Common DNS migration mistakes to avoid
- Changing nameservers when only one website A record needed updating.
- Copying the visible website records but forgetting MX, DKIM, verification TXT or DNSSEC settings.
- Assuming a shorter TTL clears answers already cached elsewhere.
- Leaving an old AAAA record active after updating the IPv4 address.
- Testing only the homepage instead of forms, APIs, payments and important pages.
- Changing public URLs without permanent redirects, updated canonicals and sitemap links.
- Removing old hosting or mailboxes before verifying data synchronization and delivery.
- Calling a migration complete before monitoring from external networks.
Frequently asked questions
Will changing website hosting stop my business email?
Not necessarily. If the authoritative DNS and email service remain unchanged and only web records move, email can continue normally. Mail can fail when MX or related records are accidentally changed or omitted.
How long does DNS propagation take in 2026?
There is no universal fixed duration. It depends on record TTLs, cached answers, resolver behavior, delegation and the type of change. Plan around the previous TTL, not only the new one.
Should I change nameservers or just the A record?
For a hosting-only move, changing the required web record at the existing DNS provider is often simpler. Change nameservers only when the authoritative DNS service itself must move.
Do I need to change MX records when moving WordPress hosting?
No, not if the mail provider is staying the same. Preserve the correct MX and authentication records. Verify actual mail delivery after the web migration.
Will a domain migration hurt SEO?
Search visibility can fluctuate while search engines process the new URLs. Accurate permanent redirects, canonical URLs, internal links, sitemaps and Search Console monitoring reduce avoidable problems but cannot guarantee unchanged rankings.
Can I move a Next.js frontend while keeping WordPress as the CMS?
Yes. Test the public frontend, CMS API, image URLs, caching and slug routes separately. Ensure the canonical and sitemap reference the intended public domain rather than the backend CMS host.
What should I test after a DNS cutover?
Check DNS answers, HTTPS, key pages, forms, CRM records, inbound and outbound mail, redirects, analytics and sitemap accessibility. Repeat checks from more than one network.
What if the website works but emails stop arriving?
Inspect the authoritative MX records, mailbox provider status, domain verification and mail logs. Compare against the saved DNS export. Do not randomly replace SPF or MX values without confirming the active provider.
Final takeaway: migrate services, not just a homepage
A successful DNS migration preserves the business processes behind the website. Prepare the new environment, inventory every record, make the smallest safe change, verify email and enquiries, and monitor the public URLs after cutover. If your business is planning a domain or hosting move, contact Keshav Enterprises with your current platform, DNS provider, email service and intended change so the migration scope can be assessed before production settings are touched.
