Migration Actions & Commands
Complete reference of all commands sent to AOS-8 controllers during the migration workflow, organized by phase and user action.
Migration State Flow
Each AP progresses through a defined state machine from inventory through verification:
PENDINGPRECHECKCONVERTINGUPGRADINGREBOOTINGVERIFYINGDONE
Phase 1: Inventory & Curation
Initial discovery and convert list preparation
User Action: "Connect to MM and List APs"
Discover all APs managed by the Mobility Master
show ap database long— Retrieve complete AP inventory with model, serial, status, and controller mapping
Why: Populates the toolkit inventory table so operators can review which APs are AOS-10 capable, currently Up, and ready for conversion. Basis for all subsequent decisions.
User Action: "Add Selected to Convert List"
Curate the APs to be converted (no commands sent)
No commands sent to controller. This is a local UI operation—the toolkit simply marks selected APs in the convert list for processing in later phases.
User Action: "AP images and source of file (url)"
Display image mapping (no commands sent)
No commands sent to controller. Shows which AOS-10 image each AP will receive and the image source URL (from Central or HTTPS server).
Phase 2: Pre-flight Checks
Validate conversion prerequisites before activation
User Action: "Start Migration" (Run begins)
Automatic pre-flight validation runs before any AP conversion
0. Switch to primary controller context (batch processing)
cd <controller-hostname>— Context switch from Mobility Conductor (MC) to the AP's primary managed controller
Why: All AP conversion commands must run on the AP's primary managed controller, not the MC. This establishes the session context for the batch of APs managed by that controller. Use controller hostname (resolved via DNS), not IP address.
0b. Enter managed-device context
mdc— Enter managed-device context to access AP database on the controller
Why: Required in AOS-8 to query and manipulate the AP database on the managed controller. Must be executed after `cd` to enable AP conversion commands.
1. Display current convert list (optional, for verification)
show ap convert list— View all APs currently in the conversion candidate list
Why: Confirms which APs are queued for conversion before running pre-validation. Helps identify any APs that were not properly added to the list.
2. Add APs to convert list (per AP, batch)
ap convert add <ap-name>— Register each AP in the conversion candidate list on its primary controller
Why: Allows the controller to track which APs are candidates for AOS-10 conversion. Multiple APs can be added in the same controller context before running pre-validation.
3. Run pre-flight validation (batch)
ap convert pre-validate specific-aps— Validate all APs in convert list against Aruba Central and subscription requirements
Why: Prevents activation of APs that lack Central reachability, valid subscription, or device registration. Runs against all APs in the current convert list on this controller. Failed APs are marked FAILED and skipped in Phase 3.
4. Review pre-validation results
show ap convert list— Display final state of each AP (READY, FAILED, SKIPPED)
Why: Confirms which APs passed pre-validation (READY status) and which failed. Shows detailed failure reasons for each FAILED AP.
5. Outcome: READY APs proceed to Phase 3; FAILED APs are skipped
READY APs: Automatically proceed to Phase 3 (Convert & Activate). Only these APs will be converted to AOS-10.
FAILED APs: Marked as FAILED in the convert list and automatically skipped during Phase 3. They are NOT converted. Failure reasons typically include:
- • Device not found in Aruba Central inventory
- • No valid subscription assigned in Central
- • AP not registered/enrolled with Central
- • Central reachability timeout
Action for FAILED APs: Must be added/fixed in Aruba Central (device registration, subscription assignment) before retry. Once fixed in Central, can re-run pre-validate.
Phase 3: Convert & Activate
Activate AOS-10 conversion on each AP
User Action: "Continue" (when Acknowledge before each controller is enabled)
For each AP in the convert list, activate conversion
0. Switch to primary controller context (if not already in it)
cd <controller-hostname>— Re-establish context on this controller for conversion activation
Why: Ensures all activation commands execute on the correct managed controller. Use controller hostname (DNS-resolved), not IP address.
Command varies by image source method:
CENTRAL_PULL (with HTTPS image server)
ap convert active specific-aps activate image-url <url>— Start conversion using AOS-10 image from custom HTTPS server
Why: Directs AP to download AOS-10 image from specified HTTPS server during reboot. Faster for environments with local image caches.
CENTRAL_PULL (without HTTPS image server)
ap convert active specific-aps activate— Start conversion using Aruba Central cloud image pull
Why: Default method when no local HTTPS server is available. AP pulls image directly from Central.
CONTROLLER_IMAGE (local flash)
ap convert active specific-aps local-flash— Start conversion using pre-staged AOS-10 image in controller local flash
Why: Used when image has already been staged on controller. Fastest conversion path, no image download required.
User Action: "AP Convert Cancel" (manual recovery)
Stop all pending conversions (rare, operator recovery action)
ap convert cancel— Clear pending conversion list and abort any scheduled conversions
Why: Manual recovery lever when conversion was activated in error. Clears the controller's pending convert list. APs that have already rebooted into AOS-10 are unaffected.
Multi-Controller Batch Processing: Exit & Switch to Next Controller
If there are more controllers to migrate, exit current context and switch to the next primary controller
7. Exit current controller context
exit— Return to Mobility Conductor (MM) or previous command context
Why: Closes the active SSH session to the current controller and returns navigation context to MM or flat deployment point.
8. Switch to next controller (if more controllers remain)
cd <next-controller-hostname>— Context switch to the next primary controller managing a different batch of APs
Why: Positions the CLI session at the next controller. If deploying APs across multiple controllers, repeat this sequence for each.
9. Re-enter managed device context (if in MM hierarchy)
mdc— Re-establish managed-device-context for the next controller's AP database
Why: Required in MM deployments. Prepares to query and manage APs on the newly selected controller.
10. Repeat Phase 2 (Pre-flight) & Phase 3 (Convert) for next controller
Run show ap convert list, add APs, pre-validate, and activate conversions for the next batch.
Why: Each controller manages its own AP convert list independently. The workflow loops for each primary controller.
Phase 4: Upgrade & Reboot
Controller automatically executes reboot (no user commands)
No controller commands sent in this phase. After the activate command, the AP automatically:
- Downloads the AOS-10 image (from Central, HTTPS server, or local flash)
- Stages the image in boot partition
- Reboots into AOS-10
- Rejoins Aruba Central with new credentials
The toolkit monitors AP reboot progress via the "show ap database long" output (status field). Conversion timing depends on image download speed and AP model.
Phase 5: Verify & Complete
Confirm AP is running AOS-10 in Aruba Central
Automatic (if "Verify via Central" is enabled)
Central API query (no AOS-8 commands)
REST API call (not an AOS-8 command): Queries Aruba Central API to confirm the AP is now registered as AOS-10. If confirmed, AP state is marked DONE. If verification fails, AP state is FAILED.
Why: Provides definitive proof that conversion succeeded without manual console inspection. Prevents false positives from incomplete boots or re-association delays.
Manual (if "Verify via Central" is disabled)
Operator manually confirms in Central or via "show ap database"
No commands sent. Operator manually inspects Aruba Central dashboard or runs "show ap database long" on a managed device to confirm AP is now AOS-10 managed. Toolkit marks AP DONE on success.
Command Reference Summary
| Command | Phase | Purpose |
|---|---|---|
| show ap database long | Inventory | Discover all managed APs |
| ap convert add ap-name <name> | Pre-flight | Add AP to convert list |
| ap convert pre-validate specific-aps | Pre-flight | Validate Central connectivity |
| ap convert active specific-aps activate image-url <url> | Convert | Activate with custom HTTPS image |
| ap convert active specific-aps activate | Convert | Activate with Central cloud image |
| ap convert active specific-aps local-flash | Convert | Activate with pre-staged local image |
| ap convert cancel | Convert | Abort pending conversions (recovery) |