Cloudflare rollback plan template
This template helps teams define when and how to reverse a Cloudflare migration if validation fails or production risk increases.
This template helps teams define when and how to reverse a Cloudflare migration if validation fails or production risk increases.
Topics: cloudflare, resource, cloudflare, rollback, plan, template
Machine-readable context: /ai-index.json
Step by step
Rollback procedure
- 1
Define the explicit rollback triggers before the window: validation thresholds (error rate, latency, cache hit ratio, WAF false positives, failed health checks) and the time-box after which no-recovery means revert.
- 2
Capture the pre-cutover baseline state per zone: nameservers or CNAME targets, DNS records with current TTLs, proxy (orange/grey-cloud) status, SSL/TLS mode, active certificates, and origin firewall allowlists.
- 3
Lower DNS TTLs ahead of the change so a reversion propagates quickly, and record the exact prior values to restore so TTLs return to normal afterward.
- 4
Document the precise reversion actions per layer: DNS/nameserver revert, proxy toggle, WAF/rules disable-or-revert to prior version, Workers route removal or version pin, and Load Balancing pool/steering restore.
- 5
Assign a named owner and a backup for each rollback action, with the decision-maker who can call go/no-go and the communication owner who notifies stakeholders.
- 6
Verify the previous platform or origin is still live and capable of taking full traffic during the entire window — confirm certificates are valid and origin firewall still admits the old path.
- 7
Dry-run the rollback on a test hostname or low-risk record to confirm the steps, timings, and propagation behave as documented before relying on them.
- 8
Define the post-rollback checklist: confirm traffic returned to baseline, restore original TTLs, capture what failed, and set criteria for a second attempt.
Risk register
Risks to control
Rollback triggers are vague, so nobody can decide when to revert during a live incident.
Write measurable triggers (specific error-rate, latency, and validation thresholds plus a hard time-box) and name the person empowered to call it.
DNS TTLs were never lowered, so reverting nameservers or records takes hours to propagate.
Lower TTLs in advance, record the original values, and confirm the reduced TTL has fully aged out before the cutover begins.
The old platform or origin was changed or shut down, leaving nothing to roll back to.
Freeze the previous environment, keep its certificates valid, and keep the origin firewall admitting the prior path until rollback is no longer possible.
Reverting DNS does not restore prior behavior because WAF, Workers, or Load Balancing state moved forward independently.
Track every changed layer in the plan and pin each to a known-good version or saved configuration so a revert restores the whole stack, not just DNS.
Certificate or SSL/TLS mode mismatch after reverting causes TLS errors on the old path.
Record the prior SSL/TLS mode and certificate state, and verify the old path still presents a valid, trusted certificate as part of the dry run.
Rollback is attempted from memory under pressure and steps are missed or run out of order.
Use a single ordered runbook with owners, exact commands or dashboard paths, and a dry run completed before the window.
Output
Useful deliverables
- A rollback plan document with explicit, measurable revert triggers and a hard time-box.
- Pre-cutover baseline snapshot per zone: nameservers/CNAMEs, DNS records, TTLs, proxy status, SSL/TLS mode, certificates, and origin allowlists.
- Ordered per-layer reversion runbook covering DNS, proxy, WAF/rules, Workers routes/versions, and Load Balancing.
- Ownership matrix with primary and backup owners, the go/no-go decision-maker, and the communication owner.
- TTL plan recording reduced values for the window and the original values to restore.
- Dry-run results validating the rollback steps and propagation timing on a low-risk record.
- Post-rollback checklist for restoring baseline, capturing root cause, and qualifying a retry.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
What actually goes into a Cloudflare rollback plan?
Defined revert triggers and a time-box, a baseline snapshot of every layer you are changing (DNS, TTLs, proxy status, SSL/TLS mode, certificates, WAF/rules versions, Workers routes, Load Balancing), the ordered reversion steps, and named owners with a single go/no-go decision-maker.
How fast can a Cloudflare migration be rolled back?
Speed is governed mostly by DNS TTLs and how cleanly each layer can revert. If TTLs were lowered in advance and proxy status, rules, and routes are pinned to known-good states, reversion is quick; if TTLs are still high or the old origin was decommissioned, it is not.
Why lower DNS TTLs before the cutover instead of during rollback?
Resolvers cache records for the TTL set when they last queried. A reduction only takes effect after the old TTL ages out, so lowering it during an incident is too late. You lower it ahead of time and restore the original value once you are stable.
Is reverting DNS enough to undo a Cloudflare migration?
Not always. DNS only addresses traffic path. If WAF policy, Workers routes, or Load Balancing steering moved forward, those must be reverted too, which is why the plan tracks every changed layer with its prior version.
When should a rollback be triggered rather than fixing forward?
When a pre-agreed trigger is breached — for example error rate or latency past threshold, sustained WAF false positives blocking real users, or failed validation past the time-box — and there is no fast, confident fix within the remaining window.
Nanosek
Build a rollback plan
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.