Kann ich meine AirWave-Lizenzen für Aruba Central wiederverwenden?

Nein. Central erfordert eigene Abonnementlizenzen (Foundation oder Advanced). Ihre bestehenden AirWave-Lizenzen werden nicht übertragen, obwohl HPE oft Migrationsguthaben oder 'Bridge'-Programme bei Hardware-Refreshes anbietet.

Wie beeinflusst AOS-10 die Migration?

AOS-10 ist das Cloud-Native Betriebssystem für Aruba APs/Gateways. Es wird ausschließlich von Central verwaltet, wodurch die Notwendigkeit von lokalen Virtual Controllern entfällt und echte Microbranch-Funktionen ermöglicht werden.

Werden meine VisualRF-Grundrisse automatisch migriert?

VisualRF-Karten migrieren nicht direkt. Sie müssen Grundrisse aus AirWave exportieren und in den ‘Floorplans’-Bereich von Central neu importieren, was in der Regel eine Neukalibrierung des Maßstabs und der AP-Platzierung erfordert.

Wie handhabe ich die Konfigurationsgleichheit für große Switch-Stacks?

Central bietet eine 'Config Audit'-Funktion, die die Differenz zwischen der gewünschten Cloud-Konfiguration und dem lokalen Gerätestatus identifiziert. Sie können das 'Push'-Protokoll einsehen, um genau zu sehen, welche CLI-Befehle fehlerhaft ausgeführt wurden.

Sollte ich UI Groups oder Template Groups in Central verwenden?

Verwenden Sie UI Groups. Template Groups sind anfällig für Syntaxfehler, die weitreichende Ausfälle verursachen können. UI Groups bieten eine sicherere, verifizierte Methode, um Konfigurationen auf verschiedene Hardware zu übertragen.

Was passiert mit meinen älteren AP-305/315 APs?

Bestehende APs wie die 300er und 500er Serien können in Central eingebunden werden, erfordern aber ein Firmware-Flash auf eine von Central unterstützte Version (AOS-8.10 oder AOS-10). Neuere AP-600/700 Serien sollten direkt auf AOS-10 umgestellt werden.

Aruba AirWave zu Central Migration: Das 2026 Engineering Playbook

AirWave ist Software auf dem Abstellgleis, und jeder Ingenieur, der 2026 noch an einer On-Prem AMP (AirWave Management Platform)-Instanz festhält, verwaltet eine Belastung, kein Netzwerk. Aruba AirWave hat seinen funktionalen Höhepunkt vor Jahren erreicht; der Wechsel zu Aruba Central ist nicht nur ein UI-Refresh – es ist ein fundamentaler architektonischer Drehpunkt vom SNMP-basierten Legacy-Polling zu einem WebSocket-basierten Streaming-Telemetrie-Modell. Wenn Sie Ihre Migration noch nicht begonnen haben, sind Sie bereits hinter dem Zeitplan der AOS-10 Transition zurück.

Der Sonnenuntergang von AirWave: Warum 2026 die harte Deadline ist

HPE Aruba kündigt das Ende von AirWave seit Jahren an, aber die harte Realität trifft mit der Veröffentlichung der Access Points der 600er- und 700er-Serie und der AOS-10 Architektur ein. AirWave wurde für die AOS-6 und AOS-8 Ära entwickelt – eine Ära der „Controller-Managed“ oder „Instant“-Silos. AirWave hat Schwierigkeiten mit dem schieren Volumen an Telemetrie, das von modernen Wi-Fi 6E und Wi-Fi 7 Radios erzeugt wird. Noch wichtiger ist, dass AOS-10 die Kontrollebene des lokalen Mobility Controllers zugunsten eines Cloud-Native Gateway-Modells aufgibt, das AirWave einfach nicht orchestrieren kann.

Wenn Sie bei AirWave (AMP 8.3.x) bleiben, stecken Sie in der Welt von AOS-8.4/8.10 fest. Sie verlieren die Fähigkeit, AI-gesteuertes Radio Resource Management (RRM) durchzuführen, Sie verlieren die granulare ClientMatch Sichtbarkeit, und Sie sind gezwungen, Umgebungen mit hoher Dichte mit Tools zu verwalten, die 2012 entwickelt wurden. Die technische Schuld der Wartung einer XL-großen AMP Appliance (wahrscheinlich auf einem alternden R740 oder DL380) übersteigt die Abonnementkosten von Central, wenn Sie Strom, Kühlung und die manuelle Arbeit des Hand-Tunings von RF-Profilen berücksichtigen.

Architektur-Delta: Polling vs. Streaming Telemetrie

Der größte Schock für Ingenieure, die von AirWave zu Central wechseln, ist das „Health“-Dashboard. In AirWave sind Ihre Daten so alt wie Ihr letztes SNMP-Polling-Intervall (typischerweise 5-10 Minuten). Wenn ein AP ausfällt, alarmiert AirWave Sie möglicherweise erst nach mehreren Minuten, bis das verpasste Polling einen Schwellenwert auslöst. In Central unterhält der AP eine persistente WebSocket-Verbindung (HTTPS/443) zur Aruba Cloud.

Wesentliche Unterschiede in der Datenebene umfassen:

Stateful Monitoring: Central weiß den genauen Moment, in dem ein Client einen 4-Way Handshake fehlschlägt. AirWave kennt nur die „Client Count“.
Configuration Authority: In AirWave konnten Sie zwischen Monitor-Only und Config-Mode wählen. In Central ist die Cloud die Source of Truth. Jegliche lokalen CLI-Änderungen an einem Switch oder AP werden durch den Central Sync-Timer überschrieben.
Vorhaltung: AirWave begrenzte Sie durch den Speicherplatz. Central bietet 30 Tage Standarddaten mit Optionen für langfristige Berichterstattung über AI Insights.

Die AOS-10 Transformation: Der wahre Grund für die Migration

Der Umstieg auf Central fällt meist mit einem Upgrade auf AOS-10 zusammen. Hier werden die meisten Migrationen „blutig“. AOS-10 eliminiert den traditionellen 'Virtual Controller' (VC) Wahlprozess, der in Instant APs zu finden ist. Jeder AP in einer AOS-10 Umgebung ist ein gleichberechtigter Teilnehmer, der direkt mit der Central Cloud für seine Kontrollebenen-Anweisungen kommuniziert. Dies eliminiert die „VC Reboot“-Latenz, die in großen AirWave-verwalteten IAP-Clustern auftrat.

! Legacy AOS-8 IAP Config (AirWave managed)
iap-master-election
virtual-controller-ip 10.1.10.5
!
! New AOS-10 Central Logic
! No VC IP. APs use 'aruba-central' point-of-presence.
! Management via:
(AP)# show ap-env
(AP)# show ap debug cloud-server

Migrationsphase 1: Template Parity und Strategie

Sie können eine AirWave .cfg nicht einfach in Central „importieren“. Sie haben zwei Möglichkeiten: UI Groups oder Template Groups. Wenn Sie aus einem starken AirWave-Hintergrund kommen, wo Sie „Groups and Folders“ zum Massenbearbeiten von Geräten verwendet haben, werden sich Template Groups in Central vertraut, aber frustrierend anfühlen. In Central ist eine Template Group ein „alles-oder-nichts“ CLI-Block. Ein Syntaxfehler in Ihrem %variable% Mapping und Sie legen die Konnektivität des gesamten Standorts lahm.

Wir empfehlen den meisten Unternehmen, auf UI Groups umzusteigen. Dies ermöglicht Ihnen die Verwendung der Central GUI zur Konfiguration, wodurch sichergestellt wird, dass das an die APs gesendete XML immer gültig ist. Wenn Sie 500+ identische Zweigstellen haben, erst dann sollten Sie Template Groups mit .csv Variablen-Uploads in Betracht ziehen. Überprüfen Sie unseren Leitfaden zur AOS-10 Gateway Clustering, wie Sie den Head-End Übergang in dieser Phase handhaben.

Migrationsphase 2: Der Onboarding-Prozess (Greenfield vs. Brownfield)

Für eine Brownfield-Migration müssen Sie die AirWave-Einstellungen von Ihren APs/Switches entfernen. Wenn Ihre Geräte über DHCP Option 43 oder DNS (airwave.yourdomain.com) auf AirWave verweisen, müssen Sie diese Einträge löschen. Sobald das Gerät activate.arubanetworks.com über Port 443 erreichen kann, überprüft es seine MAC/Seriennummer mit Ihrem Central-Konto und ruft seine neue Konfiguration ab.

Schritt-für-Schritt Geräte-Umstellung:

Lizenzen zuweisen: Stellen Sie sicher, dass die MAC/Seriennummer im Central „Greenhouse“ ist und eine Foundation- oder Advanced-Lizenz angewendet wurde.
In Gruppe verschieben: Weisen Sie das Gerät seiner vorkonfigurierten UI/Template-Gruppe zu.
AirWave-Informationen löschen: Auf der lokalen Geräte-CLI: no communication-monitor ap und no amp-server.
Neustart: Dies zwingt das Gerät, den Activate-Handshake erneut zu initiieren.

Die „Was kaputtgeht“-Liste: Vorbereitung auf den Support nach der Migration

Migration ist nicht reibungslos. Hier ist, was am ersten Tag kaputtgehen wird:

Berichtsformatierung: AirWaves PDF-Berichte sind anpassbar. Centrals Berichte sind starrer. Wenn Ihr C-Level ein spezifisches „Weekly Wireless Health“-PDF erwartet, müssen Sie möglicherweise ein benutzerdefiniertes Dashboard mit der Central API und PowerBI erstellen.
VisualRF-Latenz: AirWaves VisualRF war lokal und schnell. Centrals Grundrisse erfordern eine konsistente Uplink-Bandbreite. Große CAD-Dateien für Grundrisse über eine 10Mbps MPLS-Verbindung werden kriechen.
Switch-Management: Wenn Sie AOS-S (2930F/M, 5400R) Switches verwenden, ist die „Configuration Audit“ in Central notorisch empfindlich gegenüber manuellen 'write memory'-Befehlen. Sie müssen Ihr NOC schulen, die CLI nicht mehr zu verwenden.
Interner Link: Überprüfen Sie unsere Analyse der ClearPass und Central Integrationsfallstricke, um sicherzustellen, dass Ihr RADIUS CoA (Change of Authorization) nicht bricht, wenn der AP auf seine neue Managementebene wechselt.

Kostenanalyse: Die bittere Pille des Abonnements

AirWave war im Wesentlichen „kostenlos“, nachdem Sie die VM-Lizenz und die einmaligen AP-Lizenzen sowie eine kleine jährliche Supportgebühr bezahlt hatten. Central ist eine wiederkehrende Opex-Belastung. Eine Standard 1-Jahres Foundation-Lizenz pro AP/Switch-Knoten kostet typischerweise 100–150 USD UVP. Für eine Umgebung mit 500 APs sind das über 50.000 USD pro Jahr.

Sie müssen jedoch die TCO (Total Cost of Ownership) berechnen. Die Verwaltung eines AirWave-Servers erfordert:

Hypervisor Compute/Storage (AirWave ist ein Ressourcenfresser – mindestens 8vCPUs und 32GB RAM für kleine Installationen).
RHEL/CentOS Patching und Security Hardening.
Manuelle Backup-Verifizierung.

Central eliminiert die Serverwartung und bietet eine geschätzte Reduzierung des „administrativen Overheads“ für das Wireless-Team um 20-30%.

Fazit: Kein Zurück

Der Übergang von AirWave zu Central ist unvermeidlich. Bis 2026 wird AirWave ein veraltetes Monitoring-Tool sein, das die Anforderungen eines Wi-Fi 7 Unternehmens an hohen Durchsatz und geringe Latenz nicht unterstützen kann. Die Migration erfordert einen Mentalitätswechsel: der Übergang von einem „Box-Manager“-Ansatz zu einem „Policy-Orchestrator“-Ansatz. Wenn Sie Unterstützung bei Ihrer Site-by-Site-Migration benötigen oder eine hochrangige Architekturvalidierung für Ihr AOS-10 Design benötigen, wenden Sie sich an unser professionelles Service- und Engineering-Team unter techleague.io.