Moving a company web app behind the VPN: a cutover walkthrough

Picture the change from the user's side. Someone clicks a bookmark, expects the familiar login page, and instead gets a connection error because the hostname now only answers inside the tunnel. That single moment contains everything the migration plan has to get right: the name, the path, the certificate, the account and the operation behind it. Work through the steps below in that order and the cutover stops being a leap.

Step 1: write down what users do today

Start with the hostname in the address bar, the port, the operations people perform and the accounts they use. If you cannot name the top three operations, you are not ready to close the public entry, because you will not recognize a broken one during acceptance.

Then decide who the private audience is. Employees on the corporate VPN is a start, not an answer. Contractors, support staff and the finance team may all need the application and may not all sit behind the same gateway.

Step 2: separate the tunnel from the login

When the user reaches the application through the VPN, the browser still opens a TLS connection to the application's own endpoint. The certificate has to match that name, and the application still authenticates the account. Nothing about the tunnel replaces either.

This is where migrations quietly go wrong. Someone decides the private address no longer needs a valid certificate, users learn to click through a warning, and the organization has traded a public exposure for a training program in ignoring security prompts. If the application genuinely needs an internal certificate, issue one from the internal authority and distribute the trust properly. That is a controlled change; a warning page is not.

Keep authorization where it already lives. NIST's zero-trust architecture abstract makes the point directly: network location is not a reason to grant a sensitive operation. Being inside the tunnel should not turn a read-only account into an administrator.

Step 3: find the callers who are not employees

Open the application's configuration and list everything that talks to it: the identity provider's callback URL, a payment provider's webhook, a scheduled import, a monitoring probe, a partner's API client. Each is a dependency with an owner, and each will break at a different moment.

Decide a supported path for each one that must remain. A webhook provider cannot join your employee VPN, so either expose a narrowly scoped integration endpoint with its own authentication, or change the integration model. Leaving the whole application public because one callback exists is a choice, and usually the wrong one.

Write each exception down with destination, allowed operation, authentication and owner. A generic VPN account handed to an integration is how an exception becomes permanent. Review the list at the next access review, because integrations outlive the projects that added them. An exception without an expiry date is a permanent design decision nobody made.

Step 4: retire the public route, not just the DNS record

Walk the publishing chain: DNS, load balancer listeners, reverse proxy rules, host firewall, and any alternate name that still points at the old address. Check both address families. Changing the main A record proves almost nothing if an older CNAME or an IPv6 listener still serves the app.

In parallel, confirm the private name resolves inside the tunnel and that the certificate covers the name users will type. A user who has to paste a numeric address has found a symptom, not a workaround.

Scope the VPN audience to the application path. Broad access to the office network swaps one exposure decision for a larger one, and administrative interfaces need their own permitted sources rather than inheriting the user rule.

Step 5: walk the acceptance yourself

Connect as an approved user, open the bookmark, check the certificate, log in and perform one real operation. Then try an account that should not have that operation and confirm it is refused. Then try from a device outside the VPN and confirm the application is unreachable.

Repeat for each retained integration, and read the provider's delivery log rather than assuming a 200 from your own test tool is the same thing. A successful VPN login is not evidence for any of these results.

Step 6: rehearse the bad day

Decide what happens during a tunnel outage: work stops, or another approved access method takes over. Whatever you choose, write it down and test it once, because emergency public reopening as an undocumented recovery mechanism will eventually be performed by someone under pressure.

Keep recovery access for the administrators who maintain the gateway and the application, with an owner and a removal date. Record the change and its reversal conditions in the same place, so a failed migration does not lock out the people who would fix it.

After the cutover, patching, account lifecycle, application authorization and auditing are still yours. The tunnel narrowed the entry; it did not take over any of those jobs.