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

• AOS-8 to AOS-10 Migration Overview and Reference Architecture
  • About This Guide
    • Audience
    • Not Covered in This Guide
  • Reference Customer Use Case
    • Reference Environment
  • Project Requirements and Objectives
    • Technical Requirements
    • Business and Operational Requirements
  • Assumptions
  • How to Use This Guide
  • Migration Workflow Overview

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, authentication, and role-based policy enforcement
• Validating end-to-end client authentication, roaming, and session control

The procedures emphasize ordered execution, explicit checkpoints, and rollback paths, 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

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.

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.

Reference Environment

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

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.
• If validation fails at any stage, stop and follow the documented rollback procedures.

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 and design
• Staging and preprovisioning
• Migration execution
• Validation and rollback

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.

---