Sexta-feira à noite, o antigo controlador WiFi está sobrecarregado novamente. A recepção de um hotel está reiniciando pontos de acesso entre os check-ins, uma loja de varejo está perdendo a conectividade de pagamento, uma ala hospitalar está relatando mobilidade clínica não confiável ou residentes em um edifício administrado estão fazendo fila do lado de fora de um escritório de suporte porque o portal do inquilino parou de autenticar. O programa de migração já atrasou, e cada solução alternativa "temporária" agora reside no ambiente de produção.
Essa situação é o ponto de partida para a migração de sistemas legados. O problema não é que o hardware ou o software sejam antigos. 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 desligar. Este guia prático trata o WiFi, a identidade e os serviços de rede multi-tenant como alvos de migração por si sós, e não como encanamento a ser resolvido após a mudança da aplicação.
Por que a migração de sistemas legados merece um plano real
Uma pilha de rede em falha raramente falha isoladamente. Uma interrupção no WiFi de um hotel pode afetar o acesso aos quartos, integrações de gerenciamento de propriedades, login de fidelidade e fluxos de trabalho de recuperação de hóspedes. Um varejista pode perder a conectividade entre caixas, serviços de pagamento, sistemas de estoque e o WiFi dos clientes. Na saúde, a cadeia de dependência pode incluir serviços de diretório, RADIUS, certificados, integrações de chamada de enfermeiros, dispositivos clínicos e aplicativos móveis. Em um condomínio residencial, um serviço de autenticação compartilhado pode dar suporte a inquilinos, prestadores de serviços, funcionários do edifício, câmeras, elevadores e instalações comuns.
O caso de negócios é, portanto, operacional, não cosmético. Conte os incidentes, falhas de autenticação, redefinições manuais, minutos de inatividade, horas de engenharia de emergência, licenças obsoletas e peças de reposição escassas. Em seguida, identifique o que essas falhas impedem. Uma migração pode reduzir os custos administrativos indiretos, melhorar a capacidade de suporte, expor os problemas de cobertura e autenticação de forma mais clara, simplificar a integração e dar às equipes de segurança uma base mais limpa para revisões de acesso.
Regra prática: Se a empresa não puder explicar quem é o proprietário de uma fonte de identidade, quem aprova uma mudança de política e quem pode autorizar o rollback, ela não está pronta para a transição.
O setor público do Reino Unido oferece um alerta ú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 registrou que 60% dos serviços digitais do governo haviam migrado para a nuvem, mas esse progresso levou 13 anos, com 28% da estrutura ainda legada. A adoção majoritária da nuvem não eliminou o núcleo duro de dependências antigas.
Uma substituição direta muitas vezes preserva as mesmas fraquezas por trás de novos logotipos. Se a plataforma antiga depende de contas compartilhadas, alterações manuais de VLAN, roteamento RADIUS frágil ou um único endpoint de gerenciamento, 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, ondas de migração, confiança de identidade, operação paralela e rollback. O resultado não é uma atualização de hardware. É a aposentadoria de um modelo operacional decadente sem deixar hóspedes, médicos, funcionários ou residentes desamparados.
Avaliação do Patrimônio Antes de Mover uma Única Carga de Trabalho
Comece com um inventário, não com a apresentação de um fornecedor. Crie um registro verificado abrangendo cada controladora, access point, switch, firewall, Captive Portal, diretório, autoridade certificadora, servidor RADIUS, VLAN, SSID e console de gerenciamento. Registre o local, proprietário, inquilino ou unidade de negócios, modelo, firmware, status de suporte, tráfego observado, método de autenticação, origem da configuração e dependências conhecidas.
A palavra verificado importa. Uma planilha montada a partir de registros de compras deixará passar pontos de acesso não gerenciados, integrações abandonadas, SSIDs temporários e dispositivos instalados por equipes locais. Compare as exportações de configuração com o tráfego observado, dados de monitoramento, chamados de serviço e entrevistas com as pessoas que oferecem suporte a cada site.
Mapeie pessoas, dispositivos e relações de confiança
Trate a identidade como seu próprio inventário. Separe funcionários, contratados, convidados, pacientes, estudantes, residentes, dispositivos IoT e contas de serviço. Para cada grupo, documente a fonte de verdade, o processo de admissão e desligamento, a vida útil das credenciais, a propriedade do certificado, o caminho de aprovação e o método de acesso de emergência.
Em seguida, teste fluxos de trabalho representativos em vez de conectividade genérica. Um hotel precisa de check-in, acesso aos quartos, guest WiFi e integrações de gestão de propriedades. Um varejista precisa de conectividade no ponto de venda, login de fidelidade, dispositivos portáteis e failover de loja. Um hospital precisa de mobilidade clínica, equipamentos conectados, autenticação de funcionários e resiliência no nível da ala. Um empreendimento residencial precisa de integração de inquilinos, instalações compartilhadas, acesso de visitantes e isolamento entre os ocupantes.
Tome decisões de migração com base em evidências
Classifique cada ativo ou fluxo de trabalho por criticidade de negócios, sensibilidade de 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 diretamente e lacunas na qualidade dos dados. Atribua um proprietário responsável e defina as evidências necessárias para passar por cada fase.
| Ativo ou Fluxo de Trabalho | Evidência a Coletar | Classificação de Risco | Onda de Migração |
|---|---|---|---|
| Caminho de RADIUS e diretório | Logs de autenticação, mapeamento de fonte de verdade, configuração de failover, proprietário do serviço | Alto se compartilhado entre locais | Onda de fundação inicial |
| Captive Portal e identidade de visitantes | Fluxos de redirecionamento, registros de vouchers ou perfis, registros de consentimento, dependências de CRM e PMS | Alto em ambientes voltados para visitantes | Piloto por local ou inquilino |
| SSIDs clínicos ou operacionais | Registro 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 é essencial | Onda controlada e específica por local |
| Serviços multi-tenant | Regras de separação de inquilinos, configuração de iPSK ou equivalente, fluxos de SSO, propriedade de suporte | Alto onde o isolamento é contratual | Ondas de coorte de inquilinos |
| Pontos de acesso e controladoras | Firmware, status de suporte, histórico de associação, backup de configuração, localização física | Médio a alto dependendo da cobertura | Alinhar com ondas de serviço validadas |
Um fornecedor pode ajudar a descobrir ativos, mas nenhuma ferramenta pode reparar um mapa de propriedade incompleto. O registro deve se tornar o registro de decisões do programa. Se um item não tiver proprietário, evidência de dependência ou caminho de rollback, ele não pertence a uma onda de ativação.
Escolhendo a abordagem de migração correta
Escolha a abordagem que corresponda à restrição. Modismos são um método de migração ruim, especialmente quando a rede transporta identidade e operações de linha de frente.
Rehost move um serviço existente para uma infraestrutura mais nova com o mínimo de alteração. Use-o para uma saída urgente de hardware ou hipervisor, uma implantação estável de RADIUS ou uma plataforma que ainda se comporta de forma previsível, mas atingiu um limite operacional. É rápido, mas carrega processos manuais, premissas de licenciamento, defeitos de configuração e débitos técnicos.
O Replatform altera o ambiente de execução enquanto preserva o comportamento principal do serviço. Um Captive Portal pode ser movido para contêineres gerenciados, ou uma integração de diretório pode migrar para uma camada de serviço suportada. Este é o caminho intermediário mais sensato quando a lógica de negócios é sólida, mas a plataforma operacional é cara ou difícil de manter.
O Refactor altera o design interno. Isso pode significar substituir regras de rede estáticas por serviços de políticas, expor APIs ou separar decisões de identidade da apresentação do portal. O refatoramento cria uma base melhor, mas exige decisões de produto mais claras e mais testes do que uma migração direta simples.
A migração estranguladora (Strangler) executa serviços antigos e novos juntos enquanto direciona um site, inquilino, SSID ou fluxo de trabalho de cada vez. Para infraestruturas de WiFi e identidade, este costuma ser o padrão mais seguro, pois a equipe pode validar a coexistência, comparar os resultados das políticas e reverter um grupo definido para a plataforma antiga.
| Abordagem | Melhor Adequação | Principal Benefício | Principal Risco |
|---|---|---|---|
| Re-hospedar | Saída urgente de infraestrutura | Mudança mínima de serviço | Preserva pontos fracos de design |
| Re-plataformar | Integrações estáveis com tempo de execução dispendioso | Melhor suporte sem necessidade de reescrita | O trabalho de compatibilidade permanece |
| Refatorar | Redesenho de políticas, API e orquestração | Modelo operacional de longo prazo mais forte | Maior demanda de entrega e testes |
| Padrão Estrangulador | Identidade compartilhada e redes multi-site | Pequenos grupos e retorno rápido | A coexistência precisa ser projetada |
Um programa prático pode fazer o rehost de uma plataforma RADIUS estável, o replatform do portal de visitantes e o refactor da aplicação de políticas. Registre 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. Organizações que avaliam serviços profissionais gerenciados também podem analisar a oferta de serviços profissionais da Purple junto ao seu modelo de entrega interno.
Evite uma transição no estilo "big-bang", a menos que o ambiente seja simples, a sincronização seja comprovada e a janela de rollback seja tolerável. Em uma infraestrutura multi-tenant, "tudo de uma vez" geralmente significa "todas as chamadas de suporte de uma vez".
Migrando dados e identidade sem quebrar a confiança
A identidade é a espinha dorsal da migração. Se ela falhar, os pontos de acesso podem estar saudáveis e os switches podem estar encaminhando tráfego, mas o serviço ainda estará indisponível para quem precisa dele.
Comece mapeando cada fonte de autenticação. Inclua servidores RADIUS, Captive Portals, integrações de sistemas de gerenciamento de propriedades, florestas do Active Directory, conexões Microsoft Entra ID, Google Workspace, Okta, contas de serviço compartilhadas, certificados de dispositivos e contas de emergência locais. Decida quais fontes sobreviverão, quais serão sincronizadas temporariamente e quais devem ser desativadas antes que o novo serviço se torne autoritativo.
Construa a coexistência de forma deliberada
Execute a sincronização de diretórios em etapas. Faça a correspondência de identidades usando atributos estáveis, resolva duplicatas antes de habilitar o acesso e defina como usuários desativados ou desligados são propagados para o novo serviço. Não use 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, uma condição de expiração e uma trilha de auditoria.
Os certificados exigem a mesma disciplina. Faça o inventário das autoridades certificadoras, templates, sistemas emissores, propriedade de renovação, cadeias de confiança e populações de dispositivos usando EAP-TLS ou 802.1X. Realize a rotação dos certificados em uma sequência controlada, começando com uma coorte representativa. Mantenha o caminho de confiança antigo disponível até que a nova cadeia tenha passado pelas verificações de autenticação e revogação em cada classe de dispositivo relevante.
“Uma migração de credenciais é uma migração de serviço. Trate as redefinições de senha, renovações de certificado e desativações de conta como alterações que causam impacto ao cliente.”
A identidade de convidados precisa de um fluxo de trabalho separado. Preserve a relação entre perfis, consentimento, vouchers, registros de fidelidade e usuários recorrentes quando o negócio depender disso. Teste o registro, o acesso recorrente, detalhes esquecidos, expiração, cancelamento de inscrição e recuperação assistida pelo suporte. Os convidados não devem descobrir que a migração foi bem-sucedida apenas porque o acesso anterior deles desapareceu.
Organize a sequência de acesso, não apenas dos equipamentos
Mova os serviços de identidade antes de grandes mudanças de SSID e VLAN. Em seguida, migre um SSID, site, inquilino ou fluxo de trabalho definido enquanto monitora o comportamento de autenticação e tráfego. Na área de saúde, mantenha os caminhos clínicos e de dispositivos conectados separados do acesso geral dos funcionários. Em ambientes residenciais, preserve o isolamento dos inquilinos ao alterar o serviço que o provisiona. Na hotelaria, verifique a integração da gestão de propriedades antes de abrir o novo fluxo de convidados para todos os quartos.
Use o Purple data and security overview como um ponto de referência ao avaliar os requisitos de identidade, segurança e tratamento de dados. A escolha da ferramenta importa menos do que as evidências de aceitação. Antes que o tráfego siga o novo plano de identidade, comprove a autenticação bem-sucedida, 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 realmente funcionam
Crie o plano de transição de trás para frente a partir do rollback. A maioria dos planos fracos descreve como o novo serviço será habilitado e, em seguida, adiciona uma instrução vaga de "reverter se necessário". Isso não é um plano de rollback. Um rollback real define o gatilho, o tomador de decisão, a ação técnica, o responsável pela comunicação e o limite de tempo.
Use uma execução paralela como instrumento de teste
Execute os planos de identidade e de rede legados e novos simultaneamente por uma janela definida. Use requisições RADIUS espelhadas (shadow) onde a arquitetura permitir, jornadas de Captive Portal duplicadas, comparação de configuração e testes sintéticos de login de visitantes. Teste autenticações bem-sucedidas e com falha, certificados expirados, contas desativadas, roaming, atribuição de VLAN, dependência de DNS, comportamento do firewall e perda de um endpoint de diretório ou RADIUS.
Teste por grupo de negócios. Uma ala de hotel, um ponto de venda, um grupo de dispositivos aprovado por uma ala médica 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, falhas e aprovações.
Escreva o roteiro de execução minuto a minuto
A sequência de transição deve incluir:
- Congelar alterações: Interrompa alterações não relacionadas de rede, diretório, certificado e portal.
- Registrar o estado: Exporte configurações, registre versões de políticas, preserve mapeamentos de identidade e confirme se os arquivos de restauração estão utilizáveis.
- Migrar o grupo de usuários: Altere o site definido, tenant, SSID ou fluxo de trabalho, e não um "ambiente" ambíguo.
- Observar o comportamento: Monitore autenticação, redirecionamentos, conexões de pontos de acesso, contatos de suporte, transações de aplicativos e isolamento de tenants.
- Expandir ou reverter: Continue apenas depois que o proprietário designado confirmar os critérios de saída. Se um gatilho for acionado, execute o rollback planejado.
As notas do plano identificam exemplos como uma taxa de falha de autenticação acima de 1,5%, loops de redirecionamento de Captive Portal e falhas de conexão de pontos de acesso acima de um limite acordado. Use esses exemplos apenas se a sua linha de base os suportar, e defina o gatilho final com os proprietários do serviço 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 o rollback com as mesmas pessoas que executarão a produção. Um plano de retorno que existe apenas em um documento falhará quando certificados, caches, rotas e decisões humanas interagirem sob pressão.
Análise real de custo, cronograma e conformidade
A estimativa de entrega otimista de um fornecedor não é um orçamento pronto para a diretoria. Construa o modelo em torno de descoberta, remediação, integrações, testes, tempo da equipe interna, cobertura de suporte, licenciamento, comunicações, treinamento, 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, captive portals, certificados, roteamento, isolamento de inquilinos e suporte de transição site a site. Uma migração não é barata se a plataforma antiga permanecer operacional indefinidamente.
O setor público do Reino Unido fornece um alerta claro sobre o trabalho adiado. O State of Digital Government Review registrou tecnologia legada em 28% dos sistemas do governo central em 2024. Também encontrou níveis de sistemas legados variando de 10% a 60-70% em forças policiais e fundações do NHS, referiu-se a serviços críticos construídos em sistemas que remontam à década de 1970, e citou problemas legados em 153 sistemas em 16 departamentos. Esses números não são uma lista de preços do setor privado. Eles mostram por que a descoberta e a remediação de dependências pertencem ao orçamento de entrega, não a uma linha de despesas gerais que acaba sendo cortada.
Uma análise do setor público do Reino Unido sobre custos de TI legada relatou que a TI legada custa 4 - 7% dos gastos anuais do setor público em produtividade perdida. Trate esse número como um estímulo para medir o desperdício operacional em sua organização, incluindo trabalho de identidade manual, chamados de suporte repetidos, falhas de acesso de visitantes e soluções temporárias de serviços de rede. Não o apresente como uma economia de migração garantida.
| Setor | Faixa de Custo Indicativa | Duração Típica | Principais Fatores de Conformidade |
|---|---|---|---|
| Hospitalidade | Escopo baseado na contagem de locais, identidade de visitantes, integração com PMS, design de WiFi e cobertura de suporte | Sequência em torno de ocupação e eventos | Segurança de pagamento, privacidade, registros de acesso, garantia do fornecedor |
| Varejo | Escopo baseado na variação de lojas, dependências de PDV, identidade de fidelidade, WiFi e janelas comerciais | Piloto fora do pico comercial, depois implantação por coorte | PCI DSS, privacidade, controles de endpoint, auditabilidade |
| Saúde | Escopo baseado em fluxos de trabalho clínicos, validação de dispositivos, resiliência sem fio e governança de mudanças | Janelas de planejamento e validação mais longas | Segurança do paciente, privacidade, garantia de dispositivos médicos, continuidade |
| Residencial e propriedades estudantis | Escopo baseado em isolamento de inquilinos, integração, instalações compartilhadas e sistemas prediais | Ondas por edifício ou portfólio | Privacidade, isolamento contratual, governança de acesso, controles de fornecedores |
Para redes de convidados, avalie o consentimento, a retenção, os registros de acesso, o tratamento de identidade e a separação de inquilinos antes de se comprometer com um projeto. Use a ferramenta de verificação de conformidade de guest WiFi da Purple para revisar essa postura e identificar lacunas que precisam de investimento.
O ONS oferece outra lição difícil. O relatório sobre a migração do legado do ONS apontou que restrições orçamentárias desaceleraram sua transição para fora dos sistemas legados, apesar do progresso na substituição de 80% dos serviços legados. A mesma fonte relatou que 90% das organizações tinham débito técnico de Microsoft Windows, 60% tinham muitos servidores ou desktops Windows sem suporte e 51% relataram tempo de inatividade vinculado a débitos técnicos. A pressão de fim de vida útil não elimina a necessidade de planejamento de continuidade.
Mapeie o programa em relação ao PCI-DSS 4.0, ISO 27001, Cyber Essentials Plus, NIS2 onde aplicável, e obrigações específicas do setor. A conformidade exporá suposições frágeis, portanto, defina o preço dos controles, evidências, testes e propriedade operacional antes da janela de alteração.
Monitoramento pós-migração e desativação contínua
A ativação é o início da responsabilidade. Assim que o novo serviço carregar o tráfego de produção, a equipe precisará de uma linha de base que prove se a migração melhorou as operações ou apenas moveu as mesmas falhas para um console diferente.
Monitore a latência de autenticação RADIUS, taxa de falha do Captive Portal, sucesso de associação de access points, tempo de entrega de renovação de certificado, divergências de políticas, contatos de suporte e objetivos de serviço no nível do inquilino onde o isolamento de múltiplos inquilinos for importante. Dê 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
Use um ritmo de revisão de 30, 60 e 90 dias. A primeira revisão deve identificar desvios de configuração, alertas ausentes, falhas recorrentes de autenticação e soluções paliativas do suporte. A segunda deve testar se o serviço está operando sem a intervenção da equipe de migração. A terceira deve decidir se a plataforma legada está pronta para ser desativada.
Não declare vitória só porque a nova plataforma está ativa em um fim de semana tranquilo. Compare o comportamento ao longo dos ciclos de negócios, grupos de inquilinos, classes de dispositivos e eventos operacionais. O setor de hotelaria precisa de variação de ocupação, o varejo precisa de condições comerciais, a saúde precisa de fluxos de trabalho clínicos aprovados e os condomínios residenciais precisam de integração de inquilinos e acesso comunitário.
Descomissionamento em etapas 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: Interrompa alterações, encerre canais de suporte, arquive configurações aprovadas e atualize os registros de propriedade.
- Revogação de confiança: Revoque certificados obsoletos, desative contas de serviço antigas, remova sincronizações de diretório não utilizadas e elimine caminhos de acesso residuais.
- Desativação de rede: Remova túneis VPN legados, políticas, integrações e dependências de gerenciamento, depois recupere espaço de endereçamento e licenças.
- Transferência de conhecimento: Armazene a arquitetura final, log de decisões, evidências de testes, histórico de incidentes e procedimentos operacionais onde a equipe de suporte possa encontrá-los.
Uma análise do governo do Reino Unido sobre a complexidade de ambientes legados descreveu os sistemas legados como antigos, vulneráveis, sem suporte e uma limitação para a transformação. Essa fonte já estabeleceu a escala do problema. Seu trabalho após a migração é garantir que o ambiente antigo não permaneça como uma fronteira de segurança sem proprietário.
O Purple oferece autenticação WiFi baseada em nuvem e redes baseadas em identidade para convidados, funcionários e ambientes multi-tenant, com integrações para serviços de diretório e plataformas de rede. Visite o site do Purple para avaliar se seus recursos de identidade, acesso de convidados, análise e migração se alinham ao seu plano de migração de sistemas legados.
