Skip to content
Notifications
Clear all

What's the best way to do a phased rollout without disrupting everyone?

3 Posts
3 Users
0 Reactions
1 Views
(@eval_rookie_42)
Reputable Member
Joined: 4 months ago
Posts: 158
Topic starter   [#17966]

We're considering Perimeter 81 to replace our current VPN for a team of about 80. The idea of zero-trust sounds good, but I'm worried about rolling it out.

I've seen projects fail when they force everyone to switch at once. What's the best practice for a phased rollout here? I'm thinking we could start with just the IT team, but I'm not sure what to test for beyond basic connectivity. Should we focus on specific applications or user groups first? How do you measure if a phase is successful before moving to the next group? Our main goal is better security without hurting productivity.



   
Quote
(@devops_dad_v2)
Estimable Member
Joined: 4 months ago
Posts: 122
 

I manage infrastructure for a 120-person engineering org in fintech. We transitioned from a traditional VPN to a zero-trust network access (ZTNA) model about 18 months ago, running on a combination of Cloudflare Zero Trust and our own proxies for internal apps.

When evaluating a tool like Perimeter 81 for a phased rollout, you're spot on to avoid a big-bang switch. Beyond just the IT team, here are the concrete criteria I'd measure against.

* **Deployment & Integration Effort**: Start by mapping your critical "crown jewel" applications (1-3 max). The initial phase is not about testing user VPN connectivity, but about ensuring these apps work *without* your old VPN's network-level access. You'll need to inventory which internal domains/IPs these apps use and replicate that access in the new system. This config work for 3 apps takes about a week.
* **Where It Can Break (The Gotcha)**: Legacy apps that rely on IP-based whitelisting or non-HTTP protocols (e.g., SSH to internal servers, database GUI clients) are your biggest risk. For your first phase, pick a user group whose workflow is 95% web-based SaaS and internal web apps. This avoids the complexity of setting up TCP tunneling.
* **Measuring Success Per Phase**: Go beyond "can they connect." Track 1) latency to key apps compared to the old VPN (a simple ping test), 2) the number of support tickets related to the new access method, and 3) a simple productivity survey after one week. A phase is successful when tickets are low (<2 per user) and latency is within 115% of the old VPN.
* **Real Cost & Scaling**: For a team of 80, list price is typically $8-12/user/month. The hidden cost is in the identity provider integration (SCIM provisioning) and the time to rebuild any automation that relied on your old VPN's API. Budget 20-30 engineering hours for those integration tasks.

I'd recommend starting with a pilot of 10-15 people in a single department (like Finance or HR) that uses a defined set of web applications. To make a cleaner call, tell us if your team needs access to raw TCP services (like RDP or database ports) and what your primary IdP is (Okta, Azure AD, etc.).



   
ReplyQuote
(@ericd)
Reputable Member
Joined: 1 week ago
Posts: 180
 

Starting with the IT team is a solid instinct, but I'd add a caveat. They're tech-savvy and can troubleshoot, but they also have deep, sometimes unique, access that isn't representative of a regular user. You might miss pain points that a typical marketing or sales person would hit.

Instead, or in addition to IT, I'd pick one small, non-technical department that uses a standard set of apps. That way you're testing both the technology and the clarity of your instructions for regular folks. If they can switch without a spike in support tickets, that's a great success metric right there.

How are you planning to communicate the change and gather their feedback during the pilot? A simple, dedicated Slack channel or a short weekly check-in can catch small frustrations before they become big problems for the wider rollout.


Keep it civil, keep it real.


   
ReplyQuote