Leaving a legacy enterprise WAF — a migration checklist that avoids the outage
Migrations fail in the cutover, not the setup
Setting up a new WAF is easy. Moving live production traffic to it without breaking anything is where teams get hurt. The classic failure is a big-bang DNS switch that sends real users through an enforcement config nobody validated against real traffic — and the first thing you learn is which legitimate requests the new rules block, live, in front of customers. The second failure is discovering mid-cutover that something you depended on — a specific TLS behavior, a header the old WAF added, an IP allowlist — did not come across.
A safe migration is a sequence, not a switch. Here is the checklist we use with teams moving off an incumbent.
1. Inventory what the old WAF actually does
Before anything moves, write down what your current WAF is really doing — not what its brochure says. Which rules are in enforcement versus log-only? What custom rules or exceptions has someone added over the years? What rate limits, IP allow/deny lists, and geo rules are live? What headers does it inject? This inventory is the spec for your new config, and it is almost always different from what people remember.
2. Bring the domain under the edge in detection mode first
Point the new edge at your origin and run the OWASP ruleset in detection, not enforcement. Nothing blocks yet. You watch what would have been blocked against your real traffic, and you tune out the false positives before a single real user is affected. This is the step that prevents the self-inflicted outage, and it is why we start every onboarding here rather than flipping enforcement on day one.
3. Get TLS continuity right
A cutover breaks if certificates lapse for even a moment. Smart WAF issues per-tenant Let’s Encrypt TLS automatically, from the first DNS change onward — no manual certificate export from the old vendor, no shared-cert blast radius. Confirm the certificate issues and serves cleanly on the new edge before you move production traffic, not during.
4. Move traffic gradually, with a real rollback
DNS is your migration control. Because the rollback for a DNS-based edge is “point the record back,” you always have an exit — but only if you planned for it:
- Lower your DNS TTL days ahead, so a cutover or a rollback propagates in minutes, not hours.
- Move a slice first where you can — a staging hostname, a low-traffic subdomain — and watch it through the edge before the apex domain follows.
- Keep the old WAF running until the new one has proven itself on real enforcement traffic. Overlap is cheap insurance; a gap is an outage.
Every config change you make during the cutover lands in an immutable audit log, so if something misbehaves you can see exactly what changed and when.
5. Turn on enforcement, then the extras
Once detection has been clean against real traffic, switch enforcement on. Then layer the rest at your own pace: rate limiting for your login and API endpoints, the challenge ladder for bot pressure, and geo or IP rules from your inventory. There is no reason to enable everything at once — each layer is independent.
What we don’t claim
We are not going to tell you migration is one click. If you are leaving a deeply customized enterprise deployment with years of bespoke rules, reproducing that intent takes real work and we would rather set that expectation up front than surprise you. What we do claim is that the process is safe when it is done detection-first with a DNS rollback in hand, and that we do the hands-on part of onboarding with you rather than handing you a self-serve wizard and wishing you luck. See how we compare to the incumbents if you are weighing the move.
Planning your cutover
If you are thinking about leaving a legacy WAF, the detection-first, gradual path is how you do it without an outage. Tell us your domain and we will plan the cutover with you.