You're not doing a POC. You're doing a production evaluation. Call it what it is. With 500 users, a misstep will be an incident.
Start with a clear 30-day objective. Define success metrics **before** you rack the hardware or spin up the cloud instance. Your goal is to validate it works for *your* traffic and doesn't break anything.
**Critical POC phases:**
* **Baseline Week:** Document current firewall throughput, session counts, and top application protocols. Use existing tools. No Check Point code yet.
* **Deploy & Mirror:** Deploy in parallel, use passive or mirror ports. Test policy logic against live traffic. This is where you catch bad rules.
* **Controlled Cut-overs:** Start with non-critical segments (guest Wi-Fi, a single server VLAN). Measure latency impact, SSL inspection breakage.
* **Failover Test:** Schedule it. Pull the power. Document the RTO.
**Key metrics to track from day one:**
* CPU/Memory at peak throughput with all blades enabled.
* HTTPS inspection latency (compare to baseline).
* Threat prevention false positives per policy hit.
* Management server stability (this is often the bottleneck).
Avoid the sandbox. Test with real, anonymized traffic or you'll waste everyone's time. Their sales engineer will push for a quick win; hold them to your schedule and metrics.
—DD
Metrics don't lie.
Absolutely agree with calling it a production evaluation. That framing changes the entire stakeholder conversation.
One additional metric I'd track in the baseline and controlled cut-over phases is API traffic, especially for any internal or SaaS tools. A rule that works fine for web browsing can silently break an OAuth flow or a webhook, and users might not report it for days. I'd mirror that traffic and run it through a dev instance of the critical app to catch authentication failures.
Your point about the management server is key. In a 500-user environment, it's tempting to run everything on a single VM, but that's where performance cliffs happen. I'd test pushing policy updates during peak load to see if the management console becomes unresponsive.
IntegrationWizard
Good point on the API traffic. I've seen a Looker dashboard break during a similar eval because of a re-encryption rule. The error logs weren't clear at all.
Is there a reliable way to baseline that API traffic volume, or do you just have to sample it?
Totally agree on the production evaluation mindset. Framing it as a POC can accidentally lower the guardrails with stakeholders.
One nuance on your **Failover Test** point: pulling the power is valid, but I'd also test a software crash or a forced policy install failure. In my experience, that's where you see if the HA state sync truly works or if you get a split-brain scenario. The hardware fails less often than a bad update.
And for the management server stability metric, add a check for log ingestion during the baseline week. A 500-user shop can generate surprising volumes if logging is set verbosely; that can choke the manager before throughput does.
null
Log volume is the silent killer in a 500-user shop. A verbose setting on a single application protocol can blow through your storage and processing budget before the first user complains. Seen a Splunk bill get quadrupled that way.
The forced failover point is key. Simulate a corrupted policy push, not just a crash. If the HA pair goes into a panic and starts dropping all sessions, you've found the real test. Most vendors' documentation only covers clean failures.
Trust but verify – and audit