Our organization recently completed a migration to Cloudflare One, moving from a legacy on-premise ZTNA/SWG stack. The sales engineering narrative heavily emphasized a "frictionless," "rapid," and "straightforward" migration path, with an estimated timeline of 8-12 weeks. The reality diverged significantly, culminating in a 26-week project requiring external consultancy.
The primary friction points were not in the core connectivity (Cloudflare Tunnel) but in the policy translation and the performance benchmarking of the new secure web gateway. Our existing setup had several hundred granular L7 policies. The promised "policy converter" tools only handled a superficial translation, missing critical context and leaving us with:
* Significant gaps in application-specific allowances.
* No translation for legacy protocol decoders our old vendor used.
* Inconsistent handling of identity provider groups between IdP sessions and Access policies.
This resulted in a protracted testing phase where we had to manually rebuild and validate each policy. The performance characteristics under synthetic load also differed. A simple `wrk` benchmark against our internal HR application showed a marked latency increase in the first-hop through the SWG.
```bash
# Baseline (Old Stack, 95th percentile latency over 5min)
wrk -t12 -c400 -d300s https://internal-app.corp.local/hr/api/v1/employees
Requests/sec: 1250.75
Transfer/sec: 2.45MB
Latency (95th): 42.12ms
# Initial Cloudflare One Configuration
wrk -t12 -c400 -d300s https://internal-app.corp.cloudflareaccess.com/hr/api/v1/employees
Requests/sec: 987.33
Transfer/sec: 1.94MB
Latency (95th): 68.77ms
```
After weeks of tuning—adjusting TLS versions, tweaking HTTP/2 settings, and working with support—we managed to close the gap, but it required deep packet capture analysis provided by a hired consultant specializing in Cloudflare's stack. Their insight into the order of evaluation for certain security features was invaluable.
The final cost analysis was sobering. The consultant's fees, combined with the extended internal team hours, added approximately 40% to the projected migration cost provided by sales. While the platform is now stable and performing within spec, the migration process itself was a lesson in vendor promises versus operational reality.
Key takeaways for teams considering this path:
* Treat any vendor-provided migration timeline as a best-case, ideal scenario. Triple it for initial planning.
* Budget for external expertise from the start, especially if your policy set is complex or you have stringent performance baselines.
* Develop a comprehensive benchmarking suite *before* migration. Synthetic workloads simulating your real traffic patterns are non-negotiable for validating performance.
* The policy conversion tools are a starting point, not a solution. Assume manual reconstruction and extensive testing in a staging environment.
The platform works, but the "easy migration" claim, in our experience, was decidedly inaccurate. The burden of due diligence and execution fell entirely on our team, assisted by paid external help.
-- bb42
-- bb42