We're planning to migrate remote access for about 500 employees and contractors. Our environment includes SaaS platforms, internal web applications, Windows and Linux administration, several legacy applications, and workloads split between on-premises infrastructure and public cloud. Identity is centralized, but contractor device management and posture checks are inconsistent.
We want to avoid a big-bang migration. The current plan is to inventory applications and users, classify access by protocol and sensitivity, migrate a low-risk web application first, and then move user groups in waves. The main concern is preventing temporary exceptions and duplicate access paths from becoming permanent.
For anyone who has handled a migration at a similar scale, what caused the most trouble during the first phase? Did application discovery, identity-group cleanup, private DNS, endpoint support, legacy protocol compatibility, or user communication require the most effort?
How did you provide emergency administrative access and handle outages when the normal ZTNA path was unavailable?
1 Answer
At this scale, the biggest risk usually isn’t the ZTNA platform itself—it’s leaving duplicate access paths and overly broad identity groups in place indefinitely.
Start by inventorying applications by protocol and sensitivity. Treat anything that cannot use modern authentication as an explicit exception with a named owner and expiration date. Clean up identity groups before migration, especially nested groups and old VPN memberships.
For the first pilot, use one low-risk internal web application and a group of users with managed devices. That lets you validate private DNS, authentication, and posture checks before adding contractors. Contractors should have a separate policy path; if their devices cannot meet the required posture, consider managed access, VDI, or browser isolation instead of assuming unmanaged devices are equivalent to employee endpoints.
Keep a small, monitored break-glass path for emergencies, protected with strong separate credentials or hardware-backed authentication and limited in time. Without an out-of-band administrative option, an outage can lock everyone out.
The most common time sinks are missed applications, private DNS problems, and unclear user communication. Publish the migration schedule clearly, explain the new access portal, and disable the old VPN permissions as soon as each group moves so overlapping access does not become permanent.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures