Link Search Menu Expand Document

   Gateway Clustering with AOS 10
05-Oct-26

AOS-8 to AOS-10 Migration Overview and Reference Architecture

This Validated Solution Guide (VSG) describes a practical, repeatable process for migrating a campus wireless deployment from HPE Aruba Networking Wireless Operating System 8 (AOS-8) campus mode to HPE Aruba Networking Wireless Operating System 10 (AOS-10) tunnel mode, using Central’s new scope-based configuration model.

Table of contents

About This Guide

This comprehensive guide stems from a collaboration among several Aruba product and field engineering teams - including product engineers and product managers who developed the product, and field engineers who implemented it for Aruba customers.

It is built around Orange Widget Logistics (OWL), the fictional reference customer introduced in the Aruba VSG documentation set. OWL is used throughout this guide to provide a concrete, end-to-end migration example that mirrors real customer environments and operational constraints.

While OWL is fictional, the workflows, sequencing, and validation steps presented here are directly applicable to production campus networks and are intended to be adapted to customer-specific designs.

This guide focuses on the full migration lifecycle, including:

  • Converting controller-managed access points from AOS-8 to AOS-10
  • Upgrading and performing initial configuration of AOS-10 mobility gateways and access points
  • Building gateway clusters and required configuration objects in Central
  • Migrating overlay WLANs
  • Checkpoints and validation

The procedures emphasize ordered execution and explicit checkpoints, enabling engineers to complete migrations within controlled maintenance windows and with predictable outcomes.

Audience

This guide is written for IT professionals responsible for executing AOS-8 to AOS-10 campus migrations, including:

  • Network and systems engineers performing controller and AP configuration changes
  • Project and change managers coordinating upgrade windows and stakeholder communication
  • Aruba partners and professional services engineers delivering customer migrations

Readers are expected to be familiar with:

  • AOS-8 controller CLI operations
  • HPE Aruba Networking Central
  • Campus networking fundamentals (VLANs, RADIUS, 802.1X)
  • Device console access and basic API concepts

Key Terms

Use this list for reference throughout the AOS-8 to AOS-10 campus migration.

Appliances and Roles

  • Mobility Conductor (MM / MCr) - AOS-8 appliance that centrally manages Mobility Controllers and owns the configuration hierarchy.
  • Mobility Controller (MC/MD) - AOS-8 controller that terminates AP tunnels and enforces policy; becomes a Mobility Gateway in AOS-10.
  • Mobility Gateway (GW/Gateway) - AOS-10 gateway (an upgraded controller) that terminates tunneled WLAN traffic, managed by Central.
  • Gateway Cluster - A group of AOS-10 gateways providing redundancy and load balancing; WLAN profiles reference it for tunnel termination.
  • Campus AP (CAP) - Controller-based access point in AOS-6/AOS-8.

AP Forwarding Modes

  • Tunnel Mode - Client traffic is tunneled from the AP to the Mobility Gateway (gateway-based forwarding).
  • Bridge Mode - Client traffic is bridged locally onto tagged VLANs at the AP (AP-only, no gateway required).
  • Mixed Mode - Tunnel and bridge SSIDs coexisting on the same AP.

HPE Aruba Networking Central

  • HPE Aruba Networking Central (Central) - Cloud platform used to manage AOS-10 devices.
  • new Central / classic Central - new Central is the scope-based configuration model; classic Central is the legacy group-based interface. At the time of this publication, device groups are created in classic Central with “Allow New Central to overwrite all configurations for this group” enabled so new Central can manage the configuration.
  • Scope - The level at which configuration is applied and inherited: Global, Site Collection, Site, Device Group, and Device.
  • Library - The new Central container for reusable shared profiles, created once and assigned to device functions and scopes.
  • Profile - A named, reusable configuration object (VLAN, DNS, NTP, RADIUS, RF, WLAN, and so on).
  • Device Function - The device type a profile applies to: Mobility Gateway or Campus Access Point.
  • GreenLake - HPE cloud platform where device inventory and Central subscriptions are managed.

Authentication and Policy

  • AAA / RADIUS - Authentication, Authorization, and Accounting; RADIUS servers validate 802.1X clients.
  • 802.1X (WPA3-Enterprise) - Enterprise authentication against a RADIUS server (used by CorpNet).
  • PSK (WPA3-Personal) - Pre-shared-key authentication (used by OpsNet and GuestNet).
  • CoA / RFC3576 (Change of Authorization) - Lets the RADIUS server change a client’s role or VLAN mid-session without reauthentication.
  • User Role - The policy set (VLAN assignment and/or access rules) applied to a client after authentication.
  • Named VLAN - A VLAN profile defined in the Library and referenced by WLANs and gateways.
  • Enhanced Open (OWE) - Opportunistic Wireless Encryption: the Wi-Fi Alliance standard for an open, passwordless SSID that still encrypts each client’s traffic individually. (Will replace the legacy PSK on AOS-8’s GuestNet when upgraded to AOS-10).
  • Captive Portal - A web page that intercepts a new client’s first browser request and requires sign-in or acceptance of terms before granting network access (will be used for GuestNet in Central).
  • Central NAC - HPE Aruba Networking Central’s cloud-based Network Access Control service. It will host the GuestNet captive portal and assign the guest role after a visitor authenticates or accepts the terms.

Redundancy, Onboarding, and Migration Commands

  • VRRP / VIP - Virtual Router Redundancy Protocol; a shared Virtual IP used for resilient management and CoA delivery across cluster members.
  • LMS IP - The controller IP an AP is directed to in its AOS-8 AP system profile.
  • ZTP (Zero Touch Provisioning) - Automatic device provisioning without manual console configuration.
  • Static-Activate - Manual, console-based initial gateway setup (management VLAN, IP, DNS, default gateway) used in place of ZTP.
  • Activate / ADP - Aruba Activate cloud provisioning service; ADP (Aruba Discovery Protocol) is one method AOS-6/8 APs use to discover their controllers.
  • apmove - AOS-8 command, run on a controller cluster member, that relocates APs between controllers before an upgrade.
  • ap convert - AOS-8 command used to convert a Campus AP to an AOS-10 AP managed by Central.

Not Covered in This Guide

To keep the guide focused and operationally actionable, the following topics are intentionally out of scope:

  • Switch firmware upgrades and detailed switchport configuration
  • Step-by-step ClearPass or third-party RADIUS server configuration
  • Endpoint supplicant configuration and client-specific troubleshooting
  • Virtual infrastructure, database, or third-party server provisioning beyond basic reachability

Where relevant, integration points are identified, but detailed procedures are deferred to their respective platform documentation.

Reference Customer Use Case

OWL is expanding its operations through acquisition. The newly acquired company is operating on an AOS-8 controller-based WLAN architecture that does not meet OWL’s firmware compliance and management standards. It consists of eight sites grouped into three categories: headquarters campus, distribution centers, and retail stores. The existing hierarchy is built as follows:

Group 1: Barcelona_HQ

  • Building 1: Barcelona_1
  • Building 2: Barcelona_2
  • Building 3: Barcelona_3

Group 2: Distribution

  • Building 4: Milan
  • Building 5: Rotterdam

Group 3: Retail

  • Building 6: London
  • Building 7: Madrid
  • Building 8: Paris

The graphic below illustrates the AOS-8 hierarchy and geographical locations for reference.

AOS-8 Hierarchy

To align this site with OWL’s AOS-10 tunnel mode standard, these sites will be migrated to AOS-10. More importantly, OWL IT is taking this opportunity to begin migrating to Central’s new scope-based configuration model. The first site to be migrated will be Barcelona_1, one of three buildings at the Barcelona Headquarters Campus. The objectives are as follows:

  • Standardize on Aruba-recommended AOS-10 firmware
  • Consolidate configuration and monitoring in Central’s new scope-based configuration model
  • Preserve user experience during migration
  • Complete the upgrade within a short, controlled maintenance window

The diagram below illustrates the AOS-8 Mobility Conductor hierarchy to help visualize inheritance. The two controllers marked with green boxes will be converted to mobility gateways in this exercise.

AOS-8 Hierarchy Diagram

Reference Site

The Barcelona_1 reference site reflects a common mid-sized campus deployment:

  • Two Mobility Conductor-managed AOS-8 controllers operating as an L2 cluster, upgrading to AOS-10 mobility gateways
  • A fleet of Aruba campus APs (CAPs) to be converted to AOS-10 and onboarded into Central
  • Centralized RADIUS infrastructure providing 802.1X authentication and RFC3576 (CoA)
  • A requirement for minimal disruption to production users during the migration

AOS 8 Site Overview

Although the examples reference OWL, the same approach applies to customer environments with similar architectural characteristics.

Project Requirements and Objectives

The following requirements guide the planning and execution of the OWL migration and should be evaluated for any customer deployment.

Technical Requirements

  • Gateways and APs must meet minimum supported firmware levels prior to onboarding.
  • Devices must be able to reach Aruba Central and be assigned valid GreenLake subscriptions.
  • RFC3576 (CoA) must be reachable from RADIUS servers to the AOS-10 gateways.
  • API-driven configuration must respect documented rate limits and include retry logic.

Business and Operational Requirements

  • Minimize service disruption by migrating in phases and validating with test clients first.
  • Maintain auditable change history, including API requests, responses, and Central audit logs.
  • Provide documented rollback procedures for AP and gateway failures.
  • Ensure post-migration operational readiness, including monitoring and support handoff.

Assumptions

To keep the focus on the upgrade steps, the implementation engineer has discretion over related tasks typically associated with an infrastructure upgrade or implementation project. Assumptions regarding these tasks include the following:

  • The customer’s HPE GreenLake account has been created.
  • Subscriptions and licenses have been purchased.
  • Controllers at the site are part of an L2 cluster.
  • Pre-upgrade validations and health checks of both controllers and APs have been performed to identify and resolve existing issues to reduce chances of upgrade complications.
  • Rollback procedures for each stage have been documented and are ready if necessary.
  • Diverse client devices (phones, laptops, IoT) have been set aside and are ready for client testing and mimic production as closely as possible.
  • Monitoring strategy is in place to proactively identify latent issues post-upgrade (e.g. performance degradations, roaming inconsistencies)

How to Use This Guide

  • Follow the guide sequentially; complete planning, discovery, design, and staging before migrating production devices.
  • Use validation checkpoints to confirm success at each phase.
  • Capture console output, API responses, and audit logs to establish a baseline before, during, and after execution.

Migration Workflow Overview

This guide follows a phased workflow to migrate the OWL campus site from AOS-8 campus mode, managed by on-premises Mobility Conductor to AOS-10 tunnel mode managed by cloud-based Central. Each phase builds on the previous one and includes explicit validation steps to reduce risk.

The detailed steps for each phase are covered in the sections that follow:

  • Discovery
  • Configuration and Staging
  • Migration Execution

By following this approach, engineering teams can migrate campus wireless environments with predictable outcomes, controlled risk, and minimal disruption, using OWL as a concrete reference architecture while adapting the workflow to their own environments.