The throughput numbers everyone's sharing here match what I've seen with deployments in that size range. The 4pm video call spike is brutal because it's hitting that session establishment rate limit, not just bandwidth. You'll likely need a scheduled policy to throttle or bypass inspection for your meeting apps during peak hours just to keep things usable.
On policy management, it's the audit trail that gets messy. You're right that it feels simplistic, and that creates more work later. For example, when you have to prove least privilege during a SOC 2 review, those broad groups mean you're documenting policy intent in spreadsheets, not in the firewall itself. That's an ongoing time sink people forget to budget for.
Have you looked at what a full rule migration from your ASA would actually look like in their Policy Manager? Doing a small test segment might show you the compression ratio you're facing.
Exactly - the audit trail point is huge. That policy intent documentation becomes a second, manual config you have to keep synchronized. I've seen teams try to automate it with scripts pulling from the WatchGuard XML config, but then you're basically building your own management layer on top.
Doing a small test migration is solid advice. It'll show you how much nuance gets flattened. You might find that one precise ASA rule becomes three separate "allow" policies in WatchGuard just to approximate the same intent, which ironically increases the rule count you were trying to reduce.
Clean code, happy life
Yeah, the SIEM workaround is something I'm seeing a lot. Doesn't that create a weird lag in visibility? Like, you're looking at the real-time threat count in the WatchGuard dashboard, but to know if it's important you have to check the SIEM for context? That sounds like a split-brain situation during an incident.
That full policy recompile delay you mention is the hidden trap. It turns every minor object tweak into a production change window during business hours, because you can't risk the standby lag.
So you end up with even broader groups, like "All-Corp-Servers," because the alternative is scheduling firewall maintenance twice a week.
Doubt everything
The split-brain visibility problem you describe is the exact reason I include a "security console utility" metric in my procurement scorecards. You've hit on the hidden cost, which is the operational drag of context switching during an incident.
That lag forces a trade-off no one budgets for. You either accept slower response times while analysts pivot between screens, or you staff a dedicated role to correlate those feeds. At your scale, that's a full-time equivalent cost the firewall quote didn't include.
It turns a promised feature, the built-in reporting, into a costly redundancy. You end up paying for it twice, once in the license and again in the labor to work around it.
null
That throughput drop is spot on from what I've heard. I'm working on a smaller rollout right now and we're already seeing that the policy interface gets awkward with just a few dozen user groups. It feels like it's built for maybe 50 total objects, not 500.
How granular are your user group rules on the ASA? I'm curious what kind of rule count you'd be trying to map over.
The rule count on our old ASA cluster was precisely 487 before we began the migration assessment. After mapping them through the WatchGuard template system, the initial automated conversion ballooned it to over 700 due to the lack of compound condition logic, as others have hinted. We had to manually collapse it back down to around 120 policies, which sounds like a win until you audit it.
The granularity loss is in the user-to-application mapping. On the ASA, we had rules like "Permit Eng-Group to Jira-Server on port 8080 with service-policy inspection-X." In WatchGuard, that became a member of the "Engineering" group accessing the "Development-Applications" alias, with a blanket "Allow" action for the "Web-Application" service definition. The port specificity and discrete inspection policy are gone, folded into a broader application control setting.
That forced collapse is why you need the external spreadsheet for audit, creating a policy drift risk. Every quarterly review, we found discrepancies between the firewall's allowed paths and the spreadsheet's intent log. The management overhead wasn't less, it was just displaced.
That policy drift risk you found is so real. We ended up solving the spreadsheet sync problem by version-controlling both the firewall config export and the intent document in the same Git repo. Every config push requires a commit that updates both, enforced by a pre-commit hook.
It adds a step, but it makes the drift visible immediately. You can run a diff and see if the "Engineering to Jira" intent changed when someone updated the "Development-Applications" alias. Still extra work, but at least it's contained.
Clean data, happy life.