More than a new coat of paint
It is tempting to read the new HPE Aruba Networking Central as a UI refresh with an AI badge attached. It is not. The platform has been rebuilt around AOS-10, a distributed, cloud-native operating model, and the change reaches into how devices are configured, how policy is enforced, and how faults are found. For anyone who has run an AOS-8 controller estate, the mental model is different enough to be worth setting out clearly before planning a move.
This is a practitioner's tour of what has changed and, more usefully, what that means for the people who operate the network every day.
What AOS-10 actually is
AOS-10 is a distributed network operating system that runs across access points, gateways, and switches, managed and controlled through HPE Aruba Networking Central. The key word is distributed. In the AOS-8 world, wireless intelligence was concentrated in mobility controllers that terminated tunnels and enforced policy centrally. AOS-10 breaks that dependency. access points can operate in a controllerless mode, with the cloud handling management and orchestration, and gateways deployed where tunnelling and centralised enforcement are actually needed rather than as a default requirement.
The practical consequence is flexibility. A small site can run APs that manage themselves through Central with no local controller. A larger or more security-sensitive site can introduce gateways for centralised policy enforcement. Both live under one management plane, configured the same way.
Controller-centric to cloud-native
AOS-8 assumed a controller. AOS-10 assumes the cloud, and treats gateways as an option you deploy where the design calls for them. This is why the two are not a simple upgrade of one another. the operating model underneath is different, and that difference is the whole point.
The architecture shift
Under AOS-10, HPE Aruba Networking Central becomes the single control point for WLAN, wired, and SD-Branch, rather than one of several tools. A few architectural points matter for operators:
- Unified management. Access points, switches, and gateways are provisioned and monitored from one cloud console, with a consistent configuration model across device types.
- Flexible enforcement. Policy can be enforced at the access point for many deployments, or tunnelled to a gateway cluster where centralised, high-throughput enforcement is required. The design choice is yours rather than dictated by the platform.
- Zero-touch provisioning. Devices can be shipped to a site, powered on, and adopt their configuration from Central automatically, with no on-site CLI work and no maintenance window for basic bring-up.
- Live operations. Onboarding and configuration no longer hinge on controller maintenance windows in the way AOS-8 estates often did.
AIOps and agentic operations
The "AI-native" description is the part most likely to be dismissed as marketing, so it is worth being specific about what it refers to. Central now incorporates both traditional and generative AIOps: AI-driven insights that surface anomalies, actionable alerts, and increasingly proactive remediation, rather than leaving an operator to infer problems from raw dashboards.
More recently, HPE has been deploying agentic capabilities. a multi-agent orchestration layer, surfaced through a GreenLake copilot interface, intended to let the platform reason across signals and take or recommend actions rather than only report. For operators, the meaningful shift is directional: the platform is moving from "here are the graphs, you work it out" toward "here is what looks wrong, here is the likely cause, here is what to do". How far you lean on that is a choice, but the capability changes what a first line of triage can look like.
"The interesting question with AIOps is not whether the AI is clever. It is whether it shortens the path from a user complaint to a correct diagnosis. On that measure, the newer Central is a real step, provided the underlying deployment is clean enough for the telemetry to be trustworthy."
Edge7 Networks, Networking PracticeWhat changes day to day
Set against an AOS-8 controller estate, the day-to-day differences an operator will feel are concrete:
- Fewer controller dependencies. Many operations that revolved around controller capacity, redundancy, and upgrade windows simply change shape, because the control plane lives in the cloud.
- Configuration by group and profile. Rather than per-device or per-controller configuration, you work with a group and profile model applied consistently across the estate (covered in detail in our multi-site deployment guide).
- Telemetry-led troubleshooting. Client and network insights are built in and agentless, which changes how you approach a fault (the subject of our Client Insights and AIOps piece).
- Policy as a design decision. Whether to enforce at the edge or tunnel to a gateway becomes an explicit design choice per use case, especially where dynamic segmentation is in play.
Moving from AOS-8
Because AOS-10 is a different operating model rather than a point release, the move from an AOS-8 controller estate is a project, not a patch. It rewards planning. The main considerations:
- Design intent first. Decide where you actually need gateways and centralised enforcement, and where controllerless operation is sufficient. This shapes the whole migration.
- Configuration translation. AOS-8 constructs do not always map one-to-one. The group and profile model is an opportunity to rationalise configuration that has accreted over years, not just to lift and shift it.
- Licensing and subscription. The cloud-native model is subscription-based through Central. worth confirming the commercial shape early.
- Phased cutover. As with any estate change, migrating in stages and validating each phase beats a single large cutover.
Clean telemetry depends on a clean deployment
The AIOps and Client Insights value is only as good as the deployment feeding it. A migration is the right moment to fix the RF design, naming, and configuration hygiene that a decade of incremental changes tends to erode. Carrying old inconsistencies into the new platform limits what the intelligence can do for you.
Where to start
If you are running AOS-8 today, the useful first step is a design and readiness review: what your current estate looks like, where gateways are actually needed under AOS-10, how your configuration would rationalise into the group and profile model, and what the migration would sequence into. That turns a platform change into a plan rather than a leap.
Edge7 Networks designs, migrates, and runs HPE Aruba Networking environments for organisations across Ireland and the UK, and holds the Aruba partnership behind that work. If you are weighing a move to AOS-10, or want to get more out of a Central estate you already run, a readiness review is the right place to begin.