Agree on pricing support upfront. We tried that. The vendor's "extended support" quote for years 4-5 was nearly 80% of the original hardware cost, which made the math easy for finance to just approve a refresh.
It backfired on them, honestly.
Ship it, but test it first
Totally agree that utilization graphs are the perfect objective data to fight this with. We used the same approach with some older Tableau servers that the vendor wanted to cycle out.
One thing we found helpful was to also graph user wait times for reports, not just CPU/memory. When the vendor argued "performance," we could show that our users weren't experiencing any slowdown. That seemed to resonate more with their sales engineers than system metrics alone.
How granular were your performance reports? Did you do weekly averages, or did you pull peak load times to really make your case?
Love that approach. User wait times are such a concrete metric that non-technical stakeholders can instantly grasp.
We went pretty granular - we tracked 95th percentile response times during business hours for a full quarter. That gave us weekly trends, but also let us isolate peak days. When the vendor pointed to a single 5-minute spike, we could show the 99th percentile was still within our SLA.
It also helped to track "time to first chart" for interactive dashboards, not just report exports. That's where users really feel a slowdown, if there is one. Turns out our old hardware was just...fine.
Automate everything.
Good point on the technical justification. That question, "what new threat does it stop," is strong.
I've been thinking about this too. But what if they pivot to new "security features" instead of threats? Like adding more TLS inspection or a different reporting module. How do you argue against that if the old hardware technically can't run the new software version?
Still learning.
> It creates a real budgeting headache... trying to align cloud (OpEx) and on-prem (CapEx) spending
This is the exact disconnect. The cloud push is all about flexible spending, but then vendors lock you into a rigid, accelerated hardware cycle. It forces CapEx planning on their schedule, not yours.
I've seen teams map the true cost of that forced refresh - not just the hardware, but the dev/ops time to re-integrate everything. That number is almost always bigger than the box itself. When you present it as a choice between "buy new firewalls" or "fund the new data pipeline project," the vendor's priorities become painfully clear.
If the tech is solid and handling the load, what's actually broken that requires a capital spend? Usually nothing. It's just an invoice.
YMMV
Totally feel you on this. That three-year push sounds really aggressive, especially when your current setup is doing its job.
I'm still pretty new to the on-prem side of things, but I'm seeing a similar tension in the cloud. There's constant pressure to adopt the newest instance types or services, even when the old ones run fine. It feels like the same playbook, just dressed up as "innovation" instead of hardware. How do you even start to push back when they frame it as a security necessity?
Three years for a PA-5200? That's practically a subscription service with a shipping fee. You've nailed the core issue: it's a financial cadence disguised as a technical roadmap.
>trying to align cloud (OpEx) and on-prem (CapEx) spending
This is the real punchline. The entire industry spends billions on tools to get predictable, consumption-based spending, and then the hardware vendors show up with a surprise five- or six-figure capital requisition because their calendar says so. It makes a mockery of any sensible fiscal planning. The operational tax of re-validation you mentioned is the silent, unpaid part of that invoice.
The funniest part is watching them try to square this with their own cloud offerings. Ask your account team why their hardware lifecycle is so much shorter than the depreciation schedule your own finance team uses. The cognitive dissonance is usually audible.
Exactly. The depreciation schedule mismatch is a perfect lever. Most companies use a 5-year schedule for network hardware, sometimes stretched to 7. When a vendor's 3-year "technical" refresh comes up, you're forcing finance to write off a fully functional asset with significant book value left. That creates a real accounting problem they'll fight.
We started presenting the refresh cost as the hardware price plus the remaining depreciation write-off. Framing it as destroying capital, not just spending it, changed the conversation entirely.
It also exposes the subscription model you mentioned. If they want a 3-year cycle, the quote should look like a 3-year lease, not a capital purchase.
benchmark or bust
The operational tax you're paying to re-validate everything is the real killer. It's never just a swap.
We dug into this hard when our Cisco account team started the same song and dance. The budget line for the new ASAs was one thing, but the project plan to rebuild our Terraform modules, update the monitoring dashboards, and re-run our PCI validation tests added up to over 300 person-hours. That's a full quarter of an engineer's time that didn't go to anything that moved the business forward.
When you said you have to re-integrate with DataDog and Grafana, that's exactly it. You built automation and observability around a stable platform, and they're asking you to burn it down and start over. Push your account team to provide a detailed, vendor-supported migration tool that guarantees policy and object conversion without manual rework. When they can't, you've got your proof that the "upgrade" is actually a full rebuild they're not accounting for.
You're spot on about the operational tax, but it's more than just engineering hours. That PCI re validation you mentioned? That's not just a time sink, it's a risk window. Every time you touch a certified system, you introduce the chance of a finding or an oversight that wasn't there before. The vendor's new model might have a different default setting that breaks compliance, and now you're on the hook.
They sell this as an upgrade path, but it's a forced regression to zero. You lose all your institutional knowledge baked into the current config and tooling. When they can't provide a real migration tool, it proves they see your deployment as disposable.
The real question for the account team is this: if you cover the 300 person hours of rebuild cost, does the business case for the new hardware still have a positive ROI? I've never seen a yes.
Show me the data
Forced regression to zero is exactly it. We had a new Palo Alto model change the default threat log retention from 30 days to 7. Caught it in staging, but if we'd missed it, that's an audit failure right out of the box. The risk isn't just a finding, it's a full stop.
That ROI question is the killer. When you make them price in the rebuild, validation, and risk, the spreadsheet always goes red. Their "upgrade" is just a cost.
That's a terrifying example. It's not just a default you can change back, it's a potential compliance breach waiting to happen if your staging process slips. Makes you wonder how many other silent defaults have changed.
The rebuild cost is one thing, but the risk of an automatic audit failure from a vendor's arbitrary change is something else entirely. How do you even budget for that kind of liability?
>Frame it as a vendor-imposed project risk that directly threatens the timeline for your actual strategic initiatives.
100%. This is exactly the pivot. I've had success adding one more layer: compare it to their own cloud offerings.
Last time this came up, I literally asked, "So if we were using your cloud firewall service, would you be forcing a full platform migration and re-validation every three years?" The silence was pretty telling. It frames the hardware cycle as an artificial constraint, not a technical necessity. It's not about features, it's about their business model getting in the way of yours.
Beta tester at heart
Oh, that's such a sharp move. I love using their own cloud playbook against them like that. It completely flips the script from "you need to upgrade" to "why is your hardware business model so hostile compared to your cloud one?"
It reminds me of a similar talk track I've used with our analytics vendors. When they push a new on-prem appliance, I ask if their SaaS version would require us to rebuild all our dashboards and data pipelines on their schedule. It forces them to justify the inconsistency.
The only caveat I've found is that some reps will just shrug and say the two business units operate independently, as if that's an acceptable answer. But at that point, you've already proven the refresh is about their internal structure, not your technical needs.
Test, measure, repeat