Cloudflare migration checklist
Use this checklist to organize a Cloudflare migration before moving production traffic. It covers discovery, DNS, certificates, WAF, cache behavior, logs, validation, rollback, and post-launch operations.
Use this checklist to organize a Cloudflare migration before moving production traffic. It covers discovery, DNS, certificates, WAF, cache behavior, logs, validation, rollback, and post-launch operations.
Topics: cloudflare, resource, cloudflare, migration, checklist
Machine-readable context: /ai-index.json
Step by step
Step-by-step checklist
- 1
Inventory every public hostname, the platform that currently fronts it (CDN, WAF, DNS provider, load balancer), the origin behind it, and which team owns each one.
- 2
Capture a behavioral baseline per hostname: current cache hit ratio, TTLs, response headers, redirect chains, status codes, WAF actions, and any edge logic, so you have something to compare against after cutover.
- 3
Decide the onboarding model per zone — full nameserver move versus CNAME setup (partial/Business+ zone) — and confirm registrar access, current authoritative provider, and DNSSEC state before touching anything.
- 4
Map existing controls into Cloudflare primitives: cache behavior to Cache Rules, origin overrides to Origin Rules, header and URL edits to Transform Rules, redirects to Redirect Rules, and WAF/bot/rate-limit policy to the corresponding Rulesets, marking each as keep, replace, simplify, or retire.
- 5
Choose the SSL/TLS encryption mode (prefer Full (strict)), order or upload edge certificates, plan Authenticated Origin Pulls or an origin allowlist, and confirm Host header and SNI behavior the origin expects.
- 6
Build everything in a staging zone or behind test hostnames with WAF and bot controls in Log/monitor mode, then validate using internal DNS overrides or low-TTL test records while the legacy platform still serves production.
- 7
Lower TTLs ahead of the window, define go/no-go criteria, owner sign-offs, monitoring thresholds, and a written rollback path, then execute a phased cutover with live validation.
- 8
After traffic settles, compare Cloudflare analytics against the baseline, promote WAF and bot controls from monitor to enforce, confirm Logpush is flowing, and hand over runbooks and ownership.
Risk register
Risks to control
Hostnames or delegated subdomains are missed during inventory and stop resolving after the nameserver move.
Reconcile the exported zone file against live DNS lookups and certificate SAN lists, and confirm every record (including NS delegations and email records) is recreated in Cloudflare before cutover.
An SSL/TLS mode of Flexible or Full hides a broken origin certificate and creates redirect loops or insecure delivery.
Validate the origin certificate chain, then set Full (strict) and confirm end-to-end TLS on test hostnames before production traffic moves.
Default proxied caching changes origin load and breaks dynamic or authenticated responses.
Define Cache Rules per path, set cache eligibility and TTLs explicitly, and verify cache status and origin request volume on test traffic before promotion.
WAF and bot controls are switched straight to enforce and block legitimate users or API calls.
Deploy all custom rules, managed rulesets, bot controls, and rate limits in Log mode first, review sampled events, then promote rule by rule.
Rollback depends on memory because TTLs were never lowered.
Reduce record TTLs days before the window and document the exact records, nameservers, and policy states to revert to, with named owners.
Logging and ownership are treated as a post-launch afterthought, leaving a visibility gap.
Configure Logpush, dashboards, and alerts and assign operational ownership before the cutover, not after.
Output
Useful deliverables
- Hostname and zone inventory listing origin, current fronting platform, owner, and chosen onboarding model per record.
- Behavioral baseline per critical hostname covering cache, headers, redirects, status codes, and security actions.
- Cloudflare target architecture: zones, DNS records, SSL/TLS mode, certificates, origin configuration, cache topology, and rule layout.
- Control mapping register translating legacy behavior into Cache Rules, Origin Rules, Transform Rules, Redirect Rules, WAF, bot, and rate-limiting rulesets with keep/replace/simplify/retire decisions.
- Staged validation results from test hostnames and monitor-mode policies, including a parity comparison against the baseline.
- Cutover and rollback runbook with lowered TTLs, go/no-go criteria, monitoring thresholds, and named owners.
- Post-launch tuning backlog and operating model covering enforcement promotion, Logpush, alerting, and managed operations handover.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
Where do most Cloudflare migrations actually go wrong?
Rarely at the DNS move itself. The common failure points are SSL/TLS mode mismatches against the origin, caching that changes origin behavior, and security controls promoted to enforce too quickly. A behavioral baseline plus monitor-mode rollout catches these before they reach users.
Do I have to move my nameservers to Cloudflare?
Not always. A full setup moves authoritative DNS to Cloudflare nameservers; a CNAME setup (partial zone, available on Business and Enterprise) proxies specific hostnames while DNS stays elsewhere. The checklist covers choosing per zone based on registrar access, DNSSEC, and how many records you control.
How do I test Cloudflare before sending real traffic to it?
Use a staging zone or test hostnames, validate with internal DNS overrides or low-TTL records, and keep WAF and bot controls in Log mode. This lets you confirm cache, TLS, headers, and policy behavior while the existing platform still serves production.
What should be true before I delete the old platform?
Cloudflare analytics should match or improve on the baseline, WAF and bot controls should be enforcing cleanly, Logpush and alerting should be validated, and application, security, and infrastructure owners should have signed off on the runbooks. Decommission only after that.
Nanosek
Get migration help
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.