Qual é a principal diferença técnica entre AirWave e Central?

O AirWave é uma ferramenta de monitoramento on-premise baseada em SNMP, adequada para controladores AOS-8. O Central é uma plataforma de gerenciamento cloud-native que usa telemetria WebSocket, essencial para hardware AOS-10 e Wi-Fi 7.

Posso reutilizar minhas licenses do AirWave para o Aruba Central?

Não. O Central exige suas próprias licenses de subscrição (Foundation ou Advanced). Suas licenses existentes do AirWave não são transferíveis, embora a HPE frequentemente ofereça créditos de migração ou programas 'Bridge' durante renovações de hardware.

Como o AOS-10 impacta a migração?

O AOS-10 é o sistema operacional cloud-native para APs/Gateways da Aruba. Ele é gerenciado exclusivamente pelo Central, eliminando a necessidade de Virtual Controllers locais e habilitando verdadeiras capacidades de "microbranch".

Meus "floorplans" do VisualRF migrarão automaticamente?

Os mapas do VisualRF não migram diretamente. Você deve exportar os "floorplans" do AirWave e reimportá-los para a seção 'Floorplans' do Central, geralmente exigindo uma recalibração da escala e do posicionamento do AP.

Como eu lido com a paridade de configuração para grandes stacks de switch?

O Central fornece um recurso de 'Config Audit' que identifica o delta entre a "config" desejada na nuvem e o estado do dispositivo local. Você pode visualizar o log de 'Push' para ver exatamente quais comandos CLI falharam na execução.

Devo usar UI Groups ou Template Groups no Central?

Use UI Groups. Os Template Groups são propensos a erros de sintaxe que podem causar interrupções generalizadas. Os UI Groups fornecem um método mais seguro e verificado de enviar configuração para diversos hardwares.

O que acontece com meus APs legados AP-305/315?

APs existentes como as séries 300 e 500 podem se conectar ao Central, mas exigem um "firmware flash" para uma versão suportada pelo Central (AOS-8.10 ou AOS-10). As séries mais recentes AP-600/700 devem ir direto para o AOS-10.

Migração do Aruba AirWave para o Central: O Guia de Engenharia 2026

O AirWave é um software legado e qualquer engenheiro que se apegue a uma instância on-prem de AMP (AirWave Management Platform) em 2026 está gerenciando um passivo, não uma rede. O Aruba AirWave atingiu seu pico funcional anos atrás; a mudança para o Aruba Central não é apenas um "refresh" da UI — é uma mudança arquitetural fundamental do polling legado baseado em SNMP para um modelo de telemetria de streaming baseado em WebSocket. Se você ainda não começou sua migração, já está atrasado na curva de transição para o AOS-10.

O "Sunset" do AirWave: Por Que 2026 é o Prazo Final

A HPE Aruba tem sinalizado o fim do AirWave há anos, mas a dura realidade chega com o lançamento dos Access Points das séries 600 e 700 e a arquitetura AOS-10. O AirWave foi construído para a era AOS-6 e AOS-8 — uma era de silos "Controller-Managed" ou "Instant". O AirWave tem dificuldades com o volume de telemetria gerado pelos rádios modernos Wi-Fi 6E e Wi-Fi 7. Mais importante, o AOS-10 abandona o control plane do "mobility controller" local em favor de um modelo de gateway cloud-native, que o AirWave simplesmente não consegue orquestrar.

Se você permanecer no AirWave (AMP 8.3.x), você está preso ao mundo do AOS-8.4/8.10. Você perde a capacidade de realizar "AI-driven Radio Resource Management" (RRM), perde a visibilidade granular do ClientMatch e é forçado a gerenciar ambientes de alta densidade com ferramentas projetadas em 2012. O "technical debt" de manter um appliance AMP XL (provavelmente rodando em um R740 ou DL380 antigo) supera o custo da subscrição de Central quando você considera energia, refrigeração e o trabalho manual de ajuste fino de perfis de RF.

Diferença Arquitetural: Polling vs. Streaming Telemetry

O maior choque para os engenheiros que migram do AirWave para o Central é o dashboard "Health". No AirWave, seus dados são tão antigos quanto seu último intervalo de polling SNMP (tipicamente 5-10 minutos). Se um AP cair, o AirWave pode não alertá-lo por vários minutos até que o polling perdido acione um threshold. No Central, o AP mantém uma conexão WebSocket persistente (HTTPS/443) com a Aruba Cloud.

As principais diferenças no "data plane" incluem:

Stateful Monitoring: O Central sabe o momento exato em que um client falha um "4-way handshake". O AirWave só sabe "Client Count".
Configuration Authority: No AirWave, você podia escolher entre "Monitor-Only" e "Config-Mode". No Central, a nuvem é a "Source of Truth". Quaisquer alterações de CLI locais em um switch ou AP serão sobrescritas pelo "sync-timer" do Central.
Retention: O AirWave o limitava pelo espaço em disco. O Central fornece 30 dias de dados padrão com opções para relatórios de longo prazo via AI Insights.

A Transformação AOS-10: A Verdadeira Razão para Migrar

A mudança para o Central geralmente coincide com um upgrade para o AOS-10. É aqui que a maioria das migrações fica "complicada". O AOS-10 elimina o processo tradicional de eleição de 'Virtual Controller' (VC) encontrado nos Instant APs. Cada AP em um ambiente AOS-10 é um participante igual, comunicando-se diretamente com a nuvem do Central para suas instruções de "control plane". Isso remove a latência de "reboot do VC" observada em grandes clusters IAP gerenciados pelo AirWave.

! 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

Fase 1 da Migração: Paridade de Templates e Estratégia

Você não pode simplesmente "importar" um .cfg do AirWave para o Central. Você tem duas opções: UI Groups ou Template Groups. Se você vem de um background pesado de AirWave onde usava "Groups and Folders" para edição em massa de dispositivos, os Template Groups no Central parecerão familiares, mas frustrantes. No Central, um Template Group é um bloco de CLI "tudo ou nada". Um erro de sintaxe no seu mapeamento de %variable% e você derruba a conectividade de todo o site.

Recomendamos que a maioria das empresas migre para UI Groups. Isso permite que você use a GUI do Central para configuração, garantindo que o XML enviado aos APs seja sempre válido. Se você tiver 500+ sites de branch idênticos, somente então você deve considerar os Template Groups com uploads de variáveis .csv. Verifique nosso guia sobre AOS-10 Gateway Clustering para saber como lidar com a transição do "head-end" durante esta fase.

Fase 2 da Migração: O Processo de Onboarding (Greenfield vs. Brownfield)

Para uma migração "brownfield", você deve remover as configurações do AirWave dos seus APs/Switches. Se seus dispositivos estão apontados para o AirWave via DHCP Option 43 ou DNS (airwave.yourdomain.com), você deve desativar esses registros. Assim que o dispositivo puder alcançar activate.arubanetworks.com na porta 443, ele verificará seu MAC/Serial em sua conta Central e obterá sua nova configuração.

"Cutover" de Dispositivo Passo a Passo:

Atribua as Licenses: Certifique-se de que o MAC/Serial esteja no "Greenhouse" do Central e que uma license Foundation ou Advanced esteja aplicada.
Mova para o Grupo: Atribua o dispositivo ao seu grupo UI/Template pré-configurado.
Limpe as Informações do AirWave: No CLI do dispositivo local: no communication-monitor ap e no amp-server.
Reinicie: Isso força o dispositivo a reiniciar o "handshake" do Activate.

A Lista de "O Que Quebra": Preparando-se para o Suporte Pós-Migração

A migração não é perfeita. Aqui está o que vai quebrar no primeiro dia:

Formatação de Relatórios: Os relatórios em PDF do AirWave são customizáveis. Os relatórios do Central são mais rígidos. Se sua C-suite espera um PDF específico de "Weekly Wireless Health", você pode precisar construir um dashboard customizado usando a Central API e o PowerBI.
Latência do VisualRF: O VisualRF do AirWave era local e responsivo. Os "floorplans" do Central exigem largura de banda de "uplink" consistente. Arquivos CAD grandes para "floorplans" em um link MPLS de 10Mbps serão lentos.
Gerenciamento de Switches: Se você usa switches AOS-S (2930F/M, 5400R), o "Configuration Audit" no Central é notoriamente sensível aos comandos manuais de 'write memory'. Você deve treinar sua NOC para parar de usar o CLI.
Internal Link: Revise nossa análise das armadilhas de integração ClearPass e Central para garantir que seu RADIUS CoA (Change of Authorization) não quebre quando o AP se mover para seu novo "management plane".

Análise de Custos: A "Bitter Pill" da Subscrição

O AirWave era essencialmente "gratuito" depois que você comprava a license da VM e as licenses "one-time" de AP, mais uma pequena taxa anual de suporte. O Central é um custo Opex recorrente. Uma license Foundation padrão de 1 ano por nó AP/Switch tipicamente custa entre $100–$150 USD MSRP. Para um ambiente de 500 APs, isso é um item de linha anual de mais de $50 mil.

No entanto, você deve calcular o TCO (Total Cost of Ownership). Gerenciar um servidor AirWave requer:

Compute/storage do hypervisor (AirWave é um "resource hog" – mínimo de 8vCPUs e 32GB RAM para instalações pequenas).
Patching e "security hardening" do RHEL/CentOS.
Verificação manual de backups.

O Central elimina a manutenção do servidor, proporcionando uma redução estimada de 20-30% nas horas de "overhead administrativo" para a equipe de wireless.

Conclusão: Sem Volta

A transição do AirWave para o Central é inevitável. Até 2026, o AirWave será uma ferramenta de monitoramento legada incapaz de suportar os requisitos de alta "throughput" e baixa latência de uma empresa com Wi-Fi 7. A migração exige uma mudança de mentalidade: passando de uma abordagem de "box-manager" para uma abordagem de "policy-orchestrator". Se precisar de assistência com sua migração site-by-site ou precisar de validação arquitetural de alto nível para seu design AOS-10, consulte nossos serviços profissionais e equipe de engenharia em techleague.io.