Scope
Move DNS hosting, not necessarily the domain registration
This guide is for the common situation where a domain remains registered at GoDaddy, but Cloudflare becomes the authoritative DNS provider. It is not a domain transfer, hosting migration or automatic email-platform change. Those can happen separately; they should not be accidentally bundled into one high-risk change.
Before changing anything
Confirm who controls the registrar, DNS and connected services
A migration goes wrong when the team edits the dashboard that is not authoritative, or discovers too late that a recovery code, third-party sender or old nameserver is owned by someone else. Record who controls each account before you start.
Registrar access
Confirm the GoDaddy account owner, recovery email, two-factor method, billing contact, renewal date and who can change nameservers.
Current DNS authority
Check the live nameservers before trusting any zone editor. If GoDaddy is not authoritative already, its DNS screen may not control production traffic.
Cloudflare ownership
Confirm access to the intended Cloudflare account and record which person can approve or reverse a zone change.
Connected services
List the web host, email provider, form service, CRM, newsletter tool, payment service, VoIP provider and any service that uses domain verification.
Current setup
Capture the whole live zone before importing it
Take an export and readable screenshots of the current zone. A DNS importer can help, but it is not a substitute for comparison. The record that is easiest to miss is often the one that keeps email delivery, an SSL renewal or a third-party integration working.
Web records
Record apex and www A, AAAA and CNAME records, plus redirects, canonical hostnames and any staging or subdomain routes.
Email records
Capture MX, SPF, DKIM, DMARC, autodiscover, mail-host and verification TXT records. Match them to the actual providers in use today.
Service verification
Look for records used by Google, Microsoft 365, payment tools, analytics, certificate authorities, helpdesks, booking tools or newsletters.
Less common records
Check CAA, SRV, NS delegations for subdomains and _acme-challenge records. These are small entries with potentially large operational impact.
Cloudflare setup
Build and compare the Cloudflare zone before the nameserver change
Cloudflare's usual full setup is: add the domain, import or create DNS records, review them and then update the nameservers at the registrar. Cloudflare explicitly recommends reviewing the records before activation because an incomplete zone can make the domain unreachable.
Use the assigned nameservers
Copy the exact nameserver pair shown for the zone. Do not reuse a pair from another Cloudflare account or a screenshot from an old migration.
Review imported records
Compare record type, name, value, priority, TTL and notes against the original zone. A successful import does not prove that every record is present.
Choose proxy status deliberately
Cloudflare proxy status applies to A, AAAA and CNAME web records. Start with only the public HTTP/S hostnames that are understood and tested.
Keep mail DNS-only
Mail-related hostnames and records should remain DNS-only unless the mail provider gives a specific supported exception. Cloudflare does not proxy ordinary SMTP traffic.
Do not skip this check
Pause if DNSSEC is already active
DNSSEC changes deserve their own plan. Cloudflare's standard onboarding guidance says an existing domain should have its DNSSEC state addressed at the registrar before a nameserver move, unless an advanced active-migration method is being used. Treat an existing DS record as a reason to stop and check, not as a normal DNS record.
Check the registrar
Find out whether DNSSEC is enabled, whether a DS record exists and who has authority to change it.
Use the right method
For simple zones, follow the provider's current migration guidance. For an advanced signed migration, use a specialist or the provider's documented multi-signer process.
Do not guess timing
DNSSEC relies on cached DS and nameserver data. Record the relevant TTLs and confirm the intended sequence before making the cutover.
Re-enable deliberately
Once the Cloudflare zone is stable, enable DNSSEC only through the correct provider sequence and keep a written record of the new DS details.
Cutover
Change nameservers only after the new zone is ready
In GoDaddy, changing the nameservers changes where the internet looks for the live DNS zone. It is not the same as adding an NS record inside a zone. Keep the prior zone available until the Cloudflare zone has been tested from outside the normal office network.
- Confirm the Cloudflare zone matches the captured source zone and that the assigned nameservers are correct.
- Record a rollback owner, the old nameserver values and the exact place they are stored.
- Update the domain's nameservers in the GoDaddy Domain Portfolio using Cloudflare's assigned pair.
- Wait for the delegation to settle, then check authoritative answers rather than relying on one browser or one office resolver.
- Validate website, redirects, SSL, email, contact forms and business-critical third-party services.
- Keep the evidence and the old zone until the agreed observation window has passed.
Post-change testing
Test the services people actually use
A green status badge is not enough. Run a small, purposeful set of tests from a network that is not relying on the same cached answer as the administrator. Record the result, the time and what was tested so the next person has evidence rather than a memory.
Website and redirects
Open the preferred hostname and its alternate. Check HTTPS, redirects, public pages, logged-in areas and assets or forms that depend on another hostname.
Email receive and send
Send a test message in both directions, check any shared or forwarding address and confirm that authentication and spam-folder behaviour have not changed.
Third-party services
Confirm form notifications, booking tools, payment callbacks, CRM connections, newsletter verification and any certificate or DNS validation workflow.
Search and measurement
Check canonical redirects, analytics loading, sitemap availability and Search Console access if the domain change also touches web delivery.
Common questions
What this migration does and does not change
Does this transfer the domain away from GoDaddy?
No. Changing nameservers can leave the registration, billing, renewal and account recovery at GoDaddy. A registrar transfer is a separate decision.
Should every record be proxied through Cloudflare?
No. Proxy status is for supported web hostnames. Email and many third-party verification records need DNS-only treatment.
Can I delete the old DNS zone immediately?
Do not remove it until the new authoritative zone and the business-critical services have been validated, with a documented rollback plan.
Will this fix an unrelated website or email fault?
Not by itself. A DNS migration can expose an existing configuration problem, so identify the source of the fault before using a nameserver change as a remedy.
DNS migration support
Want someone to plan and run the cutover?
I am based in Christchurch and can handle suitable DNS migrations remotely for businesses across New Zealand. The work can include zone capture, target-zone comparison, nameserver changes, website and email testing, rollback notes, a proving period and final handover documentation.
Provider references
Use current official guidance at the point of change
Provider interfaces and requirements can change. Treat this guide as a planning checklist and a record of the checks, then confirm the exact current steps in the relevant official documentation before making a live change.
Related guidance
Continue with DNS, email and launch checks
Use the DNS checklist to confirm ownership and records, the DNS migration and routing support page for a planned cutover or reachability fault and the launch checklist when the change also affects redirects, forms, analytics or canonical URLs.