Como migrar servidores para o Azure com plano de ondas

Por que migrar servidores para o Azure

Migrar servidores para o Azure deixou de ser um projeto de infraestrutura isolado e passou a ser uma decisão de negócio. Contratos de datacenter vencendo, hardware no fim da vida útil, custos de energia e a necessidade de escalar rápido empurram empresas no Brasil e nos Estados Unidos para a nuvem. O desafio raramente é técnico: é fazer a migração sem interromper a operação e sem estourar o orçamento.

A abordagem que reduz risco é sempre a mesma: descobrir o ambiente, avaliar cada carga de trabalho, agrupar servidores em ondas e migrar em incrementos testáveis. A ferramenta central para isso é o Azure Migrate, um hub gratuito que a Microsoft oferece para descoberta, avaliação e movimentação de servidores, bancos de dados e aplicações web.

As fases de uma migração bem-sucedida

Um projeto conduzido pela RHC como Microsoft Solutions Partner costuma seguir cinco fases claras:

1. Descoberta e inventário — mapear todos os servidores, sistemas operacionais, CPU, memória, disco e tráfego de rede.
2. Avaliação (assessment) — dimensionar o destino no Azure e estimar custo mensal.
3. Planejamento de ondas — agrupar servidores por dependência e criticidade.
4. Migração (replicação e cutover) — replicar dados e fazer a virada com janela mínima.
5. Otimização e desligamento — ajustar tamanho, aplicar reservas e desativar o datacenter antigo.

Descoberta com o dispositivo do Azure Migrate

O Azure Migrate usa um appliance (uma máquina virtual leve instalada no ambiente atual) que coleta dados de desempenho sem instalar agentes em cada servidor. Para ambientes VMware, Hyper-V ou servidores físicos, o appliance observa por alguns dias e captura picos reais de uso — isso evita superdimensionar o destino.

O ponto mais valioso da descoberta é o mapeamento de dependências. Um servidor de aplicação que conversa com um banco de dados e um serviço de autenticação precisa migrar junto ou com conectividade garantida. Ignorar dependências é a causa número um de cutovers que falham.

Avaliação: right-sizing desde o início

Na avaliação, o Azure Migrate compara o consumo real com os tamanhos de VM disponíveis e recomenda o SKU adequado. Você escolhe o critério:

Aplicar o Azure Hybrid Benefit e planejar Instâncias Reservadas já na avaliação muda completamente o retorno do projeto. É comum ver a estimativa inicial cair de forma expressiva quando essas duas alavancas entram na conta.

O plano de ondas

A onda é o coração da migração de baixo risco. Em vez de mover tudo de uma vez, você organiza grupos de servidores que migram juntos. Bons critérios para montar ondas:

• Baixa criticidade primeiro — ambientes de teste e desenvolvimento validam o processo.
• Dependências agrupadas — aplicação, banco e middleware na mesma onda.
• Janela de negócio — respeitar horários de menor uso de cada área.
• Complexidade crescente — cargas simples antes de sistemas legados sensíveis.

Uma sequência típica de ondas:

1. Onda 0 (piloto): servidores de teste, sem impacto no negócio.
2. Onda 1: aplicações internas de baixa criticidade.
3. Onda 2: cargas de produção de médio porte.
4. Onda 3: sistemas críticos e bancos de dados principais.
5. Onda 4: exceções, legados e casos que exigem modernização.

Cada onda termina com um checklist de validação: aplicação responde, usuários acessam, backups configurados e monitoramento ativo.

Replicação e cutover

Na migração propriamente dita, o Azure Migrate replica os discos do servidor para o Azure de forma contínua, mantendo o servidor original ligado. Quando a réplica está sincronizada, você executa um teste de migração em uma rede isolada — liga a VM no Azure sem afetar produção e valida tudo. Só depois vem o cutover definitivo, com uma janela curta para a sincronização final.

Essa mecânica de replicação contínua com teste prévio é o que permite virar sistemas de produção com minutos de indisponibilidade, não horas.

Erros comuns que a RHC ajuda a evitar

• Migrar sem avaliar dependências, causando quebra de integrações.
• Fazer lift-and-shift de tudo, incluindo servidores que deveriam ser aposentados ou modernizados.
• Esquecer rede e segurança — sub-redes, NSGs, firewall e conectividade híbrida precisam estar prontos antes da primeira onda.
• Não planejar economia — deixar Hybrid Benefit e reservas para depois costuma custar caro.
• Desligar o datacenter antigo cedo demais — mantenha rollback disponível por um período.

Checklist / Key takeaways

• Use o Azure Migrate para descoberta sem agentes e avaliação baseada em desempenho.
• Trate o mapeamento de dependências como requisito, não como opcional.
• Aplique Azure Hybrid Benefit e Instâncias Reservadas já na estimativa de custo.
• Organize a migração em ondas da menor para a maior criticidade.
• Sempre faça teste de migração em rede isolada antes do cutover.
• Mantenha rollback e só desligue o datacenter após estabilização.

Como parceira Microsoft e CSP, a RHC conduz esse processo de ponta a ponta — da descoberta ao desligamento do datacenter — mantendo previsibilidade de custo e continuidade da operação.