Sexta-feira ao fim do dia, o antigo controlador de WiFi está sobrecarregado novamente. A receção de um hotel está a reiniciar os pontos de acesso entre check-ins, uma loja de retalho está a perder a conectividade de pagamento, uma enfermaria hospitalar está a reportar mobilidade clínica pouco fiável ou os residentes num edifício gerido estão a fazer fila fora de um escritório de suporte porque o portal do inquilino deixou de autenticar. O programa de migração já derrapou e cada solução alternativa "temporária" reside agora dentro do ambiente de produção.
Essa situação é o ponto de partida para a migração de sistemas legados. O problema não é o hardware ou o software ser antigo. O problema é que uma organização construiu um modelo operacional em torno de uma infraestrutura frágil, dependências não documentadas, administração manual, suporte expirado e serviços de identidade que ninguém quer desativar. Este guia prático trata o WiFi, a identidade e os serviços de rede multi-tenant como alvos de migração por direito próprio, não como canalizações a serem tratadas após a mudança de aplicações.
Por que a migração de sistemas legados merece um plano real
Uma pilha de rede em falha raramente falha isoladamente. Uma interrupção de WiFi num hotel pode afetar o acesso aos quartos, as integrações de gestão de propriedade, o início de sessão de fidelização e os fluxos de trabalho de recuperação de hóspedes. Um retalhista pode perder a conectividade entre caixas registadoras, serviços de pagamento, sistemas de stock e o WiFi de clientes. Na saúde, a cadeia de dependência pode incluir serviços de diretório, RADIUS, certificados, integrações de chamada de enfermaria, dispositivos clínicos e aplicações móveis. Numa propriedade residencial, um serviço de autenticação partilhado pode suportar inquilinos, empreiteiros, funcionários do edifício, câmaras, elevadores e instalações comuns.
O caso de negócio é, portanto, operacional e não cosmético. Conte os incidentes, as falhas de autenticação, as reposições manuais, os minutos de inatividade, as horas de engenharia de emergência, as licenças obsoletas e as escassas peças de substituição. Em seguida, identifique o que essas falhas impedem. Uma migração pode reduzir os custos administrativos, melhorar a capacidade de suporte, expor os problemas de cobertura e autenticação com maior clareza, simplificar a integração e dar às equipas de segurança uma base mais limpa para revisões de acesso.
Regra prática: Se a empresa não conseguir explicar quem é o proprietário de uma fonte de identidade, quem aprova uma alteração de política e quem pode autorizar a reversão, não está pronta para a transição.
O setor público do Reino Unido serve de aviso útil sobre o adiamento. Uma resposta parlamentar do Reino Unido de 2025 sobre sistemas legados estimou que os sistemas legados representavam 28% dos sistemas nos departamentos do governo central em 2024, acima dos 26% em 2023. A mesma evidência registou que 60% dos serviços digitais do governo tinham migrado para a cloud, no entanto, esse progresso demorou 13 anos, com 28% do património ainda legado. A adoção maioritária da cloud não eliminou o núcleo duro de dependências antigas.
Uma substituição direta muitas vezes preserva as mesmas fragilidades por trás de logótipos mais recentes. Se a plataforma antiga depende de contas partilhadas, alterações manuais de VLAN, encaminhamento RADIUS instável ou um único ponto de extremidade de gestão, movê-la para um novo hardware apenas torna a falha mais difícil de reconhecer. Construa o plano em torno de propriedade, evidência de dependência, vagas de migração, confiança de identidade, operação paralela e reversão. O resultado não é uma atualização de hardware. É a reforma de um modelo operacional falhado sem abandonar hóspedes, clínicos, funcionários ou residentes.
Avaliar a Infraestrutura Antes de Mover uma Única Carga de Trabalho
Comece com um inventário, não com uma apresentação de fornecedor. Construa um registo verificado que cubra cada controlador, access point, switch, firewall, captive portal, diretório, autoridade de certificação, servidor RADIUS, VLAN, SSID e consola de gestão. Registe a localização, proprietário, inquilino ou unidade de negócio, modelo, firmware, estado de suporte, tráfego observado, método de autenticação, origem da configuração e dependências conhecidas.
A palavra verificado é importante. Uma folha de cálculo elaborada a partir de registos de aquisição irá falhar pontos de acesso não geridos, integrações abandonadas, SSIDs temporários e dispositivos instalados por equipas locais. Compare as exportações de configuração com o tráfego observado, dados de monitorização, pedidos de suporte e entrevistas com as pessoas que apoiam cada site.
Mapear pessoas, dispositivos e relações de confiança
Trate a identidade como o seu próprio inventário. Separe funcionários, prestadores de serviços, convidados, doentes, estudantes, residentes, dispositivos IoT e contas de serviço. Para cada grupo, documente a fonte de verdade, o processo de entrada e saída de utilizadores, o tempo de vida das credenciais, a propriedade dos certificados, o caminho de aprovação e o método de acesso de emergência.
Depois, teste fluxos de trabalho representativos em vez de conectividade genérica. Um hotel precisa de check-in, acesso aos quartos, WiFi de convidados e integrações de gestão de propriedade. Um retalhista precisa de conectividade para pontos de venda, início de sessão de fidelidade, dispositivos portáteis e failover de loja. Um hospital precisa de mobilidade clínica, equipamentos conectados, autenticação de pessoal e resiliência ao nível da enfermaria. Um condomínio residencial precisa de integração de inquilinos, instalações partilhadas, acesso de visitantes e isolamento entre ocupantes.
Tomar decisões de migração com base em evidências
Classifique cada ativo ou fluxo de trabalho por criticalidade de negócio, sensibilidade dos dados, risco de compatibilidade e urgência. Sinalize protocolos não suportados, expiração de certificados, pontos únicos de falha, regras de firewall não documentadas, contas de serviço codificadas de forma rígida e falhas na qualidade dos dados. Atribua um proprietário responsável e defina as provas necessárias para passar cada vaga.
| Ativo ou Fluxo de Trabalho | Evidências a Recolher | Classificação de Risco | Vaga de Migração |
|---|---|---|---|
| Caminho de RADIUS e diretório | Logs de autenticação, mapeamento da fonte de verdade, configuração de failover, proprietário do serviço | Alto se partilhado entre locais | Vaga de fundação inicial |
| Captive Portal e identidade de convidados | Fluxos de redirecionamento, registos de vouchers ou perfis, registos de consentimento, dependências de CRM e PMS | Alto em ambientes voltados para convidados | Piloto por local ou inquilino |
| SSIDs clínicos ou operacionais | Registo de dispositivos, método de autenticação, testes de fluxo de trabalho clínico, janela de suporte | Crítico onde a continuidade do serviço é fundamental | Vaga controlada e específica do local |
| Serviços multi-tenant | Regras de separação de inquilinos, configuração de iPSK ou equivalente, fluxos de SSO, propriedade do suporte | Alto onde o isolamento é contratual | Vagas de coorte de inquilinos |
| Pontos de acesso e controladores | Firmware, estado do suporte, histórico de associação, cópia de segurança de configuração, localização física | Médio a alto dependendo da cobertura | Alinhar com vagas de serviço validadas |
Um fornecedor pode ajudar a descobrir ativos, mas nenhuma ferramenta pode reparar um mapa de propriedade incompleto. O registo deve tornar-se o registo de decisões do programa. Se um item não tiver proprietário, evidência de dependência ou caminho de reversão, não pertence a uma vaga de entrada em produção.
Escolher a abordagem de migração correta
Escolha a abordagem que se adapta à restrição. A moda é um método de migração fraco, especialmente quando a rede transporta identidade e operações de linha da frente.
O Rehost move um serviço existente para uma infraestrutura mais recente com o mínimo de alterações. Utilize-o para uma saída urgente de hardware ou hipervisor, uma implementação estável de RADIUS ou uma plataforma que ainda se comporta de forma previsível, mas atingiu um limite operacional. É rápido, mas transporta consigo processos manuais, pressupostos de licenciamento, defeitos de configuração e dívida técnica.
A mudança de plataforma altera o runtime enquanto preserva o comportamento principal do serviço. Um Captive Portal pode mudar para contentores geridos, ou uma integração de diretório pode mudar para uma camada de serviço suportada. Esta é a rota intermédia sensata quando a lógica de negócio é sólida mas a plataforma operacional é cara ou difícil de manter.
O refactoring altera o design interno. Isso pode significar a substituição de regras de rede estáticas por serviços de políticas, a exposição de APIs ou a separação de decisões de identidade da apresentação do portal. O refactoring cria uma base melhor, mas exige decisões de produto mais claras e mais testes do que uma migração direta - "lift and shift".
A migração strangler executa os serviços antigos e novos em simultâneo enquanto encaminha um site, inquilino, SSID ou fluxo de trabalho de cada vez. Para ambientes de WiFi e identidade, este é geralmente o padrão mais seguro porque a equipa pode validar a coexistência, comparar resultados de políticas e devolver uma coorte definida ao plano antigo.
| Abordagem | Melhor Adequação | Principal Benefício | Principal Risco |
|---|---|---|---|
| Realojar | Saída urgente de infraestrutura | Alteração mínima de serviço | Preserva fragilidades de design |
| Remodelar plataforma | Integrações estáveis com runtime dispendioso | Melhor capacidade de suporte sem reescrita | O trabalho de compatibilidade permanece |
| Refatorar | Redesenho de políticas, API e orquestração | Modelo operacional de longo prazo mais forte | Maior exigência de entrega e testes |
| Padrão Strangler | Identidade partilhada e redes multi-site | Pequenos grupos e reversão rápida | A coexistência deve ser planeada de raiz |
Um programa prático pode realojar uma plataforma RADIUS estável, replataformar o portal de convidados e refatorar a aplicação de políticas. Registe o método escolhido, as alternativas rejeitadas, o período de coexistência, o proprietário e a condição de saída para cada carga de trabalho. As organizações que avaliam serviços profissionais geridos também podem analisar a oferta de serviços profissionais da Purple em conjunto com o seu modelo de entrega interno.
Evite uma transição imediata do tipo "big-bang" a menos que o ambiente seja simples, a sincronização esteja comprovada e a janela de reversão seja tolerável. Num ambiente multi-inquilino, "tudo de uma vez" significa habitualmente "todas as chamadas de suporte ao mesmo tempo".
Migrar dados e identidade sem quebrar a confiança
A identidade é a espinha dorsal da migração. Se falhar, os pontos de acesso podem estar operacionais e os switches a encaminhar tráfego, mas o serviço continuará indisponível para o utilizador que dele necessita.
Comece por mapear todas as fontes de autenticação. Inclua servidores RADIUS, portais cativos, integrações de gestão de propriedades, florestas de Active Directory, ligações Microsoft Entra ID, Google Workspace, Okta, contas de serviço partilhadas, certificados de dispositivos e contas de emergência locais. Decida quais as fontes que irão sobreviver, quais as que serão sincronizadas temporariamente e quais as que devem ser retiradas antes que o novo serviço possa passar a ser autoritativo.
Construa a coexistência deliberadamente
Execute a sincronização de diretórios por fases. Corresponda as identidades utilizando atributos estáveis, resolva duplicados antes de ativar o acesso e defina como os utilizadores desativados ou que saíram são propagados para o novo serviço. Não utilize a migração como desculpa para criar um segundo diretório de identidades não controlado. Cada conta temporária precisa de um proprietário, de uma condição de expiração e de uma pista de auditoria.
Os certificados exigem a mesma disciplina. Inventarie as autoridades de certificação, modelos, sistemas de emissão, propriedade de renovação, cadeias de confiança e populações de dispositivos que utilizam EAP-TLS ou 802.1X. Rode os certificados numa sequência controlada, começando por uma coorte representativa. Mantenha o caminho de confiança antigo disponível até que a nova cadeia passe as verificações de autenticação e revogação em todas as classes de dispositivos relevantes.
“Uma migração de credenciais é uma migração de serviço. Trate as reposições de palavra-passe, a renovação de certificados e a desativação de contas como alterações com impacto para o cliente.”
A identidade dos convidados precisa de um fluxo de trabalho separado. Preserve a relação entre perfis, consentimento, vouchers, registos de fidelização e utilizadores recorrentes onde o negócio dependa disso. Teste o registo, o acesso recorrente, detalhes esquecidos, expiração, opt-out e recuperação assistida pelo suporte. Os convidados não devem descobrir que a migração foi bem-sucedida apenas porque o seu acesso anterior desapareceu.
Sequenciar o acesso, não apenas o equipamento
Mova os serviços de identidade antes de efetuar alterações gerais de SSID e VLAN. Em seguida, migre um SSID, local, inquilino ou fluxo de trabalho definido enquanto monitoriza a autenticação e o comportamento do tráfego. Na saúde, mantenha os caminhos dos dispositivos clínicos e conectados separados do acesso geral do pessoal. Em ambientes residenciais, preserve o isolamento dos inquilinos ao alterar o serviço que o fornece. Na hotelaria, verifique a integração de gestão de propriedade antes de abrir o novo fluxo de convidados para todos os quartos.
Utilize a Purple data and security overview como um ponto de referência ao avaliar os requisitos de identidade, segurança e processamento de dados. A escolha da ferramenta importa menos do que a prova de aceitação. Antes de o tráfego seguir o novo plano de identidade, comprove o sucesso da autenticação, a autorização correta, a confiança do certificado, a desativação do diretório, a conclusão do portal, a atribuição de VLAN e a recuperação após a interrupção do serviço.
Testes, transição e rollback que funcionam de verdade
Construa o plano de transição de trás para a frente, começando pela reversão. A maioria dos planos fracos descreve como o novo serviço será ativado e depois adiciona uma instrução vaga para "reverter se necessário". Isso não é um plano de reversão. Uma reversão real define o gatilho, o decisor, a ação técnica, o proprietário da comunicação e o limite de tempo.
Utilizar uma execução paralela como instrumento de teste
Execute os planos de rede e de identidade legados e novos em conjunto durante uma janela definida. Utilize pedidos RADIUS espelho sempre que a arquitetura o permita, percursos de Captive Portal duplicados, comparação de configurações e sondas sintéticas de início de sessão de convidados. Teste a autenticação bem-sucedida e com falha, certificados expirados, contas desativadas, roaming, atribuição de VLAN, dependência de DNS, comportamento da firewall e perda de um endpoint de diretório ou RADIUS.
Teste por coorte de negócio. Uma ala de hotel, um espaço comercial, um grupo de dispositivos aprovado por enfermaria ou um edifício residencial é mais útil do que um teste de laboratório que exclui integrações reais. Mantenha um pacote de evidências contendo carimbos de data/hora, identidades de teste, tipos de dispositivos, resultados de políticas, defeitos e aprovações.
Escrever o manual de procedimentos minuto a minuto
A sequência de transição deve incluir:
- Congelar alterações: Interromper alterações não relacionadas de rede, diretório, certificados e portais.
- Registar o estado atual: Exportar configurações, registar versões de políticas, preservar mapeamentos de identidade e confirmar que os ficheiros de restauro estão utilizáveis.
- Migrar o grupo: Alterar o site, tenant, SSID ou fluxo de trabalho definido, e não um "ambiente" ambíguo.
- Observar o comportamento: Monitorizar autenticação, redirecionamentos, associações de pontos de acesso, contactos de suporte, transações de aplicações e isolamento de tenants.
- Expandir ou reverter: Continuar apenas após o proprietário designado confirmar os critérios de saída. Se um gatilho for acionado, executar a reversão ensaiada.
As notas do plano identificam exemplos como uma taxa de falha de autenticação superior a 1,5%, loops de redirecionamento do Captive Portal e falhas de associação de pontos de acesso acima de um limite acordado. Utilize esses exemplos apenas se a sua linha de base os suportar e defina o acionador final com os proprietários dos serviços antes da janela de alteração. O objetivo não é escolher um número universal. O objetivo é eliminar discussões na sala de incidentes.
Ensaie a reversão com as mesmas pessoas que vão gerir a produção. Um plano de contingência que existe apenas num documento falhará quando certificados, caches, rotas e decisões humanas interagirem sob pressão.
Avaliação realista de custos, prazos e conformidade
A estimativa de entrega otimista de um fornecedor não é um orçamento pronto para a administração. Construa o modelo em torno da descoberta, remediação, integrações, testes, tempo da equipa interna, cobertura de suporte, licenciamento, comunicações, formação, exposição ao tempo de inatividade e contingência. Inclua a camada de rede como trabalho de entrega: design de WiFi, serviços de identidade, portais cativos, certificados, encaminhamento, isolamento de inquilinos e suporte de transição local a local. Uma migração não é barata se a plataforma antiga permanecer operacional indefinidamente.
O setor público do Reino Unido fornece um aviso claro sobre o trabalho diferido. O State of Digital Government Review registou tecnologia antiga em 28% dos sistemas da administração central em 2024. Também encontrou níveis de sistemas antigos que variam entre 10% e 60-70% nas forças policiais e trusts do NHS, referiu serviços críticos integrados em sistemas que remontam à década de 1970, e citou problemas de sistemas antigos em 153 sistemas em 16 ministérios. Estes valores não são uma tabela de preços do setor privado. Mostram por que razão a descoberta de dependências e a remediação pertencem ao orçamento de entrega, e não a uma linha de custos gerais que acaba por ser cortada.
Uma análise do setor público do Reino Unido sobre custos de TI legados relatou que as TI legadas custam entre 4% a 7% do orçamento anual do setor público em perda de produtividade. Utilize esse valor como um incentivo para medir o desperdício operacional na sua organização, incluindo o trabalho manual de identidade, chamadas de suporte repetidas, falhas no acesso de convidados e soluções temporárias de serviços de rede. Não o apresente como uma poupança de migração garantida.
| Setor | Intervalo de Custo Indicativo | Duração Típica | Principais Fatores de Conformidade |
|---|---|---|---|
| Hotelaria | Âmbito com base no número de locais, identidade de convidados, integração com PMS, design de WiFi e cobertura de suporte | Sequenciamento de acordo com a ocupação e eventos | Segurança de pagamentos, privacidade, registos de acesso, garantia de fornecedores |
| Retalho | Âmbito com base na variação de lojas, dependências de POS, identidade de fidelização, janelas de WiFi e de atividade comercial | Piloto fora do pico de atividade, seguido de implementação por coorte | PCI-DSS, privacidade, controlos de endpoints, auditabilidade |
| Saúde | Âmbito com base em fluxos de trabalho clínicos, validação de dispositivos, resiliência sem fios e governação de alterações | Janelas de planeamento e validação mais longas | Segurança dos doentes, privacidade, garantia de dispositivos médicos, continuidade |
| Imobiliário residencial e universitário | Âmbito com base no isolamento de inquilinos, integração, instalações partilhadas e sistemas do edifício | Vagas por edifício ou portefólio | Privacidade, isolamento contratual, governação de acessos, controlos de fornecedores |
Para redes de convidados, avalie o consentimento, retenção, registos de acesso, processamento de identidade e separação de inquilinos antes de se comprometer com um design. Utilize a ferramenta de verificação de conformidade de WiFi de convidados da Purple para analisar essa postura e identificar lacunas que necessitam de financiamento.
O ONS oferece outra lição difícil. O relatório sobre a migração do legado do ONS referiu que as restrições orçamentais abrandaram a transição de sistemas legados, apesar do progresso no sentido de substituir 80% dos serviços legados. A mesma fonte informou que 90% das organizações tinham dívida técnica de Microsoft Windows, 60% tinham muitos servidores ou computadores Windows não suportados e 51% relataram tempo de inatividade associado à dívida técnica. A pressão do fim de vida útil não elimina a necessidade de um planeamento de continuidade.
Mapeie o programa em relação à PCI-DSS, ISO 27001, Cyber Essentials, NIS2 onde aplicável, e obrigações específicas do setor. A conformidade exporá pressupostos fracos, por isso precifique os controlos, evidências, testes e propriedade operacional antes da janela de alteração.
Monitorização Pós-Migração e Desativação Contínua
A entrada em produção é o início da responsabilidade. Assim que o novo serviço transporta tráfego de produção, a equipa necessita de uma base de referência que comprove se a migração melhorou as operações ou se apenas moveu as mesmas falhas para uma consola diferente.
Monitorize a latência de autenticação RADIUS, a taxa de falha do captive portal, o sucesso de associação dos access points, o tempo de entrega da renovação de certificados, as incompatibilidades de políticas, os contactos de suporte e os objetivos de serviço ao nível do inquilino onde o isolamento multi-inquilino seja importante. Atribua a cada sinal um proprietário nomeado, uma rota de escalonamento e uma cadência de revisão. Um painel sem um operador responsável é apenas decoração.
Executar uma curva de estabilidade
Utilize um ritmo de revisão de 30, 60 e 90 dias. A primeira revisão deve detetar desvios de configuração, alertas em falta, falhas de autenticação recorrentes e soluções temporárias de suporte. A segunda deve testar se o serviço está a operar sem a intervenção da equipa de migração. A terceira deve decidir se a plataforma legada está pronta para ser desativada.
Não declare vitória apenas porque a nova plataforma esteve ativa durante um fim de semana calmo. Compare o comportamento ao longo dos ciclos de negócio, grupos de inquilinos, classes de dispositivos e eventos operacionais. A hotelaria precisa de variação de ocupação, o retalho precisa de condições comerciais, a saúde precisa de fluxos de trabalho clínicos aprovados e os complexos residenciais precisam de integração de inquilinos e acesso comunitário.
Desativar em fases controladas
Desative o serviço legado apenas após a aprovação dos critérios de saída e a assinatura do proprietário do negócio. Em seguida, remova-o metodicamente:
- Encerramento administrativo: Interromper alterações, fechar canais de suporte, arquivar configurações aprovadas e atualizar registos de propriedade.
- Revogação de confiança: Revogar certificados obsoletos, desativar contas de serviço antigas, remover a sincronização de diretórios não utilizada e eliminar caminhos de acesso residuais.
- Desativação de rede: Remover túneis VPN antigos, políticas, integrações e dependências de gestão, e depois recuperar espaço de endereçamento e licenças.
- Transição de conhecimento: Armazenar a arquitetura final, registo de decisões, evidências de testes, histórico de incidentes e procedimentos operacionais onde a equipa de suporte os possa encontrar.
Uma análise do governo do Reino Unido sobre a complexidade do património legado descreveu os sistemas legados como antigos, vulneráveis, insuportáveis e uma limitação à transformação. Essa fonte já estabeleceu a escala do problema. O seu trabalho após a migração é garantir que o património antigo não permaneça como um limite de segurança sem proprietário.
A Purple disponibiliza autenticação WiFi baseada na nuvem e redes baseadas em identidade para convidados, funcionários e ambientes multi-inquilino, com integrações para serviços de diretório e plataformas de rede. Visite a Purple para avaliar se as suas capacidades de identidade, acesso de convidados, analítica e migração se adequam ao seu plano de migração de sistemas legados.
