Alright team, let's have a real talk about legacy applications. You know the ones—the internal Java monstrosity from 2012, the bespoke procurement portal that only works in IE compatibility mode, the on-prem reporting tool that's never heard of SAML. We can't just forklift them into the cloud, and wrapping them in a traditional VPN feels like giving everyone a master key to the castle.
I've just come off a successful (and surprisingly fast) implementation for a client with a portfolio of 15 such "heritage" apps. We used an agentless ZTNA gateway, and had core access working in five business days. The key was shifting the mindset: we're not *modernizing the apps*, we're *modernizing access to them*. Here’s the practical blueprint we followed, scars and all.
**Phase 1: The Inventory & Mapping (Day 1-2)**
Don't overcomplicate this. We created a simple spreadsheet with:
* Application Name & Internal URL/IP:Port
* The *exact* authentication method it supports (e.g., HTML form, basic auth, none)
* Any client-side dependencies (specific Java version, ActiveX, etc.)
* The user groups (AD/LDAP) that need access.
This is where most teams stumble—they try to document every possible nuance. For access, you need the *gateway requirements*, not a full audit.
**Phase 2: Gateway Configuration & Identity Hook (Day 3-4)**
We stood up the agentless ZTNA gateway (vendor-agnostic, but think Zscaler Private Access, Citrix Secure Private Access, or similar) as a virtual appliance in the same data center as the apps. The magic is in the connectors.
1. We pointed it at our existing IdP (Azure AD in this case). This is non-negotiable. Your source of truth for identity must be your modern IdP.
2. For each app, we configured a "resource" in the gateway. This involved giving it the internal URL and, crucially, teaching it how to handle the app's legacy auth. For a form-based app, this meant using the gateway's "single sign-on" feature to inject credentials post-authentication. For one app with no auth, we used the gateway to enforce AD group membership *before* granting the TCP connection.
The battle scar here? We initially tried to make the gateway handle an app that required a persistent Java applet. We pivoted after half a day and presented that app via a remote browser isolation (RBI) session instead. Know when to switch tactics.
**Phase 3: Policy & Pilot (Day 5)**
This is where Zero Trust becomes real. We built policies like:
* "Members of AD Group 'Finance' can reach the legacy Java app at legacy-app-finance.corp.internal, but only from a managed device with an endpoint protection certificate present."
* "Contractors in Group 'External-Vendors' can access the procurement portal, but access is terminated after 8 hours and requires re-authentication."
We then ran a controlled pilot with 10 users. The feedback was overwhelmingly about the *user experience*—they loved the clean, web-based portal and not having to connect a clunky VPN client. The tech just worked.
**Why This Over a VPN?**
* No network-layer access. Users get an HTML5 tunnel to *that specific app*, not a route into the entire subnet.
* The apps remain untouched, in their cozy on-prem home.
* You get logging and analytics on *application access*, not just network connections.
* User onboarding/offboarding is instantaneous via the IdP.
The goal isn't perfection. It's *material risk reduction* in a timeframe the business will actually tolerate. You can iterate on policies and add more granular controls (like in-session recording) later. But getting those legacy apps out of the VPN and under a Zero Trust access model in a week? That's a game-changing win.
Implementation is 80% process, 20% tool.