What a controller is — and what it isn’t
Behind every managed network sits a control plane: the brain that provisions devices, pushes configuration, enforces policy and gathers telemetry. The control plane is distinct from the data plane — the actual movement of packets, which happens on the switches, access points and gateways themselves. Understanding that split is the key to comparing controller models, because where the control plane lives changes cost, scale and resilience, but it does not change where your traffic flows.
There are three broad models: a dedicated hardware controller, an on-prem virtual controller, and a cloud-managed control plane. Each has a legitimate place. The goal of this article is to help you match the model to your environment rather than to crown a universal winner.
- Hardware controller — a dedicated on-site appliance
- On-prem virtual controller — the same software on your own server
- Cloud-managed control plane — a hosted service, one console for every site
- In all three, the data plane stays on the devices — only control differs
The hardware controller appliance
The traditional model is a dedicated controller appliance living in your data centre, with access points and switches tunnelling back to it. It offers tight control and predictable on-site latency, and for a single large campus it can be very effective. The downsides are familiar: the appliance is a capital purchase, it is a potential single point of failure unless you buy a second for redundancy, and scaling across many sites means either backhauling everything to one box or buying more boxes.
For organisations with one big site and strict requirements to keep everything on-premises, a hardware controller still makes sense. For distributed estates — retail chains, multi-branch enterprises, public Wi-Fi operators — it tends to become an expensive, rigid bottleneck.
The on-prem virtual controller
A virtual controller runs the same control-plane software on your own server or hypervisor, removing the dedicated appliance while keeping management inside your walls. It is more flexible than a hardware box — you can scale resources, snapshot it, and fold it into existing virtualisation — and it appeals to regulated environments that must keep the control plane on-premises.
The trade-off is that you now own the lifecycle: patching, backups, high availability and capacity planning are your responsibility. For teams that already run a mature virtualisation practice this is comfortable; for lean IT teams it is one more system to keep alive.
The cloud-managed control plane
In the cloud model, the control plane is a hosted service and your devices check in to it over the internet. You manage every site — access points, switches, gateways — from a single console, with zero-touch provisioning, centralised configuration and fleet-wide telemetry. Immunity’s Net Cloud follows this model, adding AIOps on top so the platform does not just show you data but interprets it.
The advantages compound as you add sites. There is no controller hardware to buy or maintain, new locations come online by plugging in a pre-claimed device, and software improvements arrive without a forklift upgrade. For anyone running more than a handful of locations, this is usually the lowest-friction model.
Resilience: what happens when the link drops
The most common objection to cloud management is “what if the internet goes down?” In a well-architected cloud-managed network, the answer is reassuring: because the control plane is separate from the data plane, devices keep forwarding traffic and enforcing their last-known policy even when they temporarily lose contact with the cloud. You lose management visibility until the link returns — not connectivity.
That is a very different failure mode from a hardware controller that tunnels user traffic and takes the network down with it when it fails. Designing for graceful degradation — local forwarding continuing through a cloud outage — is one of the quiet strengths of the cloud model.
Security and data residency
Security is often framed as on-prem versus cloud, but the more useful question is how each handles the control plane. A reputable cloud platform exchanges only configuration and telemetry over encrypted channels and never sits in the user data path, so sensitive traffic stays on your local network. On-prem keeps even the control plane inside your walls, which some regulated workloads require.
Whichever model you choose, the gateway still does the heavy lifting of edge security. A controller manages devices; it does not replace a firewall. Immunity’s Gateway Controller handles firewalling and WAN at the edge while Net Cloud orchestrates the fleet — the two are complementary, not alternatives.
Scaling across many sites
The clearest dividing line between the models appears the moment you add sites. A hardware controller forces a choice between backhauling every remote site’s traffic to one appliance — adding latency and a fragile dependency — or buying and maintaining a controller per region. Each new location multiplies cost and operational overhead.
A cloud-managed control plane inverts that. New sites come online by shipping a pre-claimed switch, gateway or access point that phones home and pulls its configuration automatically. Provisioning a tenth site is no harder than the first, and every location shares the same templates, policies and dashboards. For retail chains, multi-branch enterprises and public Wi-Fi operators, this difference is decisive — and it is why our campus wireless and PM-WANI deployments lean on cloud management.
Day-two operations: where the model earns its keep
Buying decisions focus on day one, but a controller earns or loses its value on day two — the months and years of running the network. Ask how each model handles a firmware upgrade across the fleet, a new VLAN that must reach every site, a security policy change, or a 2 a.m. fault. A cloud control plane pushes all of these from one console with an audit trail; an appliance model often means touching each box.
Telemetry is the other day-two differentiator. A modern platform does not just store logs — it correlates client experience, RF health, port stats and gateway events to point at root cause. That is the leap from monitoring to insight, and it is what separates a console you check after users complain from one that warns you first.
A decision framework
To choose, score your environment against four axes. Number of sites: one campus leans on-prem; many sites lean cloud. Data-residency rules: strict on-premises mandates favour a virtual controller. IT team depth: lean teams benefit most from cloud-managed simplicity. Resilience expectations: if you need local forwarding to survive a WAN outage, design for graceful degradation regardless of model.
For most growing organisations the weight falls toward cloud-managed networking with AIOps, because it scales without adding operational headcount. For a regulated single campus, an on-prem virtual controller remains a sound choice. There is no universal winner — only the right fit for your estate, which we are glad to help you assess against a live walkthrough of Net Cloud.
- Number of sites — one campus leans on-prem; many sites lean cloud
- Data-residency rules — strict mandates favour an on-prem virtual controller
- IT team depth — lean teams benefit most from cloud-managed simplicity
- Resilience expectations — design for local forwarding to survive WAN loss
The cost model: capex versus opex
The three models carry very different financial shapes. A hardware controller is capex-heavy: a large upfront purchase, a second unit for redundancy, and a refresh cycle every few years, plus the data-centre power and space it occupies. An on-prem virtual controller trades some of that for the cost of the server and the staff time to run it. A cloud-managed control plane is opex-light: no controller hardware, predictable subscription, and improvements delivered as software.
Over a five-year horizon, the operational savings often dominate the comparison — fewer truck rolls, faster provisioning, less time spent patching and maintaining infrastructure. When you model the decision, count the staff hours and downtime, not just the purchase orders; that is where the cloud model quietly pulls ahead for distributed estates.
Migrating from an appliance to cloud management
Organisations rarely switch models overnight, and they do not have to. A practical path is to run cloud-managed devices at new and refreshed sites while the legacy appliance continues serving its existing campus, then migrate the older site at its natural refresh point. Because the cloud control plane provisions devices automatically, each migrated location is mostly a matter of claiming hardware and applying a template.
Plan the order around risk: start with a small, tolerant site to build confidence, capture the configuration templates and policies it produces, then roll the proven pattern out to larger locations. By the time the central campus is due for refresh, the operational model is well understood and the cutover is routine rather than daunting.
Vendor lock-in and exit planning
A fair question with any control-plane model is what happens if you want to change direction later. Hardware controllers tie you to their ecosystem of managed devices; cloud platforms create an operational dependency on a hosted service. The pragmatic guard is to understand, before committing, how configuration is exported, how devices behave if the relationship ends, and whether the hardware can be repurposed. None of this should deter a sound choice — but it should be a known, not a surprise.
A local OEM relationship helps here too: clear support terms, accessible engineers and in-country accountability make the long-term commitment far more comfortable than a distant, opaque vendor relationship where exit terms are an afterthought.
Matching the model to your team
Technology choices succeed or fail on whether the team can run them. A deep infrastructure team comfortable with virtualisation may happily run an on-prem virtual controller and value the control it brings. A lean team spread across many sites will get far more done with a cloud-managed platform that automates provisioning and surfaces problems for them. Be honest about the team you have, not the one an ideal architecture assumes.
That honesty usually points distributed, lean operations toward cloud management and concentrated, well-staffed single campuses toward on-prem control. Either way, the decision should weigh day-two operational load as heavily as day-one capability — which is exactly the lens we bring when we walk a topology with you and show Net Cloud against a live network.
From management to intelligence
The real shift underway is not cloud versus on-prem — it is from managing a network to having the network help manage itself. A modern cloud control plane collects telemetry from every device and applies analytics to surface root cause and even remediate automatically, the pattern we unpack in what AIOps really means for network operations.
So the honest answer to “which model wins” is: it depends on your estate. One on-prem campus with strict data rules may stay on a virtual controller. A growing, multi-site operation almost always benefits from cloud-managed networking with AIOps. If you would like help deciding, we are happy to walk your topology with you and show Net Cloud running against a live network. You can also see how it underpins our switching and routing and campus wireless solutions.