How to migrate hundreds of domains to Cloudflare without downtime

Who this is for: platform, web, and operations leads who own many zones and cannot afford an outage window. This is the staged method we use; our engineers have led staged DNS, SSL, WAF, and bot migrations covering hundreds of domains with tested rollback paths. Zero downtime is the design goal, not a guarantee.

Why do large migrations fail?#

They fail on the record nobody knew about, the origin firewall that still blocks the new edge, or a rollback that waits on nameserver caches. Cloudflare’s guidance to minimize downtime uses the same order: unproxied records first, an active edge certificate, Cloudflare’s IP addresses allowed, then proxying.

Two terms matter throughout. A DNS-only record answers with your origin’s IP address, and Cloudflare does not handle the traffic. A proxied record answers with Cloudflare anycast addresses, so traffic passes through Cloudflare’s TLS, cache, and WAF. Only A, AAAA, and CNAME records can be proxied; MX, TXT, and other types are always DNS-only.

The wave model#

The wave model orders domains by blast radius. Each wave has a written go/no-go gate and a rollback step. The gates are our published defaults, not Cloudflare recommendations; adjust them to your change process.

Step 1: Take an inventory before anything moves#

Export every zone through the current provider’s API and tag each hostname: web, API, mail, verification, or unknown. Unknown is a blocker. Cloudflare’s import scan may miss records, and records added at the old provider after onboarding must also be added in Cloudflare, so freeze DNS changes until the zone is active. Script the imports: Cloudflare documents a 256 KiB limit per zone file and three import requests per minute per user.

Check these per zone:

• Mail. Records used only for email stay DNS-only. Cloudflare does not proxy SMTP on port 25 by default.
• DNSSEC. Cloudflare says to disable DNSSEC at the registrar before changing nameservers, or the domain can become unreachable. Remove the DS record and wait until its TTL expires at the parent zone, commonly 24 to 48 hours; dig DS example.com shows when it is gone. Changing nameservers earlier makes validating resolvers return SERVFAIL. A multi-signer migration keeps DNSSEC on throughout, if the old provider supports it.
• CAA. CAA records must permit the certificate authority Cloudflare uses. If a zone has any CAA record, Cloudflare adds its Universal SSL authorities automatically, but those records do not appear in the dashboard; check with dig.
• Origins that use the client IP. Allow-lists, rate limits, and logs will see Cloudflare addresses once a hostname is proxied; the real client IP arrives in CF-Connecting-IP.

Step 2: Build one baseline and apply it everywhere#

Define the settings once, keep them in Terraform, and import existing configuration with cf-terraforming. Run the generated imports before the first plan; otherwise Terraform tries to create the resources again.

• SSL/TLS mode Full (strict), which needs a valid origin certificate from a public authority or Cloudflare Origin CA. Automatic SSL/TLS is the default for new zones; to pin Full (strict), choose the custom mode.
• Publicly trusted origin certificates for the rollback path. Visitors who reach the origin directly after a DNS-only rollback may see errors with an Origin CA certificate, which only Cloudflare trusts.
• The same minimum TLS version, Always Use HTTPS, and Automatic HTTPS Rewrites on every zone.
• Cache rules for static paths, with the origin’s Cache-Control header as the contract.
• Managed WAF rulesets, introduced as described in Step 6.
• HSTS held back until every hostname serves HTTPS and the rollback window has closed. Cloudflare warns that a site can become unreachable for the whole max-age period if HTTPS goes away, and advises against switching records to DNS-only once HSTS is on.

Step 3: Move DNS first, proxy second#

Moving DNS and moving traffic are two changes, each with its own check.

1. Lower TTLs at the old provider 24 to 48 hours ahead (our default); a resolver may cache a record for its TTL (RFC 1035). This does not shorten DS caching.
2. Import every A, AAAA, and CNAME record as DNS-only. Proxying is on by default during onboarding: untick the option to proxy imported records, use the cf-proxied:false tag in a zone file, or set proxied: false in the API.
3. Change nameservers at the registrar to exactly the two Cloudflare assigns.
4. Wait for the zone to show Active, up to 24 hours per Cloudflare, confirmed by email. Re-enable DNSSEC only after this, once the previous nameserver records have expired from caches.
5. Confirm edge certificates. Universal SSL is issued after activation, typically within 15 minutes to 24 hours; it is provisioned while records are DNS-only and presented once they are proxied.
6. Allow Cloudflare’s published ranges at the origin (cloudflare.com/ips-v4/, /ips-v6/, or the API). Cloudflare rates an allow-list as moderately secure and open to IP spoofing; block all other addresses only after the rollback window closes.
7. Switch records to proxied, one wave at a time.

Until step 7, only the server that answers DNS has changed for visitors. That is why this stage can be validated without customer impact.

Step 4: Roll back one hostname, not a whole zone#

Once the zone is active, rolling a hostname back is one toggle from proxied to DNS-only. Proxied records use an Auto TTL of 300 seconds, so resolvers typically pick up the change in about five minutes, though local caches can take longer. The rollback works while HSTS is off, the origin has a publicly trusted certificate, and the origin still accepts direct traffic; the origin IP is visible while the hostname is DNS-only. A nameserver rollback waits on registry and resolver caches that you do not control; we do not rely on it.

The migration cutover checklist#

Print it per wave. Every line is pass or fail.

Step 5: Watch the right signals after each wave#

After each wave we compare edge and origin status codes, with 520 to 526 counted separately, cache hit ratio for cacheable paths, and security events by rule. The data comes from the GraphQL Analytics API at https://api.cloudflare.com/client/v4/graphql. Its httpRequestsAdaptiveGroups dataset is available on all plans with at least 31 days of data, and Cloudflare documents edgeResponseStatus and originResponseStatus. Confirm the exact fields by schema introspection, and pace the queries: 300 per five minutes per user, up to 10 zones per query.

Step 6: Keep security changes separate#

Do not move DNS and tighten security in the same change. Cloudflare documents the Log action as Enterprise-only; custom rules on Free, Pro, and Business support every other action. On those plans, filter the expected traffic in Security Analytics and create the rule from those filters; our practice is then to go live on a low-risk subset first. The WAF rollout article has the full runbook.