Emergency Cloudflare migration checklist
Use this checklist during urgent Cloudflare onboarding to confirm the incident driver, critical hostnames, DNS authority, certificates, SSL/TLS mode, origins, Host header and SNI behavior, cache baseline, WAF baseline, bot and rate limiting approach, logging, monitoring, rollback, and decision ownership.
Use this checklist during urgent Cloudflare onboarding to confirm the incident driver, critical hostnames, DNS authority, certificates, SSL/TLS mode, origins, Host header and SNI behavior, cache baseline, WAF baseline, bot and rate limiting approach, logging, monitoring, rollback, and decision ownership.
Topics: cloudflare, resource, emergency, cloudflare, migration, checklist
Machine-readable context: /ai-index.json
Step by step
Step-by-step checklist
- 1
Confirm the incident driver in one line — active DDoS, origin overload, CDN/WAF outage, DNS provider failure, or an expired/broken certificate — because it determines what you stabilize first.
- 2
Identify the handful of critical hostnames that must stay up and confirm who currently controls their DNS and who can authorize emergency changes right now.
- 3
If DNS authority is reachable, onboard the zone to Cloudflare and recreate critical records; if it is not, use a CNAME setup so you can proxy individual hostnames without waiting on a full nameserver move.
- 4
Bring the origin behind Cloudflare safely first: set SSL/TLS to Full (strict) if the origin certificate is valid, confirm the Host header and SNI the origin expects, and proxy (orange-cloud) the critical records.
- 5
Stand up an immediate protective baseline — enable the relevant managed WAF rulesets, switch on the relevant DDoS/HTTP attack protections, and deploy a small set of rate-limiting and bot rules in enforce only where the attack signal is clear, otherwise Log.
- 6
If the origin is being directly attacked, lock it down: restrict the origin firewall to Cloudflare IP ranges and turn on Authenticated Origin Pulls so traffic can only reach it through Cloudflare.
- 7
Turn on monitoring you can watch live — Security Events, traffic and origin analytics, and Logpush to your SIEM if time allows — and assign one person to call rollback.
- 8
Write down the rollback path before declaring success: which records, nameservers, and proxy states to revert, and keep TTLs low until the incident is closed and behavior is verified.
Risk register
Risks to control
Proxying records with SSL/TLS left on Flexible during the rush exposes traffic or creates redirect loops.
Check the origin certificate first and use Full (strict) where it is valid; only fall back deliberately and document it as temporary.
The attacker keeps hitting the origin directly because its IP is already known and unprotected.
Restrict the origin firewall to Cloudflare IP ranges and enable Authenticated Origin Pulls so the published IP becomes useless to direct attacks.
DNS authority is not actually controllable in the moment, stalling a full nameserver move mid-incident.
Confirm registrar and DNS access before committing; if it is not available, fall back to a CNAME setup to proxy critical hostnames immediately.
Emergency WAF, bot, or rate-limit rules are set too aggressively and block real users alongside the attack.
Scope rules tightly to the observed attack signal, run anything ambiguous in Log, and watch Security Events live to back rules off quickly.
High TTLs on existing records slow both the onboarding and any rollback.
Lower TTLs as the first action where possible and keep them low until the incident is fully resolved.
Nobody owns the rollback decision while several people change settings at once.
Assign a single decision owner and a written rollback path before enabling protections, so reverting is one decision, not a debate.
Output
Useful deliverables
- Incident summary identifying the driver, the critical hostnames, and the DNS authority and approval owners.
- Emergency onboarding plan (full move vs CNAME setup) with the records to recreate and proxy first.
- Origin protection configuration: SSL/TLS mode, Host header/SNI confirmation, origin IP allowlist, and Authenticated Origin Pulls.
- Protective baseline of managed WAF rulesets, DDoS/HTTP attack settings, and scoped rate-limiting and bot rules with their enforce/Log state recorded.
- Live monitoring setup covering Security Events, traffic/origin analytics, and Logpush where time permits.
- Rollback path naming the exact records, nameservers, proxy states, and the single decision owner.
- Post-incident handover noting which emergency settings are temporary and need proper tuning once stable.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
How fast can a hostname actually get behind Cloudflare in an incident?
If you control DNS, proxying a critical hostname can be near-immediate once the record is in Cloudflare, bounded by the record's existing TTL. A full nameserver move depends on registrar propagation and is slower, which is why a CNAME setup is often the faster emergency path.
We are under a DDoS right now and the origin IP is exposed. What matters most?
Get the critical hostnames proxied through Cloudflare, then immediately restrict the origin firewall to Cloudflare IP ranges and enable Authenticated Origin Pulls. Until the origin only accepts Cloudflare traffic, attackers can keep hitting the published IP directly and bypass everything you turned on.
Should I switch WAF and rate limiting straight to blocking during the emergency?
Only where the attack signal is unambiguous. Scope those rules tightly and run anything uncertain in Log so you do not block legitimate users on top of the incident. Watch Security Events live and tighten from there.
What is the difference between this and a normal migration?
A normal migration is baselined, staged, and validated before cutover. An emergency migration trades that for speed: you stabilize the critical hostnames and origin first, accept some temporary settings, and keep a clear rollback path, then do the proper tuning and validation once the incident is closed.
Nanosek
Prepare emergency migration
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.