Having just finished migrating a client off a pair of over-provisioned XGS appliances into a (frankly, more elegant) cloud-native firewall setup, I feel compelled to chime in. We left the hardware running in monitoring mode for a month, managed entirely through Sophos Central, and the experience cemented my growing skepticism about these all-in-one management portals for complex network gear.
The short answer to your question is: yes, it can be profoundly laggy, but not uniformly. The latency seems to be a feature, not a bug, of the architecture. It's not your internet. The console itself is reasonably snappy, but any operation that requires the Central platform to push a configuration delta to your on-prem box, or worse, pull a meaningful log stream back, enters a state of profound lethargy. I've seen CLI changes take effect in seconds that took over 90 seconds to acknowledge and reflect in Central.
The pain points are predictable and cluster around specific tasks:
* **Policy pushes and firmware management:** Click "deploy." Watch the spinning icon. Make a coffee. The multi-step handshake between Central, the Sophos update infrastructure, and your box adds staggering overhead compared to local management.
* **Real-time log inspection:** If you're trying to trace a live threat or a connectivity issue, forget it. The log feed is batched and delayed, often by several minutes. For actual diagnostics, you SSH into the box anyway, rendering the "centralized" view rather useless.
* **Reporting generation:** Request a detailed threat report for the last 24 hours and you might as well go to lunch. It's a queued, asynchronous process that feels like it's running on severely under-provisioned shared backend systems.
The underlying issue, from an architectural standpoint, is that they've taken a stateful, network-local control plane and tried to abstract it to a globally distributed SaaS model. The synchronization mechanisms are heavy. It's the classic over-engineering problem: the added complexity of making everything "cloud-managed" introduces more failure modes and latency than it solves in operational simplicity.
My advice? If you're considering Central for day-to-day firewall rule tweaking and real-time monitoring, you'll be frustrated. If you're using it purely for centralized firmware compliance across dozens of distributed boxes and high-level reporting, the lag might be an acceptable trade-off. But ask yourself: are you paying a premium for a shiny dashboard that actually slows your team down?
keep it simple
Your experience with configuration pushes mirroring ours. We tracked it more systematically during a staged firmware rollout last quarter. The 90-second acknowledgement you saw is typical, but we observed the total time from Central 'deploy' click to the appliance reporting 'success' back in the portal averaged 4-5 minutes for a simple rule change. It wasn't just the handshake, the entire sequence seems to move at a fixed, slow pace.
It led us to stop using Central for any time-sensitive config changes. We now only use it for reporting and inventory, making all firewall changes locally. That defeats the purpose of a centralized dashboard, but the latency made operational planning impossible.
Ugh, that 4-5 minute wait for a simple rule change to finalize is the exact kind of friction that makes teams abandon a tool. You hit the nail on the head about operational planning being impossible.
We found a weird workaround that sometimes shaves time off for non-critical updates: staging the change in Central but not hitting 'deploy,' then logging into the local manager and manually syncing from there. It's still clunky, but it feels like you're prompting the box directly rather than waiting for the cloud pulse. Totally defeats the single-pane-of-glass ideal though 😕
The migration story is interesting, but calling cloud-native "more elegant" glosses over a different set of trade-offs. You've swapped hardware lag for subscription sprawl and egress cost complexity. Central's lethargy is a known tax, but at least it's a predictable, flat tax.
Your 90-second CLI versus Central observation is the core of it. The "single pane" model fails when the glass is this thick. It assumes all management tasks are equally tolerant of latency, which anyone who's tried to quench a live threat knows is false.
Question everything