Estratégias de migração para a nuvem: os 7 Rs, descoberta, ondas e cutover

A maioria dos programas de migração não atrasa por causa da tecnologia. Copiar uma máquina virtual, replicar um banco de dados e apontar o DNS para outro lugar são mecânicas bem conhecidas e com ferramental de sobra. O que dá errado é que ninguém consegue dizer com segurança quais das quatrocentas aplicações do inventário ainda importam, quem é o dono delas, com o que elas conversam ou o que acontece se uma delas parar por seis horas. Uma migração é um exercício de gestão de portfólio fantasiado de projeto de engenharia.

Este guia segue a sequência de um programa real: descobrir o que você tem, decidir uma estratégia por aplicação, construir o destino, mover os dados, fazer o cutover e repetir em ondas. Ele pressupõe familiaridade com os fundamentos da nuvem e, quando o destino for o Azure, com a hierarquia descrita em fundamentos do Azure.

Descoberta: saber o que você realmente roda

A descoberta responde a três perguntas por aplicação: o que ela é, do que ela depende e quanto custa mantê-la rodando do jeito que está.

O ferramental automatizado faz a primeira passada. Scanners sem agente leem os inventários dos hypervisors e os fluxos de rede; coletores com agente acrescentam detalhes no nível de processo e histórico de desempenho. Tanto a AWS quanto o Azure oferecem serviços de avaliação de migração que recomendam um destino bem dimensionado a partir de várias semanas de uso observado de CPU, memória, disco e rede. Leve esse histórico de desempenho a sério: é o artefato mais valioso que a descoberta produz, porque é a única defesa contra reprovisionar na nuvem um parque dimensionado para o pico.

A automação não vai te dizer o que de fato decide o plano: quem aprova o downtime, qual contrato de fornecedor proíbe rodar fora de um data center específico, qual banco de dados é, discretamente, o sistema de registro de um relatório regulatório. Isso vem de entrevistas, e o resultado é uma ficha de portfólio por aplicação:

O mapeamento de dependências é onde o risco de verdade se esconde. Os dados de fluxo revelam as conexões que ninguém documentou: um arquivo depositado toda noite em um compartilhamento SMB, um endereço IP fixo no código de um job batch, uma ferramenta de relatórios mantendo uma conexão aberta com uma réplica de produção. Construa o mapa a partir do tráfego observado durante pelo menos um mês inteiro, para que os jobs trimestrais e de fim de mês apareçam, e depois agrupe as aplicações em grupos de migração (move groups): conjuntos que precisam migrar juntos porque separá-los colocaria uma conversa muito tagarela e sensível à latência atravessando um link de rede.

Os sete Rs

Depois que você sabe o que é uma aplicação, atribui a ela uma estratégia. A lista começou com cinco itens e hoje, por convenção, tem sete.

Retire (aposentar). Desligar. Na maioria dos parques, de dez a vinte por cento das aplicações não têm usuários ou duplicam outra coisa. Cada aposentadoria elimina custo de migração, custo de licença e superfície de ataque. É a opção de maior retorno e a mais difícil de aprovar, porque alguém precisa aceitar o risco de estar errado.

Retain (manter). Deixar onde está, por enquanto. Justifica-se por uma dependência de mainframe, uma substituição iminente, um regulador que ainda não aprovou a região de destino ou um hardware que ainda não foi depreciado. Manter precisa vir com uma data de revisão; caso contrário, vira um data center permanente com três servidores dentro e um contrato de suporte completo.

Rehost (re-hospedar). Mover a carga como ela está — o famoso "lift and shift". Ferramentas de replicação em nível de bloco copiam servidores em execução para máquinas virtuais na nuvem com minutos de downtime no cutover. É rápido, de baixo risco e não exige mudança na aplicação; também leva junto todas as ineficiências, então um parque re-hospedado costuma custar mais por unidade de trabalho do que o hardware que deixou para trás, até ser otimizado.

Replatform (trocar de plataforma). Mover com mudanças pontuais que trazem um benefício desproporcional — o "lift and reshape". Movimentos típicos: apontar a aplicação para um banco de dados gerenciado em vez de um administrado por você, colocá-la atrás de um load balancer gerenciado com certificados gerenciados, containerizá-la sem redesenhá-la ou trocar um compartilhamento de arquivos por object storage. A lógica da aplicação fica intocada; o fardo operacional cai drasticamente. Na maioria dos parques, é a melhor escolha padrão quando nenhum prazo exige o rehost.

Repurchase (recomprar). Substituir por um produto comercial, geralmente SaaS. Comum para CRM, RH, ticketing, colaboração e e-mail. O trabalho de migração passa a ser migração de dados, integração e gestão da mudança, em vez de infraestrutura, e o custo total costuma ser dominado pelos dois últimos.

Refactor (refatorar). Reescrever partes significativas para usar serviços cloud-native e, muitas vezes, mudar a arquitetura — decompor um monólito, passar para processamento orientado a eventos, ir para serverless. É o que traz o maior benefício de longo prazo e consome o maior orçamento e as pessoas mais seniores. Reserve para aplicações com um business case específico: um sistema que não escala para um plano de crescimento conhecido, ou um cujo lead time de mudanças está travando receita. Refatorar em cima do prazo de saída de um data center é a receita para estourar prazos.

Relocate (realocar). Mover um parque de virtualização inteiro para uma versão hospedada na nuvem da mesma pilha de hypervisor, sem converter as máquinas uma a uma. É atraente quando um grande parque VMware precisa sair de um prédio rapidamente e o esforço de conversão é inviável; preserva o ferramental e as competências, e adia em vez de resolver a questão da modernização.

Escolhendo uma estratégia por aplicação

Uma heurística prática, aplicada aplicação por aplicação e depois conferida no nível do portfólio:

Is anyone using it?                          no  -> Retire
Is there a credible SaaS equivalent?         yes -> Repurchase
Is it blocked (licence, latency, regulator)? yes -> Retain (with review date)
Is change lead time or scale a real problem
   AND is there budget and appetite?         yes -> Refactor
Would swapping 1-2 components remove most
   of the operational burden?                yes -> Replatform
Is the deadline immovable?                   yes -> Rehost, optimise later
Is the estate large and time short?          yes -> Relocate

Duas verificações no nível do portfólio importam mais do que a resposta por aplicação. Primeiro, o mix: um plano com noventa por cento de rehost vai cumprir a data e decepcionar todo mundo em custo, enquanto um plano com trinta por cento de refactor não vai cumprir a data de jeito nenhum. Algo como sessenta por cento de rehost e replatform, dez a quinze por cento de aposentadorias e um punhado de refactors escolhidos pelo impacto no negócio é um formato que costuma sobreviver ao contato com a realidade. Segundo, o sequenciamento: coloque os refactors em uma trilha separada, com financiamento próprio, para que uma reescrita atrasada não bloqueie a saída de um data center.

A landing zone vem primeiro

Nada deve ser migrado até que o destino esteja pronto para recebê-lo com segurança. Uma landing zone é a fundação pré-construída e automatizada em que toda carga migrada aterrissa. Os dois grandes provedores publicam implementações de referência, e construir a sua a partir de uma delas sai muito mais barato do que inventá-la.

No mínimo, ela oferece:

• Estrutura de contas ou assinaturas com fronteiras separadas para produção, não produção, serviços de plataforma compartilhados, ferramental de segurança e arquivamento de logs.
• Integração de identidade — federação com o diretório corporativo, grupos mapeados para papéis, nenhuma credencial de longa duração, contas de emergência (break-glass) documentadas e com alarmes.
• Topologia de rede — hub-and-spoke ou equivalente, faixas de endereços alocadas para não colidir com o on-premises, conectividade de volta ao data center via circuito privado ou VPN, resolução de DNS funcionando nos dois sentidos.
• Guardrails — políticas que impedem a criação de recursos em regiões não aprovadas, exigem criptografia e tags, e bloqueiam storage público por padrão. Controles preventivos, não um relatório publicado todo mês.
• Logging e monitoramento — logs de auditoria centralizados gravados em uma conta que mais ninguém pode alterar, além de uma stack de monitoramento à qual as cargas se conectam, em vez de cada uma inventar a sua.
• Um pipeline e templates, para que aterrissar uma carga signifique rodar automação, não clicar. É a parte do programa em que a disciplina de infraestrutura como código mais compensa.

DNS híbrido e faixas de IP sobrepostas merecem menção especial: são assuntos chatos, descobertos tarde, e já atrasaram mais migrações do que qualquer problema de aplicação.

Movendo os dados

Os dados são a parte que não dá para refazer rapidamente, por isso são eles que ditam o desenho do cutover.

Transferência em massa. Para grandes conjuntos de dados estáticos, faça a conta com honestidade: um terabyte em um link de um gigabit saturado leva cerca de três horas na taxa teórica da linha e bem mais na prática, e parques medidos em centenas de terabytes estouram a janela. Appliances de transferência física — dispositivos robustos que são enviados até você, carregados com os dados e devolvidos — existem exatamente para isso e costumam ser mais rápidos e baratos do que fazer upgrade de um circuito para uma operação pontual.

Replicação contínua. Para bancos de dados, o padrão é um serviço de replicação que faz uma carga completa e depois aplica as mudanças contínuas a partir do log de transações até que origem e destino estejam sincronizados. O AWS Database Migration Service e o Azure Database Migration Service fazem isso, inclusive em migrações heterogêneas em que o engine muda, com uma etapa prévia de conversão de schema. Deixe a replicação rodando por dias antes do cutover para que o atraso seja medido, não presumido.

Validação. Contar linhas é o começo, não o fim. Compare checksums por tabela, concilie um total no nível de negócio (o valor dos pedidos de ontem, o balancete) e execute os caminhos de leitura da própria aplicação contra o destino antes que alguém se comprometa.

A abordagem de migração então assume um de três formatos:

A execução em paralelo — os dois sistemas no ar, um deles como fonte da verdade — é a mais segura e a mais cara, porque alguém precisa conciliar os dois e decidir o que acontece quando eles divergem.

Ondas, cutover e rollback

As migrações avançam em ondas: lotes de grupos de migração agendados juntos. A primeira onda é um piloto, e o objetivo dela é aprender, não ganhar volume. Escolha duas ou três aplicações reais, com dono, e sem importância suficiente para que um fim de semana ruim seja suportável, e instrumente o próprio processo — quanto tempo cada etapa levou, o que o runbook tinha de errado, quais permissões faltaram.

Cada onda seguinte deve ter critérios de entrada por escrito (landing zone pronta, aprovação do dono, dependências já migradas ou na mesma onda), um runbook com responsáveis nomeados e tempos, e critérios de saída explícitos: taxas de erro e latência dentro de uma faixa acordada, jobs batch concluídos com sucesso, conciliação sem divergências, monitoramento alertando corretamente.

O plano de rollback é o que torna seguro tentar tudo isso, e ele precisa ser mais específico do que "a gente volta". Deixe por escrito o ponto sem volta — geralmente o momento em que o destino passa a aceitar escritas que não são replicadas de volta — e como é a decisão de cada lado desse ponto. Antes dele, o rollback é apontar de novo o DNS ou um load balancer para a origem. Depois dele, rollback significa replicação reversa ou reprocessamento de transações, o que precisa ter sido testado se você pretende afirmar que existe.

Logo após cada onda, faça duas coisas que os programas costumam pular: descomissione a origem, porque pagar pelos dois parques é o estouro de custo clássico; e redimensione o destino com base em duas semanas de métricas reais da nuvem, em vez da estimativa on-premises — é daí que vêm de fato as economias que financiaram o programa. Veja gestão de custos na nuvem.

Riscos que vale nomear no plano

Regressões de desempenho por arquiteturas divididas. Durante uma migração, é comum uma aplicação na nuvem conversar com um banco de dados que continua on-premises. Uma troca que levava microssegundos passa a custar milissegundos por ida e volta, e código ORM tagarela degrada de forma não linear. Migre componentes acoplados na mesma onda.

Licenças atreladas ao hardware. Alguns fornecedores cobram por núcleo físico ou proíbem a hospedagem virtualizada. Verifique antes de desenhar o destino, não depois.

Integrações não documentadas que disparam a cada trimestre. Um mês de dados de fluxo não captura o job de fechamento do ano. Pergunte às áreas de finanças e operações o que acontece nos fechamentos de período.

A cauda sem dono. Aplicações sem um dono identificável não podem ser aposentadas nem migradas. Escale esses casos cedo, com um padrão anunciado — geralmente "vamos desligar nesta data, a menos que alguém a reivindique" —, porque a alternativa é descobrir o dono na semana cinquenta.

Competências e cansaço. Cutovers acontecem nos fins de semana. Um cronograma que pressupõe que os mesmos seis engenheiros vão encarar doze fins de semana seguidos é um plano para perdê-los no meio do programa.

Principais conclusões

• É a descoberta, não a tecnologia, que determina o sucesso de uma migração: fichas de portfólio, utilização observada e um mapa de dependências construído com pelo menos um mês de tráfego.
• Os sete Rs — retire, retain, rehost, replatform, repurchase, refactor, relocate — são atribuídos aplicação por aplicação, e o mix do portfólio decide se o programa cumpre a data.
• Aposentar aplicações mortas é o ganho mais barato disponível, e o rehost é legítimo desde que o trabalho de otimização esteja agendado, e não apenas presumido.
• A landing zone — contas, identidade, rede, guardrails, logging, pipelines — precisa existir antes que a primeira carga seja migrada.
• A abordagem de migração de dados decorre do downtime aceitável; valide com conciliação no nível de negócio, não com contagem de linhas.
• As ondas precisam de critérios de entrada e de saída, um ponto sem volta nomeado, um rollback ensaiado e o descomissionamento imediato da origem para parar de pagar em dobro.