WAF migration checklist for Cloudflare
This checklist helps teams move WAF policy to Cloudflare without losing visibility or accidentally blocking legitimate users. It emphasizes rule inventory, exception cleanup, staged enforcement, and false-positive review.
This checklist helps teams move WAF policy to Cloudflare without losing visibility or accidentally blocking legitimate users. It emphasizes rule inventory, exception cleanup, staged enforcement, and false-positive review.
Topics: cloudflare, resource, migration, checklist
Machine-readable context: /ai-index.json
Step by step
Step-by-step checklist
- 1
Inventory the existing WAF policy: managed rule sets, custom signatures, allowlists and blocklists, IP and geo rules, rate-based rules, and per-application exceptions with the reason each exists.
- 2
Classify every rule and exception as keep, translate, simplify, or retire — drop stale exceptions and signatures that no longer match a live application path.
- 3
Map intent to Cloudflare primitives: Managed Rules and OWASP Core Ruleset for known patterns, Custom Rules for application-specific logic, Rate Limiting Rules for abuse, and WAF exceptions/skip rules for legitimate edge cases.
- 4
Deploy Cloudflare Managed Rules and Custom Rules in log/simulate mode first so they observe real production traffic without taking action.
- 5
Review Security Events against live traffic, group the top matches by path family, and separate genuine threats from false positives before any rule is promoted.
- 6
Build a scoped exception register — each skip rule documented with its path, condition, owner, and review date — instead of broad global allowlists.
- 7
Promote enforcement in stages: move rule groups from log to challenge or block per application tier, watching event volume and false-positive rate at each step.
- 8
Validate logging and alerting through Logpush to the SIEM, confirm field mapping and dashboards, then decommission the old WAF only after parity is accepted.
Risk register
Risks to control
Managed rules are switched straight to block and immediately reject legitimate requests.
Start every managed rule set and custom rule in log/simulate mode, review real Security Events, then promote per rule group with rollback steps ready.
Legacy exceptions are migrated wholesale, carrying forward dead allowlists that quietly weaken the policy.
Treat exception cleanup as a migration task: justify each one against a live path, retire the rest, and rebuild survivors as scoped skip rules.
False positives are discovered only after enforcement, eroding trust in the new WAF.
Run a dedicated false-positive review window in log mode, classifying top matches by path family before flipping anything to block.
Vendor rule syntax is translated literally instead of by intent, producing rules that do not behave the same on Cloudflare.
Map security intent to Cloudflare Managed and Custom Rules rather than porting signatures verbatim; the goal is equivalent posture, not identical syntax.
Rate-based protections are lost in the move because they were configured separately on the old WAF.
Inventory existing rate-based rules explicitly and rebuild them as Cloudflare Rate Limiting Rules, tested in counting mode against real traffic.
Old and new WAF disagree on logging, leaving a visibility gap at cutover.
Stand up Logpush, SIEM field mapping, and dashboards and confirm event parity before turning off the previous WAF's logging.
Output
Useful deliverables
- WAF rule and exception inventory with keep/translate/simplify/retire classification per item.
- Intent-to-Cloudflare mapping: Managed Rules, OWASP Core Ruleset coverage, Custom Rules, and Rate Limiting Rules.
- Scoped exception register with path, condition, owner, and review date for each skip rule.
- Staged enforcement plan moving rule groups from log to challenge to block per application tier.
- False-positive review log grouping top Security Events by path family with disposition.
- Logpush and SIEM parity validation covering field mapping, dashboards, and alerts.
- Cutover and decommission checklist confirming posture acceptance before the old WAF is removed.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
Can existing WAF rules be imported directly into Cloudflare?
No reliable direct import exists across vendors. Rules and signatures are reviewed for intent and rebuilt as Cloudflare Managed Rules, the OWASP Core Ruleset, Custom Rules, and Rate Limiting Rules. The aim is matching security posture, not copying syntax.
How do you avoid blocking real users during a WAF migration?
Deploy everything in log/simulate mode first so rules only observe traffic, review the resulting Security Events to separate threats from false positives, then promote enforcement in stages per rule group and application tier with rollback steps documented.
What should happen to the old WAF's exceptions and allowlists?
They are audited, not copied. Each exception must justify itself against a live application path; stale ones are retired and the rest are rebuilt as narrowly scoped Cloudflare skip rules with an owner and review date, rather than broad global allowlists.
How are false positives handled before enforcement?
During the log-mode window, the top matches are grouped by path family and reviewed against real traffic. Genuine edge cases become scoped exceptions; everything else stays in scope, and only then are rule groups promoted to challenge or block.
Will I lose WAF visibility during the cutover?
Only if logging is not prepared. Configure Logpush to your SIEM, confirm field mapping and dashboards, and verify event parity with the old WAF before decommissioning it, so there is no gap in security telemetry.
Nanosek
Plan a WAF 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.