Guia de migração para Azure sem paragens

Migrar servidores, dados e aplicações para a cloud não é um projecto de cópia de máquinas virtuais. Um guia de migração para Azure só é útil quando responde às perguntas que afectam a operação: que sistemas podem parar, quanto tempo, que dados se podem perder e quem assume a responsabilidade quando algo falha. Para uma empresa que depende diariamente do ERP, do e-mail, dos ficheiros partilhados ou de aplicações industriais, a resposta não pode ser «vamos migrar e ver o que acontece».

O Azure pode trazer escala, segurança e flexibilidade, mas não corrige uma arquitectura mal conhecida nem substitui processos de recuperação inexistentes. O resultado depende do diagnóstico inicial, das decisões de arquitectura e de uma operação posterior com governance activa. Arquitectos antes de vendedores: é esse o princípio que evita transformar uma iniciativa de modernização numa fonte de indisponibilidade e custo variável sem controlo.

Guia de migração para Azure: começar pelo impacto no negócio

O inventário técnico é indispensável, mas não chega. Saber que existem 40 servidores não explica quais suportam processos críticos, quais têm dependências entre si ou quais são mantidos por uma aplicação antiga sem documentação. Antes de escolher serviços Azure, é necessário classificar as cargas de trabalho pelo seu impacto operacional.

O ponto de partida deve estabelecer objetivos de continuidade claros. O RTO define o tempo máximo aceitável para recuperar um serviço. O RPO define a antiguidade máxima dos dados que a empresa aceita perder. Um servidor de impressão pode tolerar horas de indisponibilidade; uma base de dados de faturação ou uma plataforma logística pode exigir recuperação em minutos e perda de dados próxima de zero. Não se aplica a mesma arquitectura, nem o mesmo orçamento, a ambos os casos.

Nesta fase, a equipa deve identificar dependências de rede, integrações com fornecedores, contas de serviço, certificados, licenças, volumes de dados, versões de sistemas operativos e requisitos de conformidade. Também é essencial avaliar a ligação entre o datacenter local e o Azure. Numa migração pode correr tecnicamente bem e, ainda assim, degradar a experiência dos utilizadores se a conectividade, a latência ou a resolução de nomes não forem tratadas.

Há uma decisão de gestão tão relevante como a tecnológica: definir quem aprova alterações, quem valida cada aplicação e quem pode declarar um incidente encerrado. Sem responsáveis do lado do negócio, os testes tornam-se genéricos e os riscos ficam por validar.

As quatro opções de migração e os seus compromissos

Nem todas as cargas de trabalho devem ser tratadas da mesma forma. O modelo mais rápido é o rehost, muitas vezes designado lift-and-shift: a máquina virtual é replicada para o Azure com alterações mínimas. Pode ser adequado para reduzir a exposição de hardware em fim de vida ou para acelerar uma saída de datacenter, mas transfere para a cloud problemas que já existiam, incluindo sistemas sobredimensionados, configurações pouco seguras e custos de licenciamento desnecessários.

O replatform introduz melhorias controladas sem reescrever a aplicação. Por exemplo, uma base de dados pode passar a um serviço gerido ou uma aplicação pode ganhar mecanismos de escalabilidade e backup mais consistentes. Exige mais planeamento, mas tende a reduzir tarefas operacionais e a melhorar a capacidade de recuperação.

O refactor é a opção mais profunda. Implica adaptar a aplicação para serviços cloud-native, como componentes geridos, automação e modelos de escalabilidade diferentes. Pode gerar ganhos relevantes a médio prazo, mas não deve ser confundido com uma migração urgente. Se a aplicação é crítica e pouco documentada, mexer no código durante uma mudança de infraestrutura aumenta o risco.

Por fim, algumas cargas devem ser mantidas localmente, substituídas por SaaS ou simplesmente retiradas. Num ambiente híbrido não representa falta de ambição. É frequentemente a decisão mais racional quando existem equipamentos de fábrica, requisitos de baixa latência, dados com condicionantes específicas ou investimentos on-premises ainda válidos. A boa arquitectura é a que suporta o negócio, não a que força tudo para a cloud pública.

Arquitectura: segurança e conectividade antes da primeira réplica

Numa subscrição Azure sem estrutura rapidamente se transforma num conjunto difícil de governar. Antes da migração, devem ficar definidos os grupos de gestão, subscrições, permissões, convenções de naming, tags de custo, redes virtuais, segmentação e políticas. Isto permite atribuir responsabilidade, limitar privilégios e perceber quem consome recursos e porquê.

A segurança deve ser desenhada desde o início. Identidade, autenticação multifator, acesso condicional, segregação de funções e protecção de contas privilegiadas são elementos centrais. Também é necessário decidir como ligar a rede local ao Azure, que tráfego pode circular entre segmentos e como registar eventos para investigação. Abrir acessos amplos para «fazer funcionar» durante a migração é uma prática comum e um erro que pode permanecer invisível durante meses.

O backup merece uma distinção clara: replicação não é backup. A replicação ajuda a recuperar disponibilidade e a reduzir o RTO, mas pode replicar corrupção, eliminação acidental ou encriptação provocada por ransomware. A estratégia deve incluir retenção adequada, cópias imutáveis quando aplicável, controlo de acessos e testes reais de restauro. Se nunca foi feito um restauro completo, não existe garantia operacional de recuperação.

A optimização de custos também começa aqui. Dimensionar máquinas virtuais com base em estimativas, sem recolha de métricas, conduz a duas situações: recursos insuficientes que afectam o desempenho ou capacidade excessiva paga todos os meses. Reserved Instances, Azure Hybrid Benefit, desligamento programado de ambientes não produtivos e alertas de orçamento podem fazer sentido, mas dependem do perfil de utilização e da duração previsível das cargas.

Implementação por ondas, não por impulso

Numa migração controlada deve ser feita por ondas. Começa-se com cargas de baixo risco que permitem validar conectividade, identidade, monitorização, backup e procedimentos de mudança. Seguem-se aplicações com dependências conhecidas e, apenas depois, os sistemas mais críticos. Cada onda deve ter um âmbito, uma janela de mudança, critérios de sucesso, plano de reversão e responsáveis nomeados.

Os testes devem simular a realidade de utilização. Não basta confirmar que um servidor responde a ping ou que uma aplicação abre num browser. É preciso validar integrações, permissões, impressão, desempenho, tarefas agendadas, exportações, recuperação de dados e acessos remotos. Quando uma aplicação serve vários departamentos, cada área deve validar os seus processos críticos antes do corte definitivo.

O plano de reversão é especialmente importante. Deve definir o momento a partir do qual já não é seguro recuar, os dados que precisam de ser sincronizados e as condições que obrigam a voltar ao ambiente anterior. Ter este plano não é sinal de desconfiança no projecto. É uma medida de controlo que protege a continuidade operacional quando surgem comportamentos não previstos.

Durante a janela de migração, a comunicação deve ser objetiva. Os utilizadores precisam de saber o que muda, quando podem ser afectados e a quem devem reportar anomalias. A equipa técnica necessita de uma lista de verificações e de canais de escalonamento. Um processo simples e bem executado é preferível a uma cadeia extensa de fornecedores sem dono claro do incidente.

Operar o Azure depois da entrada em produção

A entrada em produção não encerra a responsabilidade. A partir desse momento começa a operação: monitorizar disponibilidade e desempenho, analisar alertas, rever consumos, aplicar correcções, testar recuperação e ajustar capacidades. Sem este ciclo, a cloud passa a ser apenas outro datacenter, com uma fatura mensal mais difícil de interpretar.

Numa operação madura combina monitorização 24/7 quando o serviço o justifica, SLA contratual, gestão de incidentes e revisão periódica. A revisão deve olhar para indicadores concretos: cumprimento de RTO e RPO, sucessos de backup, tendências de capacidade, eventos de segurança, custos por área e aplicações que continuam a consumir recursos sem utilidade. É também o momento de confirmar se as políticas suportam obrigações de conformidade, incluindo as exigências de cibersegurança aplicáveis ao sector da organização.

Para muitas empresas, a melhor abordagem é manter uma equipa interna focada no negócio e recorrer a um parceiro que assuma arquitectura, implementação e operação da infraestrutura. A ITPOINT trabalha precisamente nesta lógica: não vender componentes isolados, mas assumir responsabilidade pela stack, com acesso directo a especialistas e um modelo de suporte definido por SLA.

A migração para Azure vale pelo que permite fazer depois: recuperar mais depressa, limitar o impacto de um incidente, dar capacidade às equipas e manter custos previsíveis. Quando essas condições estão desenhadas antes da primeira migração, a cloud deixa de ser uma promessa tecnológica e passa a ser uma decisão operacional controlada.