Lift-and-shift ou modernizar? Como decidir no Azure

A pergunta que define o projeto

Toda migração para o Azure passa por uma decisão que muda custo, prazo e valor: mover como está (lift-and-shift) ou modernizar? Não existe resposta única. Modernizar tudo atrasa e encarece o projeto; mover tudo como está desperdiça o potencial da nuvem. A maturidade está em escolher a estratégia carga por carga.

Como parceira Microsoft e CSP, a RHC usa um framework consagrado para essa decisão: os 6 Rs da migração.

Os 6 Rs da migração

Na prática, a maioria dos projetos combina Rehost para ganhar velocidade e Replatform/Refactor onde o retorno justifica.

Lift-and-shift (Rehost): velocidade primeiro

O lift-and-shift move o servidor para o Azure praticamente inalterado. É a estratégia mais rápida e de menor risco, ideal quando:

• O datacenter está vencendo e o prazo é curto.
• A aplicação é estável e não será muito alterada.
• Você quer sair do hardware agora e otimizar depois.
• A aplicação é legada e reescrevê-la não compensa.

A vantagem é a velocidade; a desvantagem é que você leva as ineficiências junto — a aplicação não ganha elasticidade, resiliência gerenciada nem redução de custo operacional automaticamente. Por isso, o lift-and-shift costuma ser o primeiro passo, não o destino final.

Modernizar (Replatform e Refactor): valor primeiro

Modernizar significa aproveitar os serviços gerenciados (PaaS) do Azure, que tiram da sua equipe o trabalho de manter sistema operacional, patches e infraestrutura. Exemplos de ganho:

• Trocar um SQL Server em VM por Azure SQL Managed Instance ou Azure SQL Database — sem gerenciar o servidor, com alta disponibilidade embutida.
• Mover uma aplicação web de uma VM para o Azure App Service — escala e deploy simplificados.
• Adotar serverless (Azure Functions) para cargas orientadas a eventos, pagando só pelo uso real.

O replatform faz ajustes pontuais (o exemplo clássico é migrar o banco para PaaS mantendo o resto). O refactor vai mais fundo, reescrevendo partes da aplicação. Quanto maior o esforço, maior o retorno em custo operacional, escalabilidade e resiliência.

Como decidir carga por carga

A decisão não é ideológica, é econômica. Perguntas que guiam:

1. Qual o prazo? Datacenter vencendo empurra para Rehost primeiro.
2. A aplicação muda muito? Aplicações em evolução ativa justificam modernizar; legados congelados, não.
3. Qual o custo operacional atual? Cargas que consomem muita manutenção se pagam ao virar PaaS.
4. Qual a criticidade? Sistemas críticos ganham com a resiliência gerenciada da nuvem.
5. Vale a pena existir? Às vezes a melhor estratégia é Retire (aposentar) ou Replace por um SaaS.

A abordagem em duas velocidades

A estratégia que mais funciona na prática combina as duas:

• Onda 1 — Rehost: sair do datacenter rápido, cortando o risco de hardware e contrato. A aplicação já roda no Azure.
• Onda 2 — Modernizar: depois de estabilizar, evoluir as cargas de maior retorno para PaaS, uma a uma, sem a pressão do prazo do datacenter.

Isso captura o melhor dos dois mundos: velocidade agora, valor depois. É comum que o banco de dados seja o primeiro alvo de modernização, dado o alto custo de mantê-lo em VM.

Erros comuns

• Modernizar tudo de uma vez — atrasa o projeto e aumenta o risco.
• Rehost como destino final — perde a economia e a resiliência da nuvem.
• Ignorar o Retire — migrar servidores que deveriam ser desligados.
• Decidir por moda, não por retorno — cada carga tem sua conta.

Checklist / Key takeaways

• Decida a estratégia carga por carga usando os 6 Rs.
• Rehost (lift-and-shift) entrega velocidade e menor risco no curto prazo.
• Replatform e Refactor entregam valor de longo prazo com PaaS.
• Considere Retire/Replace antes de migrar o que não deveria existir.
• Adote a abordagem em duas velocidades: sair rápido, modernizar depois.
• Trate a decisão como econômica, baseada em prazo, custo e criticidade.

A RHC ajuda a mapear cada carga, aplicar os 6 Rs e desenhar o plano em ondas que equilibra velocidade e modernização conforme o retorno de cada sistema.