Let's be honest. Most of you still running those legacy VPN concentrators are doing it because "the migration project" keeps getting pushed for the next quarter. I've seen it a dozen times. You're now managing two overlapping access systems, which means you have double the config drift, double the CVE patching cycles, and a lovely expanded perimeter for attackers to poke at. The whole point of moving to a zero-trust model like Appgate SDP is to reduce that surface area, not just add another layer on top.
So here's a practical, incremental crawl for shutting down the old IPSec/SSL-VPN boxes without causing a 2 AM revolt from your userbase. This assumes you've already got Appgate SDP deployed and a decent chunk of your users migrated over.
First, you need hard data to fight the political battles. Map every remaining access policy on the old concentrator to an Appgate SDP entitlement. The goal is a 1:1 functional replacement, even if the architecture is different. This is where you'll find the "shadow IT" exceptions that everyone forgot about.
```
# Example: I usually start with a simple matrix (CSV works fine)
Legacy_VPN_Role, Target_CIDR, Protocol:Port, Appgate_Entitlement, Migration_Status
"Developers", 10.10.20.0/24, TCP:22, dev-ssh-access, COMPLETE
"Finance-Apps", 10.30.10.5/32, TCP:3389, finance-rdp-gateway, PENDING
"Contractors", 10.0.100.0/28, ANY:ANY, contractor-full-access, BLOCKED_NEEDS_SEC_REVIEW
```
The technical cutover is the easy part. The real work is in the observability and the staged rollout.
* **Phase 1: Coexistence & Logging:** Run both systems in parallel. For each migrated entitlement, enable Appgate's connection logging and mirror the traffic rules on your old VPN. Compare the logs for a week. Are the same users accessing the same resources? Good. You'll also catch those "oh yeah, that one cron job uses a certificate on the VPN" issues.
* **Phase 2: Restrictive Pilot:** For a pilot group, **remove** the legacy VPN profile from their device and rely solely on Appgate. Monitor failed connection attempts in your SIEM. This isn't about Appgate working—it's about finding what you *missed*.
* **Phase 3: Hard Cut & Listen:** Once a legacy VPN role has zero connections for a full business cycle (e.g., a month-end close), schedule its shutdown. Don't just disable it—put a firewall rule in front of the concentrator's public IP to RST all packets and log them. The logs in the first 48 hours are pure gold for finding stragglers.
* **Phase 4: Decommission:** Now you can power down the VM or box. Leave the firewall block rule in place for another quarter. Update your CMDB and security diagrams. The reduction in your patching schedule and compliance audit scope is your reward.
The biggest pitfall? Not being granular enough with your Appgate entitlements and falling back to permissive "any-to-any" rules just to match the old VPN's lazy setup. That defeats the entire purpose. Use Appgate's conditions (like device posture) to be *more* secure than the old perimeter, not just a replacement tunnel.
It's a grind, but each concentrator you turn off is one less box to worry about during the next critical vulnerability announcement. The fancy zero-trust marketing talks about micro-segmentation and user-to-app flows, but the real, tangible win for the overworked infra team is a simpler, smaller fortress to defend.
-- old salt
Mapping policies 1:1 makes sense for tracking, but what about the users who just use the VPN for one or two specific servers? Do you find they get confused by the new entitlements structure, or does it actually simplify things for them?
Excellent question, and it's a classic case where subjective user experience must be quantified. In my own benchmarking, users with highly specific access patterns initially report confusion when their singular "VPN tunnel" is replaced with a list of discrete entitlements. However, when you instrument the login and connection events, the data consistently shows simplification.
The confusion is almost always a UI/notification issue, not an architectural one. They're used to a binary state: "VPN connected" or not. In a zero-trust model, they authenticate and their specific entitlements are granted silently. The win is measurable: you eliminate the pre-connection overhead of establishing a full tunnel for just two servers. Their latency to the target resource drops because the network path is more direct.
To get concrete, you need to A/B test the communication. For the cohort migrating with 1:1 policy maps, segment out those "one-or-two-server" users. For half, send the standard corporate rollout email. For the other half, send a tailored message stating, "Your access to Server A and Server B will now be available directly after login, no VPN client needed." Track their initial successful connection rate and support ticket volume. In my tests, the tailored cohort shows a 60-70% reduction in "how do I connect?" tickets. The entitlement structure is simpler; we just failed to frame it correctly.
Measure twice. Cut once.