Migration Toolkit Docs

Campus Network Topology

Collapsed-core architecture showing Mobility Masters, controllers, access points, and client devices

ManagementAggregationAccessClientsMobility Masters(Primary + Standby)AOS-8 → AOS-10Controller 1AOS-10(Upgraded)Controller 2AOS-8(Pending)Controller 3AOS-10(Upgraded)AP-01AOS-10AP-02AOS-10AP-03AOS-10AP-04AOS-10AP-05AOS-10AP-06AOS-10AP-07AOS-10AP-08AOS-10AP-09AOS-10AP-10AOS-10AP-11AOS-10AP-12AOS-10Wireless Clients (Laptops, Phones, IoT Devices)
AOS-10 (Upgraded)

Successfully migrated to latest OS

AOS-8 (Pending)

Awaiting upgrade to AOS-10

Management

Mobility Masters for centralized control

Access Points

APs serve wireless clients in coverage area

Architecture Overview

  • →Management Layer: Redundant Mobility Masters provide centralized policy, user management, and device control
  • →Aggregation Layer: Controllers manage local mobility, authentication, and access policies; AOS-10 upgrades proceed sequentially
  • →Access Layer: APs (upgraded to AOS-10) handle RF transmission, client association, and per-user policy enforcement
  • →Client Layer: Wireless devices automatically connect to AOS-10 APs with seamless mobility between controllers

Migration Readiness by Layer

Management Layer — Ready

Mobility Masters are prepared for AOS-10. Verify cluster syncing, backup policies, and Central token validity before beginning AP migrations.

Aggregation Layer — Mixed State

Controllers in a single Mobility Master must be upgraded sequentially. During transition, both AOS-8 and AOS-10 controllers manage the same APs using fast-roaming handoff.

Access Layer — Primary Focus

APs are typically upgraded first (in batches by controller) to reduce downtime. Clients seamlessly roam between AOS-10 APs without manual re-authentication.

Client Layer — Passive

Clients (laptops, phones, IoT) remain in service. Upgraded APs and controllers maintain backward compatibility; no client-side action required.

Recommended Migration Strategy

  1. 1Validate inventory: Use the toolkit to connect to your Mobility Master, list all APs, and verify image compatibility for each model.
  2. 2Pre-flight checks: Run Central pre-validation to confirm licenses, RF domain settings, and default WLAN profiles are compatible with AOS-10.
  3. 3Convert by controller group:Select one controller's APs (typically 10–30 APs) and activate conversion. Monitor reboot; expect 5–15 min per AP.
  4. 4Verify in Central: After APs rejoin, confirm they are healthy in Aruba Central, have correct firmware version, and clients are associated.
  5. 5Repeat for remaining controllers: Continue with the next controller group until all APs are on AOS-10.

Key Considerations

  • •Batch sizing: Larger batches (20–30 APs) reduce total migration time but increase momentary coverage loss. Smaller batches (5–10) minimize disruption but take longer.
  • •Image download method:Use "Image server (HTTPS)" for fastest deployment if your image server is well-connected; fall back to "Central cloud pull" if local bandwidth is limited.
  • •Rollback plan: Each AP can be rolled back to AOS-8 via flash boot if issues occur. Document the pre-migration configuration snapshot for quick restore.
  • •Controller upgrade: Controllers do not automatically upgrade. Coordinate with your network team to plan when to upgrade each controller and verify compatibility.