Cloudflare Access migration guide
Use this guide to migrate private applications to Cloudflare Access. It covers application inventory, IdP integration, Access policy design, service tokens, admin access, contractor access, pilot validation, logs, rollback, and support readiness.
Use this guide to migrate private applications to Cloudflare Access. It covers application inventory, IdP integration, Access policy design, service tokens, admin access, contractor access, pilot validation, logs, rollback, and support readiness.
Topics: cloudflare, resource, cloudflare, access, migration, guide
Machine-readable context: /ai-index.json
Step by step
Implementation steps
- 1
Inventory the private applications to migrate — internal web apps, admin portals, dashboards, and internal tools — and record their hostnames, current authentication method, and who needs access to each.
- 2
Integrate the identity provider with Cloudflare Access (SAML or OIDC), configure the login methods, and confirm the identity groups that Access policies will reference.
- 3
Decide how each application is exposed to Access: public hostname proxied through Cloudflare, or a private app reached via a cloudflared tunnel so the origin is never directly exposed.
- 4
Design Access policies per application using identity, group membership, and device posture, and plan for non-human access with service tokens where automation or APIs must reach the app.
- 5
Handle the edge cases explicitly: privileged admin paths, contractor and third-party access (often time-bound), and any apps that can't speak SAML/OIDC and need self-hosted Access with a login page.
- 6
Validate with a pilot group against test identities — confirm correct allow/deny outcomes, group scoping, posture enforcement, and that service-token clients still work — while the legacy VPN or direct access stays available.
- 7
Enable Access activity logging and Logpush so authentication decisions are auditable, then cut applications over in waves with the old access path kept as a fallback per wave.
- 8
Decommission the legacy VPN or direct exposure for each app only after its Access policies are confirmed and a rollback path is documented.
Risk register
Risks to control
An application is put behind Access but its origin remains directly reachable, so the legacy path bypasses the new policy.
Front private apps with a cloudflared tunnel or lock the origin to Cloudflare, and confirm the app cannot be reached around Access before decommissioning the old route.
IdP integration uses the wrong attributes or group claims, so Access policies allow or deny the wrong people.
Validate SAML/OIDC claims and group membership against test identities, covering both allow and deny cases, before any app goes live.
Automation and API clients break because they cannot complete an interactive login.
Issue service tokens for non-human callers and test those clients during the pilot rather than discovering breakage at cutover.
Privileged admin or contractor access is migrated with the same broad policy as everyone else.
Write distinct, tighter policies for admin paths and use time-bound or stricter posture rules for contractor and third-party access.
Apps that don't support SAML/OIDC are left without a clear migration path.
Identify legacy or header-based apps early and plan self-hosted Access with an Access login page or app-token handling for them.
Cutover happens with no audit trail or rollback, so a misconfigured policy locks users out with no record of why.
Enable Access logging and Logpush before go-live, migrate in waves, and keep the prior access path available per wave until policies are confirmed.
Output
Useful deliverables
- A private-application inventory with hostnames, current auth method, and required user populations.
- A documented IdP integration (SAML/OIDC) with login methods and the identity groups Access will use.
- A per-app exposure decision: proxied public hostname versus cloudflared tunnel.
- Access policy designs per application, including admin and contractor cases and service tokens for non-human access.
- A pilot validation report covering allow/deny outcomes, group scoping, posture, and service-token clients.
- Access activity logging and Logpush wired to an audit destination.
- A waved cutover plan with per-wave rollback and legacy-path retirement criteria.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
How does Cloudflare Access replace a VPN for private apps?
Instead of putting users on the network, Access authenticates each request against your identity provider and policy, then brokers access to the specific application — typically via a cloudflared tunnel so the origin is never exposed. Users reach only the apps their policy allows.
How do automated clients and APIs authenticate when an app moves behind Access?
Through service tokens. Non-human callers present a service token (client ID and secret) instead of completing an interactive IdP login, so automation and API integrations keep working once you've issued and tested those tokens.
What about applications that don't support SAML or OIDC?
Those are migrated using self-hosted Access, where Cloudflare presents the login page and enforces policy in front of the app, regardless of whether the app itself speaks a modern SSO protocol. They need to be identified early so they get the right pattern.
Can we migrate apps gradually instead of all at once?
Yes. Apps are best cut over in waves, with the legacy VPN or direct path kept available per wave as a fallback. Each app's old route is retired only after its Access policies are validated and a rollback path is documented.
Nanosek
Migrate apps to Access
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.