Moving DNS away from HostGator can be completed without interrupting email or temporary website redirects, but every existing record and hostname must be reviewed carefully. In this case, DNS management was transferred to Cloudflare, Microsoft 365-related records were preserved, and a temporary redirect was recreated at the Cloudflare edge. A follow-up update added the www hostname so both the root domain and www redirected consistently.
Issue background
A domain was using HostGator nameservers even though the organization wanted to cancel its HostGator account. The domain did not currently serve a full website. Instead, both visitors and search traffic needed to reach a temporary external landing page while a replacement WordPress site was being developed.
The DNS zone also contained records for services beyond the website, including:
- Microsoft 365 email routing
- Autodiscover
- DKIM selectors
- SPF
- DMARC
- Domain-verification TXT records
- Legacy HostGator and cPanel hostnames
The challenge was to move authoritative DNS to Cloudflare, preserve any active services, and ensure that the temporary redirect no longer depended on HostGator.
Diagnosis
The HostGator zone contained a mixture of current and legacy records. Several A records pointed to a HostGator server for hostnames such as mail, web disk, WHM, and the root domain. The zone also included Microsoft 365 MX, Autodiscover, DKIM, SPF, and verification records.
Because the available HostGator access was delegated rather than full account access, it was not possible to confirm every service attached to the account. The account owner therefore needed to verify whether any hosting, email, file, or cPanel service still depended on HostGator before cancellation.
After the nameservers were changed, the existing redirect appeared to continue working even before the new Cloudflare rule was added. That behavior could have been influenced by DNS propagation, browser caching, or redirect caching. It was not sufficient proof that the redirect no longer depended on the old environment.
A later test found that the apex domain redirected correctly while the www hostname did not. The Cloudflare configuration needed to cover both hostnames explicitly.
Resolution steps
- Export the existing DNS zone. Record every A, AAAA, CNAME, MX, TXT, and SRV entry before changing nameservers.
- Classify each record by service. Separate website, email, verification, cPanel, FTP, and legacy hosting records so required services are not removed accidentally.
- Confirm email routing. Preserve the Microsoft 365 MX record, Autodiscover CNAME, DKIM selectors, SPF policy, DMARC policy, and any required verification records.
- Ask the account owner about hidden services. Delegated hosting access may not reveal every paid service or dependency. Confirm whether webmail, backups, FTP, databases, or other tools are still in use.
- Create the Cloudflare zone. Add the domain to Cloudflare and reproduce all records that are still required.
- Review proxy status carefully. Email-related records should remain DNS-only. Proxy only web hostnames that are compatible with Cloudflare.
- Update the registrar nameservers. Replace the HostGator nameservers with the nameservers assigned by Cloudflare.
- Verify authoritative DNS. Use WHOIS and DNS lookup tools to confirm that the domain is now using Cloudflare nameservers.
- Create the redirect at Cloudflare. Add a Redirect Rule that sends visitors to the temporary external landing page. This removes the redirect’s dependency on the HostGator server.
- Cover both apex and
www. Ensure that the rule matches bothexample.comandwww.example.com, or create separate rules when needed. - Confirm that both hostnames resolve in Cloudflare. A redirect rule cannot run for a hostname that lacks the required Cloudflare DNS record.
- Test with clean sessions. Check the redirect in private browsing, from multiple networks, and with command-line tools to avoid relying on cached browser behavior.
- Allow for propagation and redirect caching. DNS and edge changes may appear inconsistent temporarily. Recheck after the relevant TTL and cache periods.
- Test email independently. Send inbound and outbound messages and confirm that SPF, DKIM, and DMARC continue working after the nameserver change.
- Cancel HostGator only after verification. Confirm that the root domain,
www, email, and any remaining services function without the old hosting account.
Do not remove legacy-looking records until their purpose is understood. A hostname such as mail, autodiscover, or a domain-verification TXT record may still support an active external service even when the website itself no longer uses the old host.
Final outcome
The domain’s authoritative nameservers were moved from HostGator to Cloudflare, and the required DNS records were recreated in the new zone. A Cloudflare Redirect Rule replaced the temporary redirect that had previously been associated with the HostGator environment.
The first rule handled the root domain successfully. After follow-up testing identified that www did not redirect, the configuration was updated to include that hostname. Both versions of the domain then redirected correctly to the temporary landing page.
The remaining limitation was account visibility: delegated HostGator access could not prove that no other services existed. The account owner still needed to review the full HostGator account before cancellation.
The key lesson is that a DNS migration is more than changing nameservers. Existing records, email authentication, redirects, hostname variants, proxy settings, and hidden hosting dependencies all need to be verified before the old account is closed.
For help migrating DNS to Cloudflare, preserving email records, or rebuilding domain redirects safely, contact Freshy.
