From VPN to ZTNA: Building the Business Case, the Timeline, and the Rollout Plan
TL;DR: A practical guide to justifying, sequencing, and executing a VPN-to-ZTNA migration — ROI model, phased timeline, coexistence strategy, and the parts that usually break. See also our ZTNA explainer and how to replace a cloud proxy VPN.
You already know why you want to replace the VPN. The concentrator is a single point of failure, the concentrator vendor keeps raising renewal quotes, and your last penetration test flagged flat lateral movement inside the corporate network. What you don't have yet is a spreadsheet your CFO will sign off on, a sequence of milestones your infrastructure team believes in, and an honest answer to the question "when will the old VPN actually be off?"
This is that plan.
The trigger events
Most Zero Trust Network Access (ZTNA) projects don't start with a strategy deck. They start with an incident:
A hardware VPN appliance hits end-of-life and the refresh quote is six figures.
A contractor's credentials get phished and the attacker pivots freely because everyone on the VPN is on the same /16.
An acquisition closes and IT needs to give 200 new employees access to internal apps in two weeks without merging Active Directory forests.
Someone reads the CISA advisory list and notices four of the last twelve entries are VPN CVEs (Ivanti Connect Secure, Fortinet FortiOS, Cisco ASA, Palo Alto GlobalProtect all shipped critical patches in 2024).
The help desk quietly reports that "VPN won't connect" is now the #1 ticket category.
Any one of these will start the conversation. The problem is that "we should look at ZTNA" doesn't survive a budget review on its own. You need the numbers.
Building the ROI model
The mistake most teams make is comparing the VPN license line to the ZTNA license line and calling it a day. The real savings are in the operational math around the VPN, not the VPN itself.
Here is a defensible model. Replace the placeholder numbers with your own — the point is the structure.
The ROI table
Cost line | Legacy VPN (annual) | ZTNA (annual) | Notes |
|---|---|---|---|
Appliance hardware + support | $80,000 | $0 | Hardware refresh amortized over 3 years; no appliances in a SaaS ZTNA model |
VPN licenses (500 users) | $45,000 | $60,000 | ZTNA per-user is often higher on paper — the savings show up elsewhere |
Help desk tickets ("can't connect to VPN") | $52,000 | $8,000 | Assume 15 min/ticket × $50/hr × 20 tickets/week vs. 3/week |
Bandwidth (backhauled SaaS traffic) | $36,000 | $0 | ZTNA doesn't hairpin Zoom, Salesforce, or Microsoft 365 through HQ |
Contractor / M&A onboarding time | $30,000 | $6,000 | Engineer hours to provision + revoke VPN accounts vs. IdP group membership |
Breach blast radius (estimated) | $250,000 | $75,000 | Insurance actuary estimate of average lateral-movement incident cost, reduced by resource-level isolation |
Certificate + firewall rule management | $18,000 | $0 | No inbound firewall rules to manage in an outbound-only connector model |
Total | $511,000 | $149,000 |
The breach line is where CFOs push back. The way to defend it: pull your cyber insurance renewal questionnaire. If your carrier is asking whether you have network segmentation and least-privilege access, they are already pricing the risk. Reducing lateral movement is a measurable underwriting input, not a hypothetical.
A few notes on the model:
Help desk savings are real and easy to defend. Ask your service desk lead for the ticket category breakdown. In most orgs, VPN connectivity is in the top three ticket types.
Backhaul savings depend on your topology. If your VPN forces all traffic through a central egress, moving SaaS-bound traffic direct-to-internet is a bandwidth line item worth calculating.
Onboarding speed is a soft number that becomes hard during an acquisition. The last time you had to give 50 new people access in a week, how many engineering hours did that consume? That's the baseline.
The ROI math that usually wins
Total cost of ownership over three years, including a one-time migration cost of roughly $40k (professional services, internal hours, coexistence overhead), typically shows a break-even between month 8 and month 14 for organizations between 200 and 2,000 users. Below 200 users the appliance line is smaller and the payback is slower. Above 2,000 users the help desk and breach lines dominate and the payback accelerates.
A realistic phased timeline
Timelines lie. Every vendor pitch shows a four-week rollout. Every real rollout is longer. Here is what actually happens.
Under 500 users
Total: 8 to 12 weeks.
Weeks 1–2: Vendor selection, proof of concept scope, IdP integration test
Weeks 3–4: Deploy connectors in first environment (usually staging or a single VPC), pilot group of 10–20 power users
Weeks 5–7: Migrate resources by team — dev tools first, then internal apps, then admin systems
Weeks 8–10: Coexistence period, monitor VPN usage, chase down the last holdouts
Weeks 11–12: Decommission the VPN concentrator
500 to 2,000 users
Total: 4 to 6 months.
The same phases, but the resource inventory takes longer than you expect and the pilot expands in waves rather than a single cutover. Expect two to three months just for the resource-by-resource migration. Legacy applications with hardcoded IPs will slow you down.
2,000+ users
Total: 9 to 18 months.
At this size the project is a program, not a rollout. You will run VPN and ZTNA in parallel for at least a quarter. Regional offices, contractor populations, and business-unit-specific applications each become mini-projects. Plan for a dedicated project manager and expect a "decommission" milestone that keeps slipping because someone always finds another dependency.
The pattern that works across all sizes: pilot, then resource-by-resource, then coexistence, then decommission. Skipping the coexistence period is where projects fail, because there is always a resource nobody remembered.
Running VPN and ZTNA side by side
Coexistence is not a compromise — it's the safety net that makes the project succeed.
The mechanics are simpler than most teams expect. A ZTNA client like Twingate's runs alongside the VPN client on the same laptop. It intercepts DNS queries that match resources defined in ZTNA policy and assigns them CGNAT IPs in the 100.96.0.0/12 range. Everything else keeps going through the VPN (or direct to the internet). There is no routing conflict because the ZTNA client only handles the traffic it's explicitly configured to handle — split tunneling by resource, not by subnet.
The sequence inside a resource migration:
Define the resource in ZTNA (a hostname, a CIDR, a wildcard domain).
Assign a small pilot group to the resource with the same permissions they had via VPN.
Verify the pilot group can reach the resource with the VPN disconnected.
Roll access to the broader user population.
Remove the resource from VPN firewall rules.
Monitor VPN logs for anyone still trying to reach it via the old path.
Step 6 is the one people skip. Don't. Two weeks of VPN log monitoring will surface the automation scripts, service accounts, and forgotten integrations that nobody documented.
The hard parts
Migrations don't fail on the technology. They fail on the edges.
Legacy applications with hardcoded IPs. An internal app that expects to see clients on a specific /24 will misbehave when clients suddenly show up on CGNAT addresses. The fix is usually source-NAT at the connector level or updating the app's allowlist. Neither is hard, but both take time to find.
Non-web protocols. ZTNA handles arbitrary TCP and UDP, but the operational muscle memory of your team is HTTP-based. SSH, RDP, SMB, database protocols, and internal DNS all work — they just need to be defined as resources rather than assumed. Print servers and legacy thick clients are the usual friction points.
Split DNS. If your VPN was doing DNS resolution for internal .corp domains, you need to think about how those resolve when the VPN is gone. Most ZTNA clients handle this by intercepting matching queries at the client, but you need to explicitly define the domain patterns. Otherwise git.internal.corp starts NXDOMAIN-ing for anyone off VPN.
Device posture gaps. If your VPN was your only device-trust checkpoint, moving to ZTNA is an opportunity to actually enforce posture — but it's also a surface area you now need to define. Which OS versions? Which endpoint agents required? Managed vs. unmanaged? These are policy conversations that should happen before the rollout, not during.
User resistance. The VPN habit is real. People know the icon, they know the reconnect dance, they know which coffee shops have Wi-Fi that breaks it. A ZTNA client that "just works" is genuinely disorienting for the first week. Communicate early. Screenshot the new client. Tell them what to expect.
Resources nobody has owned for years. Every organization has a Jenkins instance, a Grafana dashboard, or a jump box that predates anyone still employed there. The migration forces you to find these. Budget a week just for archaeology.
Vendor questions worth asking
The RFP boilerplate for ZTNA is now mature. These are the questions that actually differentiate vendors:
Where does customer traffic flow? A vendor whose data plane routes your traffic through their servers has decrypted access to it (or has to explain why they don't). Ask specifically whether the vendor can decrypt traffic between your users and your resources.
What happens when the vendor's control plane is down? If new authentications stop working, that's one thing. If existing sessions drop, that's a different thing. Ask for the exact behavior.
Are connectors outbound-only? If a "connector" requires inbound firewall rules, it's a VPN gateway with a different name. Outbound-only is a hard requirement for the architecture to actually be Zero Trust.
How is policy enforced when the client is offline or the control plane is unreachable? Cached policy behavior tells you what happens during real incidents.
What identity providers are supported natively, and what does "supported" mean? SCIM provisioning, group sync latency, and conditional access integration are all different things.
What's the client's behavior on unmanaged devices? Contractors, personal phones, and browser-only access all have different answers.
What are the actual per-user costs at your projected 3-year headcount? Not the list price. The renewal quote.
Can you run a 30-day proof of concept in our environment at no cost? The answer should be yes.
What a good proof of concept proves
A PoC is not a demo. It's a scoped, time-boxed test of the specific scenarios your migration will hit. A useful PoC proves:
Your IdP integration works with your actual conditional access policies, not a test tenant.
At least one non-web resource (SSH to a jump host, RDP to a Windows server, a database) works end-to-end for pilot users.
Device posture checks fire correctly on both managed and unmanaged devices.
Failover behavior is what the vendor claims — pull the plug on a connector and watch what happens.
Admin workflow scales — creating a resource, assigning a group, and revoking access should take minutes, not a change ticket.
If the PoC only proves that users can reach an internal web app, you haven't tested anything the sales demo didn't already show you.
What "done" looks like, and how to decommission safely
The migration is done when three things are true:
Every business-critical resource is accessible via ZTNA with policy defined.
The VPN has had zero authenticated sessions for two consecutive weeks (excluding the security team's monitoring accounts).
The runbook for adding a new resource or new user goes through ZTNA by default, not the VPN.
Decommissioning is a checklist, not an event:
Freeze new VPN account creation. Any new access request goes through ZTNA.
Reduce the VPN license count to match the shrinking active-user population.
Route VPN authentication logs to your SIEM and alert on any successful login during the wind-down.
Give yourself a 30-day "break glass" window where the VPN is off but the appliance is still racked, in case an emergency surfaces a dependency.
Physically decommission the appliance. Cancel the support contract. Update the network diagram.
Close the change ticket. Take a screenshot of the empty VPN dashboard. You earned it.
Closing
For the technical details on how Twingate's outbound-only connector architecture, dual ACL verification, and resource-level access model work, see the Twingate documentation and our Zero Trust Network Access overview.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
From VPN to ZTNA: Building the Business Case, the Timeline, and the Rollout Plan
TL;DR: A practical guide to justifying, sequencing, and executing a VPN-to-ZTNA migration — ROI model, phased timeline, coexistence strategy, and the parts that usually break. See also our ZTNA explainer and how to replace a cloud proxy VPN.
You already know why you want to replace the VPN. The concentrator is a single point of failure, the concentrator vendor keeps raising renewal quotes, and your last penetration test flagged flat lateral movement inside the corporate network. What you don't have yet is a spreadsheet your CFO will sign off on, a sequence of milestones your infrastructure team believes in, and an honest answer to the question "when will the old VPN actually be off?"
This is that plan.
The trigger events
Most Zero Trust Network Access (ZTNA) projects don't start with a strategy deck. They start with an incident:
A hardware VPN appliance hits end-of-life and the refresh quote is six figures.
A contractor's credentials get phished and the attacker pivots freely because everyone on the VPN is on the same /16.
An acquisition closes and IT needs to give 200 new employees access to internal apps in two weeks without merging Active Directory forests.
Someone reads the CISA advisory list and notices four of the last twelve entries are VPN CVEs (Ivanti Connect Secure, Fortinet FortiOS, Cisco ASA, Palo Alto GlobalProtect all shipped critical patches in 2024).
The help desk quietly reports that "VPN won't connect" is now the #1 ticket category.
Any one of these will start the conversation. The problem is that "we should look at ZTNA" doesn't survive a budget review on its own. You need the numbers.
Building the ROI model
The mistake most teams make is comparing the VPN license line to the ZTNA license line and calling it a day. The real savings are in the operational math around the VPN, not the VPN itself.
Here is a defensible model. Replace the placeholder numbers with your own — the point is the structure.
The ROI table
Cost line | Legacy VPN (annual) | ZTNA (annual) | Notes |
|---|---|---|---|
Appliance hardware + support | $80,000 | $0 | Hardware refresh amortized over 3 years; no appliances in a SaaS ZTNA model |
VPN licenses (500 users) | $45,000 | $60,000 | ZTNA per-user is often higher on paper — the savings show up elsewhere |
Help desk tickets ("can't connect to VPN") | $52,000 | $8,000 | Assume 15 min/ticket × $50/hr × 20 tickets/week vs. 3/week |
Bandwidth (backhauled SaaS traffic) | $36,000 | $0 | ZTNA doesn't hairpin Zoom, Salesforce, or Microsoft 365 through HQ |
Contractor / M&A onboarding time | $30,000 | $6,000 | Engineer hours to provision + revoke VPN accounts vs. IdP group membership |
Breach blast radius (estimated) | $250,000 | $75,000 | Insurance actuary estimate of average lateral-movement incident cost, reduced by resource-level isolation |
Certificate + firewall rule management | $18,000 | $0 | No inbound firewall rules to manage in an outbound-only connector model |
Total | $511,000 | $149,000 |
The breach line is where CFOs push back. The way to defend it: pull your cyber insurance renewal questionnaire. If your carrier is asking whether you have network segmentation and least-privilege access, they are already pricing the risk. Reducing lateral movement is a measurable underwriting input, not a hypothetical.
A few notes on the model:
Help desk savings are real and easy to defend. Ask your service desk lead for the ticket category breakdown. In most orgs, VPN connectivity is in the top three ticket types.
Backhaul savings depend on your topology. If your VPN forces all traffic through a central egress, moving SaaS-bound traffic direct-to-internet is a bandwidth line item worth calculating.
Onboarding speed is a soft number that becomes hard during an acquisition. The last time you had to give 50 new people access in a week, how many engineering hours did that consume? That's the baseline.
The ROI math that usually wins
Total cost of ownership over three years, including a one-time migration cost of roughly $40k (professional services, internal hours, coexistence overhead), typically shows a break-even between month 8 and month 14 for organizations between 200 and 2,000 users. Below 200 users the appliance line is smaller and the payback is slower. Above 2,000 users the help desk and breach lines dominate and the payback accelerates.
A realistic phased timeline
Timelines lie. Every vendor pitch shows a four-week rollout. Every real rollout is longer. Here is what actually happens.
Under 500 users
Total: 8 to 12 weeks.
Weeks 1–2: Vendor selection, proof of concept scope, IdP integration test
Weeks 3–4: Deploy connectors in first environment (usually staging or a single VPC), pilot group of 10–20 power users
Weeks 5–7: Migrate resources by team — dev tools first, then internal apps, then admin systems
Weeks 8–10: Coexistence period, monitor VPN usage, chase down the last holdouts
Weeks 11–12: Decommission the VPN concentrator
500 to 2,000 users
Total: 4 to 6 months.
The same phases, but the resource inventory takes longer than you expect and the pilot expands in waves rather than a single cutover. Expect two to three months just for the resource-by-resource migration. Legacy applications with hardcoded IPs will slow you down.
2,000+ users
Total: 9 to 18 months.
At this size the project is a program, not a rollout. You will run VPN and ZTNA in parallel for at least a quarter. Regional offices, contractor populations, and business-unit-specific applications each become mini-projects. Plan for a dedicated project manager and expect a "decommission" milestone that keeps slipping because someone always finds another dependency.
The pattern that works across all sizes: pilot, then resource-by-resource, then coexistence, then decommission. Skipping the coexistence period is where projects fail, because there is always a resource nobody remembered.
Running VPN and ZTNA side by side
Coexistence is not a compromise — it's the safety net that makes the project succeed.
The mechanics are simpler than most teams expect. A ZTNA client like Twingate's runs alongside the VPN client on the same laptop. It intercepts DNS queries that match resources defined in ZTNA policy and assigns them CGNAT IPs in the 100.96.0.0/12 range. Everything else keeps going through the VPN (or direct to the internet). There is no routing conflict because the ZTNA client only handles the traffic it's explicitly configured to handle — split tunneling by resource, not by subnet.
The sequence inside a resource migration:
Define the resource in ZTNA (a hostname, a CIDR, a wildcard domain).
Assign a small pilot group to the resource with the same permissions they had via VPN.
Verify the pilot group can reach the resource with the VPN disconnected.
Roll access to the broader user population.
Remove the resource from VPN firewall rules.
Monitor VPN logs for anyone still trying to reach it via the old path.
Step 6 is the one people skip. Don't. Two weeks of VPN log monitoring will surface the automation scripts, service accounts, and forgotten integrations that nobody documented.
The hard parts
Migrations don't fail on the technology. They fail on the edges.
Legacy applications with hardcoded IPs. An internal app that expects to see clients on a specific /24 will misbehave when clients suddenly show up on CGNAT addresses. The fix is usually source-NAT at the connector level or updating the app's allowlist. Neither is hard, but both take time to find.
Non-web protocols. ZTNA handles arbitrary TCP and UDP, but the operational muscle memory of your team is HTTP-based. SSH, RDP, SMB, database protocols, and internal DNS all work — they just need to be defined as resources rather than assumed. Print servers and legacy thick clients are the usual friction points.
Split DNS. If your VPN was doing DNS resolution for internal .corp domains, you need to think about how those resolve when the VPN is gone. Most ZTNA clients handle this by intercepting matching queries at the client, but you need to explicitly define the domain patterns. Otherwise git.internal.corp starts NXDOMAIN-ing for anyone off VPN.
Device posture gaps. If your VPN was your only device-trust checkpoint, moving to ZTNA is an opportunity to actually enforce posture — but it's also a surface area you now need to define. Which OS versions? Which endpoint agents required? Managed vs. unmanaged? These are policy conversations that should happen before the rollout, not during.
User resistance. The VPN habit is real. People know the icon, they know the reconnect dance, they know which coffee shops have Wi-Fi that breaks it. A ZTNA client that "just works" is genuinely disorienting for the first week. Communicate early. Screenshot the new client. Tell them what to expect.
Resources nobody has owned for years. Every organization has a Jenkins instance, a Grafana dashboard, or a jump box that predates anyone still employed there. The migration forces you to find these. Budget a week just for archaeology.
Vendor questions worth asking
The RFP boilerplate for ZTNA is now mature. These are the questions that actually differentiate vendors:
Where does customer traffic flow? A vendor whose data plane routes your traffic through their servers has decrypted access to it (or has to explain why they don't). Ask specifically whether the vendor can decrypt traffic between your users and your resources.
What happens when the vendor's control plane is down? If new authentications stop working, that's one thing. If existing sessions drop, that's a different thing. Ask for the exact behavior.
Are connectors outbound-only? If a "connector" requires inbound firewall rules, it's a VPN gateway with a different name. Outbound-only is a hard requirement for the architecture to actually be Zero Trust.
How is policy enforced when the client is offline or the control plane is unreachable? Cached policy behavior tells you what happens during real incidents.
What identity providers are supported natively, and what does "supported" mean? SCIM provisioning, group sync latency, and conditional access integration are all different things.
What's the client's behavior on unmanaged devices? Contractors, personal phones, and browser-only access all have different answers.
What are the actual per-user costs at your projected 3-year headcount? Not the list price. The renewal quote.
Can you run a 30-day proof of concept in our environment at no cost? The answer should be yes.
What a good proof of concept proves
A PoC is not a demo. It's a scoped, time-boxed test of the specific scenarios your migration will hit. A useful PoC proves:
Your IdP integration works with your actual conditional access policies, not a test tenant.
At least one non-web resource (SSH to a jump host, RDP to a Windows server, a database) works end-to-end for pilot users.
Device posture checks fire correctly on both managed and unmanaged devices.
Failover behavior is what the vendor claims — pull the plug on a connector and watch what happens.
Admin workflow scales — creating a resource, assigning a group, and revoking access should take minutes, not a change ticket.
If the PoC only proves that users can reach an internal web app, you haven't tested anything the sales demo didn't already show you.
What "done" looks like, and how to decommission safely
The migration is done when three things are true:
Every business-critical resource is accessible via ZTNA with policy defined.
The VPN has had zero authenticated sessions for two consecutive weeks (excluding the security team's monitoring accounts).
The runbook for adding a new resource or new user goes through ZTNA by default, not the VPN.
Decommissioning is a checklist, not an event:
Freeze new VPN account creation. Any new access request goes through ZTNA.
Reduce the VPN license count to match the shrinking active-user population.
Route VPN authentication logs to your SIEM and alert on any successful login during the wind-down.
Give yourself a 30-day "break glass" window where the VPN is off but the appliance is still racked, in case an emergency surfaces a dependency.
Physically decommission the appliance. Cancel the support contract. Update the network diagram.
Close the change ticket. Take a screenshot of the empty VPN dashboard. You earned it.
Closing
For the technical details on how Twingate's outbound-only connector architecture, dual ACL verification, and resource-level access model work, see the Twingate documentation and our Zero Trust Network Access overview.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
From VPN to ZTNA: Building the Business Case, the Timeline, and the Rollout Plan
TL;DR: A practical guide to justifying, sequencing, and executing a VPN-to-ZTNA migration — ROI model, phased timeline, coexistence strategy, and the parts that usually break. See also our ZTNA explainer and how to replace a cloud proxy VPN.
You already know why you want to replace the VPN. The concentrator is a single point of failure, the concentrator vendor keeps raising renewal quotes, and your last penetration test flagged flat lateral movement inside the corporate network. What you don't have yet is a spreadsheet your CFO will sign off on, a sequence of milestones your infrastructure team believes in, and an honest answer to the question "when will the old VPN actually be off?"
This is that plan.
The trigger events
Most Zero Trust Network Access (ZTNA) projects don't start with a strategy deck. They start with an incident:
A hardware VPN appliance hits end-of-life and the refresh quote is six figures.
A contractor's credentials get phished and the attacker pivots freely because everyone on the VPN is on the same /16.
An acquisition closes and IT needs to give 200 new employees access to internal apps in two weeks without merging Active Directory forests.
Someone reads the CISA advisory list and notices four of the last twelve entries are VPN CVEs (Ivanti Connect Secure, Fortinet FortiOS, Cisco ASA, Palo Alto GlobalProtect all shipped critical patches in 2024).
The help desk quietly reports that "VPN won't connect" is now the #1 ticket category.
Any one of these will start the conversation. The problem is that "we should look at ZTNA" doesn't survive a budget review on its own. You need the numbers.
Building the ROI model
The mistake most teams make is comparing the VPN license line to the ZTNA license line and calling it a day. The real savings are in the operational math around the VPN, not the VPN itself.
Here is a defensible model. Replace the placeholder numbers with your own — the point is the structure.
The ROI table
Cost line | Legacy VPN (annual) | ZTNA (annual) | Notes |
|---|---|---|---|
Appliance hardware + support | $80,000 | $0 | Hardware refresh amortized over 3 years; no appliances in a SaaS ZTNA model |
VPN licenses (500 users) | $45,000 | $60,000 | ZTNA per-user is often higher on paper — the savings show up elsewhere |
Help desk tickets ("can't connect to VPN") | $52,000 | $8,000 | Assume 15 min/ticket × $50/hr × 20 tickets/week vs. 3/week |
Bandwidth (backhauled SaaS traffic) | $36,000 | $0 | ZTNA doesn't hairpin Zoom, Salesforce, or Microsoft 365 through HQ |
Contractor / M&A onboarding time | $30,000 | $6,000 | Engineer hours to provision + revoke VPN accounts vs. IdP group membership |
Breach blast radius (estimated) | $250,000 | $75,000 | Insurance actuary estimate of average lateral-movement incident cost, reduced by resource-level isolation |
Certificate + firewall rule management | $18,000 | $0 | No inbound firewall rules to manage in an outbound-only connector model |
Total | $511,000 | $149,000 |
The breach line is where CFOs push back. The way to defend it: pull your cyber insurance renewal questionnaire. If your carrier is asking whether you have network segmentation and least-privilege access, they are already pricing the risk. Reducing lateral movement is a measurable underwriting input, not a hypothetical.
A few notes on the model:
Help desk savings are real and easy to defend. Ask your service desk lead for the ticket category breakdown. In most orgs, VPN connectivity is in the top three ticket types.
Backhaul savings depend on your topology. If your VPN forces all traffic through a central egress, moving SaaS-bound traffic direct-to-internet is a bandwidth line item worth calculating.
Onboarding speed is a soft number that becomes hard during an acquisition. The last time you had to give 50 new people access in a week, how many engineering hours did that consume? That's the baseline.
The ROI math that usually wins
Total cost of ownership over three years, including a one-time migration cost of roughly $40k (professional services, internal hours, coexistence overhead), typically shows a break-even between month 8 and month 14 for organizations between 200 and 2,000 users. Below 200 users the appliance line is smaller and the payback is slower. Above 2,000 users the help desk and breach lines dominate and the payback accelerates.
A realistic phased timeline
Timelines lie. Every vendor pitch shows a four-week rollout. Every real rollout is longer. Here is what actually happens.
Under 500 users
Total: 8 to 12 weeks.
Weeks 1–2: Vendor selection, proof of concept scope, IdP integration test
Weeks 3–4: Deploy connectors in first environment (usually staging or a single VPC), pilot group of 10–20 power users
Weeks 5–7: Migrate resources by team — dev tools first, then internal apps, then admin systems
Weeks 8–10: Coexistence period, monitor VPN usage, chase down the last holdouts
Weeks 11–12: Decommission the VPN concentrator
500 to 2,000 users
Total: 4 to 6 months.
The same phases, but the resource inventory takes longer than you expect and the pilot expands in waves rather than a single cutover. Expect two to three months just for the resource-by-resource migration. Legacy applications with hardcoded IPs will slow you down.
2,000+ users
Total: 9 to 18 months.
At this size the project is a program, not a rollout. You will run VPN and ZTNA in parallel for at least a quarter. Regional offices, contractor populations, and business-unit-specific applications each become mini-projects. Plan for a dedicated project manager and expect a "decommission" milestone that keeps slipping because someone always finds another dependency.
The pattern that works across all sizes: pilot, then resource-by-resource, then coexistence, then decommission. Skipping the coexistence period is where projects fail, because there is always a resource nobody remembered.
Running VPN and ZTNA side by side
Coexistence is not a compromise — it's the safety net that makes the project succeed.
The mechanics are simpler than most teams expect. A ZTNA client like Twingate's runs alongside the VPN client on the same laptop. It intercepts DNS queries that match resources defined in ZTNA policy and assigns them CGNAT IPs in the 100.96.0.0/12 range. Everything else keeps going through the VPN (or direct to the internet). There is no routing conflict because the ZTNA client only handles the traffic it's explicitly configured to handle — split tunneling by resource, not by subnet.
The sequence inside a resource migration:
Define the resource in ZTNA (a hostname, a CIDR, a wildcard domain).
Assign a small pilot group to the resource with the same permissions they had via VPN.
Verify the pilot group can reach the resource with the VPN disconnected.
Roll access to the broader user population.
Remove the resource from VPN firewall rules.
Monitor VPN logs for anyone still trying to reach it via the old path.
Step 6 is the one people skip. Don't. Two weeks of VPN log monitoring will surface the automation scripts, service accounts, and forgotten integrations that nobody documented.
The hard parts
Migrations don't fail on the technology. They fail on the edges.
Legacy applications with hardcoded IPs. An internal app that expects to see clients on a specific /24 will misbehave when clients suddenly show up on CGNAT addresses. The fix is usually source-NAT at the connector level or updating the app's allowlist. Neither is hard, but both take time to find.
Non-web protocols. ZTNA handles arbitrary TCP and UDP, but the operational muscle memory of your team is HTTP-based. SSH, RDP, SMB, database protocols, and internal DNS all work — they just need to be defined as resources rather than assumed. Print servers and legacy thick clients are the usual friction points.
Split DNS. If your VPN was doing DNS resolution for internal .corp domains, you need to think about how those resolve when the VPN is gone. Most ZTNA clients handle this by intercepting matching queries at the client, but you need to explicitly define the domain patterns. Otherwise git.internal.corp starts NXDOMAIN-ing for anyone off VPN.
Device posture gaps. If your VPN was your only device-trust checkpoint, moving to ZTNA is an opportunity to actually enforce posture — but it's also a surface area you now need to define. Which OS versions? Which endpoint agents required? Managed vs. unmanaged? These are policy conversations that should happen before the rollout, not during.
User resistance. The VPN habit is real. People know the icon, they know the reconnect dance, they know which coffee shops have Wi-Fi that breaks it. A ZTNA client that "just works" is genuinely disorienting for the first week. Communicate early. Screenshot the new client. Tell them what to expect.
Resources nobody has owned for years. Every organization has a Jenkins instance, a Grafana dashboard, or a jump box that predates anyone still employed there. The migration forces you to find these. Budget a week just for archaeology.
Vendor questions worth asking
The RFP boilerplate for ZTNA is now mature. These are the questions that actually differentiate vendors:
Where does customer traffic flow? A vendor whose data plane routes your traffic through their servers has decrypted access to it (or has to explain why they don't). Ask specifically whether the vendor can decrypt traffic between your users and your resources.
What happens when the vendor's control plane is down? If new authentications stop working, that's one thing. If existing sessions drop, that's a different thing. Ask for the exact behavior.
Are connectors outbound-only? If a "connector" requires inbound firewall rules, it's a VPN gateway with a different name. Outbound-only is a hard requirement for the architecture to actually be Zero Trust.
How is policy enforced when the client is offline or the control plane is unreachable? Cached policy behavior tells you what happens during real incidents.
What identity providers are supported natively, and what does "supported" mean? SCIM provisioning, group sync latency, and conditional access integration are all different things.
What's the client's behavior on unmanaged devices? Contractors, personal phones, and browser-only access all have different answers.
What are the actual per-user costs at your projected 3-year headcount? Not the list price. The renewal quote.
Can you run a 30-day proof of concept in our environment at no cost? The answer should be yes.
What a good proof of concept proves
A PoC is not a demo. It's a scoped, time-boxed test of the specific scenarios your migration will hit. A useful PoC proves:
Your IdP integration works with your actual conditional access policies, not a test tenant.
At least one non-web resource (SSH to a jump host, RDP to a Windows server, a database) works end-to-end for pilot users.
Device posture checks fire correctly on both managed and unmanaged devices.
Failover behavior is what the vendor claims — pull the plug on a connector and watch what happens.
Admin workflow scales — creating a resource, assigning a group, and revoking access should take minutes, not a change ticket.
If the PoC only proves that users can reach an internal web app, you haven't tested anything the sales demo didn't already show you.
What "done" looks like, and how to decommission safely
The migration is done when three things are true:
Every business-critical resource is accessible via ZTNA with policy defined.
The VPN has had zero authenticated sessions for two consecutive weeks (excluding the security team's monitoring accounts).
The runbook for adding a new resource or new user goes through ZTNA by default, not the VPN.
Decommissioning is a checklist, not an event:
Freeze new VPN account creation. Any new access request goes through ZTNA.
Reduce the VPN license count to match the shrinking active-user population.
Route VPN authentication logs to your SIEM and alert on any successful login during the wind-down.
Give yourself a 30-day "break glass" window where the VPN is off but the appliance is still racked, in case an emergency surfaces a dependency.
Physically decommission the appliance. Cancel the support contract. Update the network diagram.
Close the change ticket. Take a screenshot of the empty VPN dashboard. You earned it.
Closing
For the technical details on how Twingate's outbound-only connector architecture, dual ACL verification, and resource-level access model work, see the Twingate documentation and our Zero Trust Network Access overview.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Solutions
Solutions
The VPN replacement your workforce will love.
Solutions