Should the orange cloud be enabled on every record right after the migration?

No, that is the fastest way to turn a migration into an outage. The safe method is to recreate every record as DNS only (grey cloud) first, verify the site and email work identically, then proxy the web records one by one while checking the site at each step.

Does DNSSEC need to be disabled before the migration?

Yes, as long as the new zone is not signed. If the registrar keeps the DS record of the old operator while the new nameservers do not sign the zone, validating resolvers consider the zone invalid and the domain disappears from the internet for part of the audience. Remove the DS before the switch, then re-enable DNSSEC once Cloudflare serves the zone.

Can a DNS migration to Cloudflare break email?

Only if the mail records are poorly recreated: MX, SPF (TXT), DKIM and DMARC must be copied identically, and mail hostnames must never be proxied. Our guide on broken email after moving to Cloudflare covers the deliverability pitfalls in detail.

Migrating Your DNS to Cloudflare Without Downtime

You want to move to Cloudflare™ to unlock the proxy, WAF, and cache rules, but the site must not go down and email must keep flowing. Here is the migration playbook that avoids the classic traps.

The golden rule: the migration is won before the nameserver switch

A successful DNS migration is prepared ahead of time, never improvised. The moment you replace the nameservers at the registrar is just a switching step: everything that matters (complete record inventory, lowered TTLs, DNSSEC neutralized) happens BEFORE. A well-prepared zone switches over without a hiccup; a hastily copied zone loses email for two days or, worse, vanishes from DNS because of an orphaned DS record.

The migration playbook, step by step

Inventory every record, not just the website's. Export the zone from the current operator (zone file or manual copy) and identify every type: A, AAAA, CNAME, MX, TXT (SPF, Google/Microsoft domain verifications), SRV, CAA. Cloudflare's automatic scanner only catches the most common web records: a forgotten telephony SRV or internal CNAME only surfaces in production, as an outage.
Lower TTLs 24 to 48 hours ahead. Set the TTLs of key records to 300 seconds at the current operator. If a fix becomes necessary during the switch, it propagates in minutes instead of hours.
Create the zone in Cloudflare and copy everything, grey cloud. Add the domain, let the initial scan fill the zone, then verify it line by line against your inventory. Recreate anything missing, and set every record to DNS only (grey cloud) for this phase: proxying comes after, never during.
Handle DNSSEC. If the zone is signed at the current operator, remove the DS record at the registrar and let it propagate before switching nameservers. A DS pointing at servers that no longer sign invalidates the whole zone for validating resolvers.
Switch the nameservers at the registrar. Replace the current NS with the pair Cloudflare provides (check the exact names in the dashboard, they vary per zone). The rest is propagation: 1 to 4 hours in practice, up to 24-48 hours theoretically.
Verify the site and email before proxying anything. Test the site on both address families, send and receive email, check that third-party services (CRM, telephony, tools querying DNS) still respond. This is the moment to fix things, with an instant rollback path since resolvers still know the old NS.
Proxy progressively, then harden SSL/TLS. Switch web records to the orange cloud one at a time, checking the site at each step. Set SSL/TLS mode to Full (strict) with a valid origin certificate, otherwise you open the door to the infinite HTTPS redirect loop.

The traps that cost the most

The forgotten DS record: the most brutal failure of a migration. The domain stops resolving for validating resolvers, often for only part of the audience, which makes diagnosis counter-intuitive. Always remove the DS before the switch.
Approximate mail records: a missing MX or a truncated SPF is rarely noticed immediately; email bounces or lands in spam for weeks. Copy MX, SPF, DKIM and DMARC character for character, and keep mail hostnames on grey cloud: proxying an MX breaks delivery. Our guide on broken email after the Cloudflare proxy covers this case in detail.
Proxying non-web hostnames: webmail, FTP, hosting control panels, legacy API clients: behind the proxy, these services hit blocked non-standard ports and get filtered. Grey cloud by default, orange cloud by justified exception.
Switching nameservers on a Friday at 5 pm: propagation can stretch over 48 hours, during which both zones coexist. Migrate early in the week during business hours, while the old zone is still fresh in resolver caches and help is reachable.
Trusting the automatic scan: the Cloudflare scanner is good at standard web records, blind to the rest. The line-by-line check against the inventory is not optional.

Frequently asked questions

How long does a DNS migration to Cloudflare take?

The manipulation takes under an hour with a prepared zone. Propagation following the nameserver change runs 1 to 4 hours in practice, up to 24-48 hours theoretically depending on TTLs. That is why lowering TTLs days ahead matters: an anomaly then gets corrected in minutes.

Should the proxy (orange cloud) be enabled right after the migration?

No, that is how incidents stack up. Recreate the whole zone on grey cloud first and confirm the site and email behave identically. Proxying comes next, record by record, with a check at each step. A problem appears? You know exactly which switch triggered it.

What to do about DNSSEC during the migration?

Remove the DS record at the registrar before changing nameservers, then re-enable DNSSEC once Cloudflare serves the zone (it provides the new DS material). Leaving an orphaned DS invalidates the zone for validating resolvers, with partial outages that are hard to diagnose.

Can the migration make me lose email?

Only if mail records are poorly recreated or mail hostnames get proxied. With MX, SPF, DKIM and DMARC copied identically and left on grey cloud, email sees nothing. Trouble starts when an MX or a webmail host is proxied, or an SPF gets truncated during the copy.

Migrating your DNS zone to Cloudflare™ without downtime