Retire the VPN without breaking the applications behind it
Every Zero Trust project stalls in the same place: nobody can enumerate what the VPN is actually being used for. We will map it — every application, every user population, every dependency — and hand you a phased Cloudflare migration plan with the risky parts identified up front.
- A complete inventory of what your VPN carries today, including the traffic nobody remembers approving
- A phased ZTNA cutover plan sequenced so the fragile applications go last, not first
- A cost comparison against your current VPN, WAF and appliance renewals
No cost · Roughly three weeks · Vendor-agnostic findings
What you receive
- Application and access inventory
- Identity and device posture review
- Phased cutover plan
- Policy design
The technology is rarely the blocker
ZTNA products are mature. What derails these programs is almost always discovery, sequencing, and organizational risk tolerance.
Nobody knows what the VPN carries
It was deployed for remote desktop access and then quietly became the transport for backups, vendor support tunnels, a legacy ERP client, and three things the person who set them up no longer works here.
The pilot works, the rollout does not
A ZTNA pilot with fifty willing engineers proves nothing about the finance team using a thick client that assumes a flat network and a static IP allowlist.
The renewal clock runs the project
An appliance refresh or a VPN concentrator EOL date forces a decision months before the discovery work needed to make it well has been done.
The business case is never written down
Zero Trust gets funded as a security initiative and then judged on cost. Without a like-for-like comparison against appliance, bandwidth and support spend, it loses that argument.
A migration plan specific enough to execute
Written so your team could run the migration without us — which is the only honest test of whether a plan is real.
Application and access inventory
Everything reachable through the VPN today, grouped by user population, protocol, and how badly it will react to an identity-aware proxy in front of it.
Identity and device posture review
How your IdP, MDM, and existing conditional access policies map onto Cloudflare Access — including where your current group structure will not survive contact with least privilege.
Phased cutover plan
Wave by wave, with the low-risk populations first and the applications most likely to break scheduled last, when the team has learned the platform.
Policy design
Concrete Access policies, service tokens, and WARP posture checks written out — not a diagram with the word "policy" in a box.
Cost model
Cloudflare licensing set against your current VPN concentrators, WAF, DDoS protection, backhaul bandwidth, and the support contracts they carry.
Risk register
The applications, vendor tunnels, and legacy dependencies that will cause a problem, with a mitigation for each — surfaced before the project starts rather than during cutover.
Three weeks, mostly running in the background
The heaviest lift on your side is one workshop and access to read your existing configuration.
Discovery workshop
Your network, security and application owners in one room. We map what is supposed to be true before we go looking at what is.
Configuration review
Read-only review of VPN configuration, firewall policy, IdP group structure and DNS. Nothing is changed and no agents are deployed.
Plan and cost modelling
We build the wave plan, write the Access policies, and model the cost against your current renewals.
Readout
A working session with the plan, the risk register, and the cost model. All documents handed over at the end.
We evaluated six Cloudflare partners. BlackHawk was the only one that could talk architecture, deploy at scale, and operate 24x7.
Not a licensing conversation with a diagram attached
The typical reseller engagement
- Discovery consists of asking how many users you have, so a quote can be produced.
- A reference architecture diagram that would apply equally to any customer.
- The hard applications are discovered during cutover, in front of the business.
- Sold by one team, delivered by another, operated by a third who was never consulted.
- The business case is left for you to assemble after the fact.
A BlackHawk readiness assessment
- Discovery enumerates every application and access path the VPN actually carries.
- A wave plan naming your applications, your user groups, and your problem dependencies.
- A written risk register produced before the project starts, with mitigations attached.
- The architects who plan it deploy it, and the same organization operates it 24x7.
- A cost model set against your real appliance, bandwidth and support renewals.
Questions we get every time
No. The assessment output is a migration plan and a cost model, and both are yours whatever you decide. We are a Cloudflare partner and the plan is built around Cloudflare One because that is the platform we know best and operate at scale — but a meaningful share of what the assessment surfaces is work you should do regardless of platform, like fixing IdP group structure and retiring access paths nobody can justify.
Tell us about your remote access estate
User count, site count, and what your VPN runs on is enough to scope this. A solutions architect will follow up within one business day.
- A senior architect responds within one business day
- Read-only review — nothing in your environment is changed
- Cost model set against your actual current renewals
- The plan is yours to execute with or without us
Want to read the detail first?
Our Cloudflare and Zero Trust work is documented in full across the site. Start there and come back when the renewal clock makes it urgent.