A company gives a payroll vendor access to an internal web app for two weeks each quarter. For years, the vendor signed into a VPN and reached the app across a private subnet. The network team wants to remove that route, but nobody has documented the app’s secondary hostname or the export tool that support staff launch from their laptops. Switching access in one weekend could close the subnet and leave payroll unable to finish.
Zero Trust Network Access (ZTNA) changes the access decision from entry to a network toward permission to reach a particular resource under defined conditions. A sound VPN migration starts by finding the resources people actually need. It proceeds app by app, proving both that the right users can work and that excluded users and devices lose the routes they previously had.
Draw the resource boundary first
Define an app in operational terms. Write down its hostnames, ports, protocols, identity provider, dependencies and owners. A modern browser application may have a clean entry point. An older workflow may call an export service, rely on internal DNS or send callbacks from a service account. Map the paths that are genuinely user access, then separate them from machine-to-machine communication and administrative recovery.
The NIST zero trust architecture describes policy decisions and enforcement in terms of resources, subjects and context. A team can apply that principle by identifying where policy is decided, where traffic is enforced and what evidence informs the decision. The access route is credible when you can trace a request through those pieces and explain the outcome afterward. NIST Zero Trust Architecture
Ask application owners for an ordinary business transaction they can observe. A successful login is a weak test for payroll. A better test runs through a realistic export using approved test data, then confirms that an unrelated app cannot be reached from the same endpoint. Repeat the transaction with the identities and devices that produce different expected decisions.
Use browser and client paths deliberately
Browser-based access can suit contractor access to an internal web interface. It may keep rollout simple when the user cannot install company software. Browser compatibility, redirects, uploads and downloads still need testing. Define how the product identifies a user on a shared machine and what information the administrator can reasonably derive about that device.
Installed clients can serve workflows that need more than a browser, with support varying by product and application design. They introduce onboarding, update and support work. Check DNS behavior and routing on corporate Wi-Fi, home broadband and networks that require a captive portal. A device management rollout can determine the schedule even when configuring the access policy takes minutes.
Cloudflare’s documentation provides an example of connecting a private application through a tunnel and using access policies to define who can reach it. Its application guidance distinguishes options based on how a device reaches the resource. That architecture is worth considering when teams want to make an application reachable without publishing a conventional inbound listener. Validate the app type and endpoint requirements against the actual workflow. Cloudflare One private app setup
One practical migration spreadsheet has a column for browser access, a column for client access and a column for dependencies that require separate handling. It also records owner approval and the date when the old route can be removed. Attach app-level acceptance tests to that inventory so it remains usable after the initial design meetings.
Treat device and identity signals as dependencies
Device posture can make an access decision depend on whether a device is managed, registered or meeting a specific endpoint requirement. Every signal has a source, a time when it last changed and a behavior when that source becomes unavailable. Decide how long the team will rely on an old result and which apps can tolerate an exception. Have identity and endpoint teams agree on those definitions.
Test a changed condition within a live session. Disable a test user or put a test device outside policy and observe when access changes. Some decisions occur at sign-in, some at session renewal and some through another mechanism. Measure the delay in your deployment and make sure the logs allow support to explain it. Separate the time to disable the account from the time existing traffic actually stops.
Keep emergency administration distinct from routine third-party access. Identify a controlled path for administrators when identity integration, device services or a connector fails. Exercise it with accountable authorization and record how the team will monitor its use. In the pilot, include a recovery scenario alongside the normal workflow.
Move traffic in reversible waves
Start with one app and a representative group that can give prompt feedback. Keep the old route during a defined observation period, then remove it for those users and verify the change directly. Users who retain both routes can quietly fall back to the VPN, hiding a dependency until the final cutover. A denial test from the old route is part of verifying the migration.
For each wave, decide what happens when a connector or gateway becomes unreachable. Test redundancy during a business transaction, including whether existing sessions reconnect and which log records the event. Have support teams practice distinguishing an identity error from a connector failure and a legacy app dependency. Document a rollback trigger in advance so a serious incident does not require an architectural debate.
| Test | Record before the VPN route closes |
|---|---|
| Intended user completes a realistic task | Identity, application path, outcome and access event |
| User outside the approved group attempts access | Denial and the rule responsible |
| Device loses the required posture | Delay until the policy takes effect |
| Approved connector fails | User experience, recovery time and alert destination |
| Previous route is tested after removal | Outcome and any remaining route to the resource |
Evaluate ongoing ownership
A small deployment may only need a short roster and one app owner. An enterprise deployment needs a repeatable process for onboarding, changing and retiring applications. Ask who can publish policies, who approves new resources and how teams inspect changes. An identity group with hundreds of members is an easy shortcut that can recreate the original access problem behind a different interface.
Evaluate pricing against your mix of employees, guests, administrators, sites and connectors. Ask how logs can be exported and correlated with endpoint and identity events. Include support time for client installation and expired devices. During evaluation, have a person outside the implementation team troubleshoot a denied session using the tools they will actually receive.
Measure progress by routes retired and work verified. A production migration might close payroll first, leave a legacy administrative flow on tightly scoped access for a while and schedule the remaining dependency for remediation. Keep the conditions that justify each exception in the migration inventory. That gives the team a path to smaller access boundaries and a way to explain what changed for every user population.
Watch for access that moves outside the app
Payroll support staff might use a locally installed database viewer during month-end close. The payroll website can pass every acceptance test while this separate tool retains broad access to the old network. Ask support to walk through a late correction on a test record. Watch which systems they open and which identity each system sees. Then decide whether to broker the viewer directly, replace that workflow or retain an explicitly scoped administrative route.
Record who owns cleanup for each residual path. During the first week after cutover, compare successful ZTNA sessions with denied attempts and help desk cases, and investigate surprising differences. A resource that nobody can reach and a retired resource can look alike in telemetry. Checking with the owner turns those observations into a reliable decommissioning decision.
The payroll vendor’s acceptance test is simple. An approved person completes the export from the intended device and session, an excluded person gets a traceable denial and the old route cannot reach the resource. When those three results agree, there is enough evidence to remove the VPN access for that workflow.