Just wrapped up a six-month migration project where we moved our primary customer-facing applications off an on-prem F5 BIG-IP ASM (Advanced WAF) setup and onto Cloudflare’s WAF. I've done plenty of tool migrations in the CRM and ERP space, but this infrastructure shift was a different beast. I wanted to share the journey because the mental model switch is significant, and the payoff is real if you can get through the initial pain.
The biggest hurdle wasn't the rules themselves—it was the paradigm shift. Coming from BIG-IP, you're used to a stateful, appliance-based mindset. You control everything: the hardware, the full traffic flow, the exact inspection point. Your rules are often complex, procedural logic blocks. Moving to Cloudflare, you're adopting a cloud-proxy, stateless (per-request) model. You no longer "see" the client IP directly in the same way, and your rule logic has to adapt to that. The learning curve felt brutal because I kept trying to force Cloudflare to behave like F5. Once I embraced its native way of working—leveraging the Cloudflare firewall rules engine and the new WAF/Transform Rules—things clicked.
Here’s my practical checklist of what needed the most attention during the migration:
* **Traffic Flow & IP Trust:** Reconciling how we handle IP whitelisting was a major task. We had to move from appliance-level source IP lists to using Cloudflare's IP Access Rules and firewall rules with `cf.connecting_ip`, and update all our backend applications to trust Cloudflare's IP ranges.
* **Rule Translation:** You can't just copy and paste F5 iRules or ASM policies. We had to decompose them into Cloudflare's building blocks.
* Simple header checks or path-based blocks went into **Firewall Rules**.
* More sophisticated attack signatures and managed rules rely on the **WAF** itself (the OWASP Core Rule Set and Cloudflare Managed Rules are excellent).
* URL rewrites, header manipulations, and query string modifications found a new home in **Transform Rules**.
* **Logging & Visibility:** BIG-IP logging is deeply configurable but localized. Cloudflare's analytics and Logpush to our SIEM are powerful, but you need to learn the new data schema (like `BotScore`, `ClientRequestHost`, `EdgeResponseStatus`). Setting up dashboards around these new fields was a week-long project.
* **Change Management Process:** The ability to deploy rules instantly from the dashboard or API is a double-edged sword. We had to institute a strict staging process using **WAF Overrides** for specific hostnames and heavy use of the *Evaluate* action in firewall rules before going to *Block*.
The "worth it" part comes down to a few key wins. The global anycast network means DDoS mitigation is someone else's problem now, and it's shockingly effective. Performance improved globally due to Argo Smart Routing for our dynamic content. The API-first design allows us to integrate WAF deployment into our CI/CD pipeline, which was clunky with our old setup. And frankly, the cost model was a fraction of our F5 hardware/maintenance renewal.
If you're embarking on a similar migration, my biggest piece of advice is this: Don't try to do a literal, one-to-one migration. Take the opportunity to clean house. Re-examine every custom rule you had in F5. Many were likely workarounds for old app versions or threats that are now covered by Cloudflare's managed protections. Migrate the intent, not the exact syntax.
Happy to dig into specifics on any of these points, especially around data mapping for logs or handling legacy API integrations that made assumptions about the network.
-- Mike
Map twice, migrate once.
I'm a platform lead at a mid-market SaaS company (around 300 employees), where we run a hybrid stack with Kubernetes on-prem and workloads in AWS. We've operated both BIG-IP LTM/ASM and Cloudflare WAF in production for different services over the last five years.
* **Deployment and Iteration Speed:** Cloudflare changes are near-instant, while BIG-IP staged-config pushes and node syncs often added 15-30 minutes to our validation cycles. This speed is a clear win for cloud-native CI/CD pipelines.
* **True Cost Beyond Licensing:** BIG-IP's capital expense and 20-25% annual support fee were substantial. Cloudflare's usage-based WAF pricing scaled predictably for us, but egress costs from your origin to Cloudflare's network can become a hidden multiplier if you have high-traffic, uncacheable POST/PUT requests.
* **Operational Control vs. Hands-Off Management:** With F5, you have granular control down to TCP buffers and hardware. In Cloudflare, you lose that deep visibility; client IPs are via CF-Connecting-IP headers, and you're trusting their global network's health. This makes full packet capture debugging impossible.
* **Rule Logic and Migration Effort:** Migrating complex ASM policies required a full rewrite. We couldn't translate our F5 iRules directly; we had to rebuild logic using Cloudflare's firewall rules, WAF custom rules, and Transform Rules. This took about 80 hours of analysis and testing for a core set of 15 legacy policies.
I'd recommend Cloudflare WAF for teams deploying mostly cloud-native applications who prioritize development velocity and lack dedicated F5 operators. For legacy on-prem applications requiring deep packet inspection or strict compliance audits where you must provide raw traffic logs, BIG-IP is still the safer choice. To make a clean call, tell us your team's ratio of F5 SMEs to DevOps engineers and whether you have a hard requirement for on-prem traffic inspection.
Mike D.
The mental model switch is the killer. It's the same moving from something like Salesforce to Pipedrive. You keep trying to recreate the old workflows in the new system and it's painful. Gotta stop fighting the tool's architecture.
Sounds like you finally got it to click. I bet the biggest win isn't even in the rules, it's that you stopped paying F5's extortionate support fees. The real WAF.
CRM is a means, not an end.
That mental model shift from appliance to proxy is exactly where you lose real security control. You said you no longer "see" the client IP directly. So how are you handling audit trails and incident response now?
Real forensic data still originates at your ingress. Are you just trusting Cloudflare's logs? Have you validated their sampling rates and retention against your actual compliance requirements? SOC 2 isn't satisfied by a vendor's marketing page.
No SOC2, no deal.