HPE Aruba wireless refresh and staged AOS 8 to AOS 10 migration

This reference design is a starting point for project discovery, not a completed customer case. Final quantities and settings require site measurements, endpoint compatibility checks and a release-specific implementation design.

1. Requirements analysis

Workload and capacity example

Illustrative inventory: classify 60 current APs as retained, software-upgraded, replaced or pending validation before choosing a floor pilot. Sixty existing APs do not establish sixty target APs. Reassess bands, placement, clients and cabling, and quote the radio refresh separately from AOS management migration.

Deliverables at this stage: a measured floor plan, client/application inventory, current topology and dependencies, agreed test objectives and constraints. Keep associated-client counts, active-client counts and concurrent application demand as separate inputs.

2. Solution design

Inventory current APs, controllers and authentication → verify target support and feature differences → prepare Central, subscriptions and forwarding → pilot → staged migration with rollback checks.

Separate the two upgrade decisions

Measure coverage, authentication, power and upstream bottlenecks first. Wi-Fi generation and AOS management architecture are separate decisions. Destination bands, clients and cabling constrain benefits. A new model does not establish compatibility with the current controller or configuration.

Build a device and feature inventory

Record complete AP and gateway SKUs, software, lifecycle, antennas and mounting. Verify the target support matrix and upgrade path. Review SSIDs, roles, certificates, RADIUS, portals and integrations. Classify devices as retained, software-upgraded, replaced or pending validation.

Pilot cutover and rollback

Prepare Central ownership, subscriptions and management connectivity, plus power and uplink changes. Include employee, guest and special clients in a representative pilot. Preserve the pre-change configuration and document supported downgrade and reprovisioning procedures. Agree failure criteria and owners before the maintenance window. Advance each batch only after application and policy acceptance; deliver the final asset and feature-gap record.

3. Network topology and forwarding

Draw both the current controller/AP/identity/egress design and the target Central/AP/gateway design. The diagram is the target bridge reference. A tunnel target adds the selected gateway cluster and requires explicit roles, VLANs, authenticator and failure-domain mapping. Avoid conflicting VLAN attachment or duplicate DHCP during coexistence.

Dashed paths denote logical management or authentication dependencies, not physical direct cables. Central is the management service, not the client data-plane transit point. If tunneling is chosen, redraw and validate the AP-to-gateway path and the authenticator location for that mode.

SSID, segment and access-policy example

Names and VLAN IDs above are illustrative and must be mapped to the customer address plan. A VLAN is not a complete security boundary: enforce the approved ACL/firewall/role policy at the selected forwarding points and verify both allow and deny behavior. Publish only the minimum necessary SSIDs and verify legacy-client exceptions separately.

4. Implementation plan

1. Discovery and export：Securely export inventory and configuration, including hierarchy, WLANs, roles, VLANs, trust and integrations.
2. Target design：Validate AP/gateway support, Central version and subscriptions; document gaps, alternatives and exclusions.
3. Staging and lab checks：Prepare ownership, licensing, connectivity, power and identity; validate workflows and rollback in a limited environment.
4. Representative cutover：Include employee, guest and specialist clients and use pre-agreed failure criteria to proceed or recover.
5. Batch migration：Verify devices, ports and configuration scope per batch; close acceptance issues before expanding.
6. Closure and handover：Deliver asset mappings, closed gaps, rollback evidence and operating records; retain old equipment for the agreed recovery window.

Change control and rollback gate

Before each batch, name the change owner, business approver and recovery operator. Preserve the approved pre-change configuration and verify that the hardware/software supports the intended recovery. Stop or roll back if critical transactions fail, identity rules are wrong or agreed recovery limits are exceeded. Capture timestamps and logs before altering the next variable.

5. Configuration and procurement checklist

6. Acceptance and operational handover

1. Close target-support, Central ownership, subscription and integration gaps before the pilot.
2. Validate employee access, guest portal, special clients, discovery and mobile sessions.
3. Compare power modes and application measurements under equivalent pre- and post-change conditions.
4. Exercise a supported rollback in the pilot and record the recovery time before approving the next batch.

Agree numeric coverage, SNR, packet-loss, latency and recovery thresholds with the application owner before the pilot. Record locations, representative clients, load and software so results can be reproduced.

7. Prepare a project request

Send scaled plans, device and application schedules, current software and topology, power and cabling records, destination and rollout constraints. We use these inputs to discuss a project-specific configuration and quotation.

Prepare the network BOM

8. Regional and architecture checks

Product families above are candidates for evaluation. Confirm exact destination SKUs, certifications, permitted channels and software support before ordering. For mainland China, global 6 GHz capability does not establish local permission to enable it. AOS 8, AOS 10 and Central features require version-specific verification.