Project summary
A website change that could not be separated from DNS and email
A New Zealand small business was replacing its website. The new web platform needed a different root-domain setup, but the existing DNS arrangement could not support the intended configuration. The domain registration was to stay at GoDaddy, Cloudflare would become the authoritative DNS provider and Microsoft 365 email had to continue using the established records.
Problem and constraints
Change the website route without treating email as an afterthought
The migration had several owners and service boundaries. A nameserver change would affect every record in the zone, not only the website. The plan therefore separated DNS authority, website routing, email, verification records and account ownership into distinct checks.
Keep registration separate
The registrar, domain ownership, billing and renewal stayed at GoDaddy. This was a DNS-hosting migration, not a domain transfer.
Protect business email
Microsoft 365 MX, Autodiscover, SPF, DMARC and other sender or verification records had to match the recorded baseline.
Stage the website change
Cloudflare first became authoritative while the old website route remained available. The root website record changed only after the DNS zone passed its checks.
Keep recovery practical
The previous nameservers, old website route, change authority, decision points and validation tests were written down before the live cutover.
Generic architecture
Registration, DNS, website and email remained separate services
The diagram shows the general architecture. It is intentionally generic and contains no source screenshots or account information.
Migration method
A staged change with an acceptance test at each boundary
The work was designed so that one failed check would stop the next stage. That reduced the number of moving parts involved in any rollback decision.
Capture the live state
I recorded the authoritative nameservers, full DNS zone, website route, email records, service verification entries and account owners before making changes.
Prepare the target zone
I built the Cloudflare zone in the client-owned account and compared record type, name, value, priority, proxy state and purpose against the baseline.
Move DNS authority first
The GoDaddy nameservers were changed to the assigned Cloudflare pair while the previous website route remained in place. Public DNS and email were checked before continuing.
Connect the new website
After the new zone was authoritative and complete, the root website record was changed to the new platform. The www route, redirects and HTTPS were checked separately.
Test from outside
I compared authoritative and public resolver answers, checked the website over HTTPS and completed a Microsoft 365 send-and-reply test.
Complete the proving period
The accepted state was rechecked after an agreed proving period. Final notes recorded service ownership, remaining account actions, rollback status and handover.
Recorded results
The new DNS, website and email paths passed their checks
These results come from the retained completion and handover records. They describe this engagement only and do not promise the same outcome for another domain or provider setup.
DNS authority
Cloudflare became authoritative and returned the expected zone data from its nameservers and multiple public resolver networks.
Website and HTTPS
The root and www addresses reached the approved replacement website, redirects worked and the certificate covered both public hostnames.
Microsoft 365 email
Inbound and outbound mail testing succeeded. The published mail, Autodiscover, SPF, DMARC and retained verification records matched the planned state.
Rollback decision
No rollback was required. The prior zone and recovery steps remained documented through the proving period and final closeout.
Rollback and handover
Separate rollback plans for DNS authority and the website route.
The first rollback would have restored the previous nameservers if Cloudflare failed to become authoritative or if essential DNS and email records did not resolve. The second would have kept Cloudflare authoritative but restored the previous root website record if only the new website route failed.
Handover record
The final report recorded the accepted service layout, test results, account ownership, remaining provider actions, access-removal steps and the boundary between DNS work and any future registrar transfer.
Change boundaries
Proxying, email routing, DNSSEC activation, domain transfer and unrelated account products were excluded from the live cutover. Each would require its own checks and approval.
Limits
What this case study does not claim
DNS changes are affected by the existing zone, provider interfaces, cached answers, account access, DNSSEC state, connected services and the people available to test the result. This page describes a completed migration, not a guarantee of uninterrupted service or a universal sequence for every domain.
No client-identifying proof
Source screenshots, domains, contacts, account exports, exact nameservers, IP addresses, invoices and identifying timings remain private.
No provider shortcut
Provider interfaces and requirements change. Current official guidance and the actual live DNS state must be checked at the time of a future migration.
Related DNS resources
Use the service page for support and the guide for the full checklist
I am based in Christchurch and can complete suitable DNS migration, website validation, email-record, rollback and handover work remotely for businesses across New Zealand.