So, the sales deck is over and the slide with the "potential savings" looks compelling. They've probably shown you how much you'll save on MPLS circuits and data center firewalls. Before you sign, let's talk about what the invoice actually looks like after the magic wears off.
The transition isn't a clean swap. You're layering a new operational cost (Zscaler) on top of existing infrastructure during a lengthy migration. That overlap period? It's pure cost duplication, and it's never as short as projected. Your network team is still managing the old gear while learning the new console. That's double the labor, and labor is the most ignored line item in these proposals.
Then there's the commitment trap. The discounts are always tied to term length and user count. But what is a "user"? Is it a named user, a concurrent connection, or a device? If your headcount fluctuates or you have a large contractor base, the billing reconciliation becomes a monthly forensic exercise. I've seen orgs get locked into a 3-year commit for 10,000 users, then undergo a divestiture and be stuck paying for 2,000 ghosts. The "savings" evaporate real quick.
Finally, watch the data egress. Zscaler's model means your traffic often hairpins through their nodes. If you have significant traffic between branch offices and cloud regions (like AWS us-east-1), you need to model the latency and the potential for increased cloud data transfer fees. That bill from AWS doesn't care that you're using Zscaler; it just sees more gigabytes crossing availability zones.
Ask for a detailed, line-item TCO model from them that includes your internal migration labor, overlap costs, and a clear definition of billable units. Then compare it to your actual last 12 months of spending, not the list price of your old hardware. If they can't or won't, that's your first red flag.
- cost_observer_42
cost_observer_42
You're absolutely right about the commitment trap being a massive hidden cost. The user definition can change between the initial quote, the contract, and the billing system, and nobody flags it until the first invoice is wrong.
One more thing on that overlap period: you also need to budget for the parallel security tooling. Your existing secure web gateway or firewall subscriptions don't just stop. You're often paying for two sets of URL filtering, malware prevention, and data loss prevention licenses for a year or more. That's a software cost duplication on top of the hardware and labor you mentioned.
Has anyone successfully negotiated a true ramp-up period where the license count aligns with actual migration phases, rather than a flat commitment from day one?
The right tool saves a thousand meetings.
Great point on the parallel security costs. It's a brutal detail.
We pushed for a phased license model. It was a grind, but we got them to agree to a 12-month ramp tied to specific department cutovers. Even then, the "true-up" at the end felt more like a punishment than a reconciliation. The key was having our migration plan in the contract as an exhibit, so the milestones were theirs to miss, not ours. Without that, you're just negotiating with hope.
dk
Great point about locking in a user count before a divestiture. We saw something similar after an acquisition - the acquired company had its own ZIA proxy, so we suddenly had double coverage for a huge group. Took six months of wrangling to merge the contracts without paying for double users.
That labor overlap is real, too. It's not just network team time, it's security ops and help desk. The console might be "unified," but troubleshooting is a whole new skillset. We had to run two playbooks for months.
What did you do about the data egress part? We almost missed that our initial POC traffic was negligible, but production streaming and backup traffic blew out our commit. The bill-back for overages was... not fun.
Data > opinions
You're dead right about labor. It's not just the network team, either. The main hidden cost is app team enablement. Every little internal app with hard coded proxies or cert pinning? That's weeks of dev work you're now funding. The network team's console time is the least of it.
The ghost users after a divestiture is a brutal clause. That's where your legal team needs to get the right to adjust the count, with a penalty floor, not just a flat commit. If you don't, you're paying for an asset you sold.
The data egress part they cut off is the real kicker. POC traffic is nothing. Wait until your backup jobs or video teams start routing through it. The commit is for users, but the overages are for bytes.
Proof in production.
Including the migration plan as a contractual exhibit is the critical detail most miss. That's the difference between a shared project plan and an unenforceable sales promise. However, I'd add a caveat on the penalty structure for missed milestones: ensure the remedy isn't just a credit toward future licenses, which locks you in further, but a true monetary concession.
Your point about the true-up feeling punitive is spot on. We observed the same, where the reconciliation ignored natural user churn and assumed 100% adoption of every deployed department. We had to fight to apply our standard HR-reported headcount attrition rate against the phased commit numbers. Without that, you're paying for theoretical users that never existed.
The data egress cutoff is where they really get you. They'll happily demo with a trickle of web traffic. The second you point your backup VLAN or a video rendering farm at it, the overage charges look like a ransom note.
And nobody budgets for the bandwidth audit team you'll need just to argue those bills.
-- old school