Switched from Sophos XG to Quantum 3600 - the CLI is a nightmare in comparison.

I'm a senior sysadmin at a mid-market MSP that manages about 300 client sites; we standardized on Check Point Quantum appliances for our own core network and for a subset of our security-focused clients, but I've had hands-on with Sophos XG at several acquired shops.

Here's the breakdown from someone who bills hours for this work:

1. **Target user:** Sophos XG is built for admins who live in the CLI. Check Point Quantum is built for architects who live in SmartConsole, with CLI as a break-glass tool. If you're a team of 1-2, that philosophical difference is a daily tax.

2. **Real deployment effort:** The initial policy migration took us roughly 40 hours per appliance for similar-sized rulesets, mostly translating flat rules into Check Point's object model. You'll script it or lose a week. The CLI is not built for bulk operations; you'll use the API or R80.x migration tools.

3. **Where Check Point wins concretely:** The consolidated logging and threat forensics. In my stack, the 3600 handles about 1.8 Gbps of inspected traffic with all blades enabled, and the correlation in SmartView is something Sophos Central couldn't touch at the time. You're paying for that single pane.

4. **Hidden costs:** Licensing complexity. A Sophos license is straightforward. A Check Point SKU with all threat prevention blades, plus support, on a 3600 came in around $28k/year for us. Miss a blade and a feature is just missing. CLI proficiency requires their $3k+ admin course; you'll be Googling the clish syntax weekly.

For a network where the primary administrator prefers a CLI workflow, I'd recommend staying with Sophos. If you have a dedicated security team that uses the GUI for deep investigation and needs the granular reporting, stick with the 3600 but budget for formal training. To decide, tell us your team size and whether you need the forensics dashboard daily or just need a firewall that passes traffic.

Oh wow, this is exactly the kind of thing that scares me about making big vendor switches. When you said "simple 'deny ip any any' style logging," I felt that. In Sophos, you just do it. The object-centric model in the CLI sounds really intense for quick tasks.

So, is the CLI mainly for emergencies or minor tweaks? Are you basically forced to use the SmartConsole for any real change? Sorry for the basic question, still learning the ropes here. Thanks for the heads-up

You're right about the object model being the core of the friction. It's not just a syntax change, it's a fundamental design choice. The CLI expects you to work within the architecture of the management database, which is why every action feels like a multi-step process.

That said, once you internalize that everything is an object, you can start scripting in clish more effectively. You can't fight it. The quick wins come from learning to use `add object` and `set object` commands as your first step for any new host, network, or service before you even touch a rule.

For the running config clarity, try `show configuration full`. It's still not a clean hierarchical dump like you might be used to, but it gets you closer to a complete picture without jumping between sub-menus.

That's a solid point about internalizing the object model. It really is the only way to work effectively with clish. The shift from a rule-based CLI to a database-centric one is the biggest mental hurdle.

I'd add that the `add object` approach becomes crucial for automation. If you're scripting any kind of deployment or change, you have to create the object first before you can reference it in a policy command. Trying to shortcut that will just lead to errors.

Your tip on `show configuration full` is a good one. For anyone else reading, it's also worth remembering that `show configuration full` can be piped to a file. It's not pretty, but having that text file to search through offline can sometimes be easier than navigating the live CLI menus when you're looking for something specific.

You're absolutely right about scripting. The object-first approach is key, and once you embrace it, you can actually build some pretty reliable automation. It forces you to think declaratively, which is good practice.

One caveat I'd add: watch out for state. If your script runs `add object` for something that already exists, it'll error and stop. I've found wrapping those calls in simple conditionals (checking via `show object` first) saves a lot of headache in longer scripts. It adds lines, but makes the script idempotent, which is a lifesaver.

The offline search trick with `show configuration full > file.txt` is golden for debugging those scripts, too. You can grep for the object names you're trying to manipulate.