Insights · Modernização de legado

Lift and shift vs modernização: o que muda de verdade

Publicado em 15 de outubro de 2026

Lift and shift (também chamado de rehost) é mover um sistema de um ambiente para outro, em geral de um datacenter para a nuvem, sem mudar a aplicação: o código e a arquitetura seguem os mesmos. A regra de negócio, os acoplamentos e a forma de entregar continuam iguais; muda o endereço onde a carga roda. Modernização é outra decisão: preservar a regra de negócio e mudar, de propósito, arquitetura, stack e práticas. Este texto compara os dois caminhos, mostra quando a migração pura ainda faz sentido e como combiná-los sem chamar de modernização o que só trocou de servidor.

A definição de sistema legado e a tabela curta de caminhos (rehost, replatform, refactor, rewrite, strangler fig) estão em Sistema legado: o que é, sinais de risco e quando modernizar. O passo a passo depois da decisão de modernizar está em Como modernizar um sistema legado: guia passo a passo. A conta da dívida, em Custo da dívida técnica: quanto a empresa paga, e como estimar. O nível de maturidade da organização, em Maturidade em modernização de legado: 4 níveis e autodiagnóstico. Aqui o foco é só: lift and shift versus modernização.

O que é lift and shift (rehost)

No guia prescritivo da AWS para migrações grandes, que organiza as estratégias de migração em sete (os 7 Rs), rehost é o nome formal do lift and shift: levar a aplicação do ambiente de origem para a nuvem sem fazer mudanças na aplicação. O glossário do Migration Lens, também da AWS, repete a definição. Na Cloud Adoption Framework (CAF) da Microsoft, que trabalha com oito estratégias, o rehost é uma migração like-for-like, com mudança mínima: máquina virtual vai para IaaS, IaaS para IaaS, PaaS para PaaS. São guias de fornecedores de nuvem, não pesquisa de mercado; servem como vocabulário comum.

Na prática, o executável, as bibliotecas, o banco (muitas vezes no mesmo motor) e o jeito de fazer deploy viajam juntos. O que muda é a camada de baixo: máquina, armazenamento, contrato de datacenter. O que não muda é o que já pesava antes: o monólito, se havia um; a linguagem sem suporte; a falta de testes; o medo de tocar o núcleo.

O guia público The Code Modernization Playbook, da Anthropic (fornecedor de modelos de IA para esse tipo de trabalho), resume a crítica com uma imagem: muita gente já viu migrações lift-and-shift que prometem ganho rápido e, no fim, só levam os problemas para um imóvel mais sofisticado, a um custo nada pequeno. É a visão de um fornecedor, não estatística. Vale como alerta para a conversa.

Quando o lift and shift faz sentido

Demonizar o rehost é tão errado quanto chamá-lo de modernização. Há situações em que a migração pura é a decisão racional:

Prazo para sair do datacenter (fim de contrato, venda do prédio, consolidação) que não espera a reescrita do núcleo.
Fim de contrato de colocation ou de hardware, com multa ou custo crescente se a carga ficar.
Portfólio grande, em que a primeira onda precisa desligar máquinas físicas com risco baixo e a modernização vem nas ondas seguintes.
Carga estável, com pouca mudança de regra, compatível com a nuvem de destino e sem necessidade imediata de redesenho.

Esses casos batem com os indicadores que a CAF da Microsoft lista para rehost: carga estável e compatível com o Azure, migração de baixo risco, metas de curto prazo, nenhuma necessidade imediata de modernizar, reduzir despesa de capital e liberar espaço no datacenter.

A mesma CAF faz dois avisos. Primeiro, não rehoste carga problemática: o rehost não resolve problemas de performance, de confiabilidade ou de arquitetura, e migrar essa carga sem modernizar pode levar a dívida técnica adiante e exigir retrabalho depois. Segundo, o rehost só é indicado quando há confiança de que a carga vai continuar como está por pelo menos dois anos; se a modernização for provável antes disso, a CAF sugere considerar refactor ou rearchitect, para evitar esforço em dobro. São critérios de fornecedor (Microsoft), não norma.

A AWS, no guia de migrações grandes, olha para o volume. Chama o refactor de estratégia mais complexa e cara e não o recomenda durante uma migração grande: prefere rehost, relocate ou replatform e modernizar depois que a migração terminar, quando a aplicação já roda na nuvem e fica mais fácil de otimizar. Ou seja: o lift and shift pode ser o primeiro ato de um plano maior, não o último.

Os dois guias se completam mais do que se contradizem. A AWS fala de muitas aplicações migradas de uma vez; a CAF, de cada carga. Na nossa leitura, a carga estável vai antes e como está, e a carga problemática merece decisão própria.

Por que lift and shift não é modernização

Nos próprios guias de nuvem, rehost não conta como modernização. Para a CAF, modernizar durante a migração significa fazer replatform, rearchitect ou refactor; para o rehost, o motivo de negócio que ela registra é justamente não ter modernização prevista no futuro próximo.

Modernizar, na leitura que usamos no site (próxima do Cap. 2 do playbook da Anthropic, visão de fornecedor), não é jogar fora décadas de regra de negócio. É mudar como essa regra vive no sistema, em três pilares: arquitetura, stack e práticas. O detalhe de cada pilar está no guia passo a passo. Aqui interessa o que o rehost deixa igual em cada um:

Arquitetura: o desenho viaja inteiro. Se era um bloco único em que qualquer mudança mexe em tudo, continua sendo, agora em outra máquina.
Stack: mesma linguagem, mesmos frameworks e mesmas versões, inclusive as que perderam suporte.
Práticas: o time entrega como antes. Se o deploy era manual e não havia testes automatizados, nada disso muda com o endereço.

O lift and shift mexe, no máximo, na infraestrutura de baixo. A regra fica no mesmo código, e os acoplamentos ficam onde estavam. Se a fatia da semana do time em manutenção já é alta, mudar de servidor não corta os juros da dívida. Onde esse custo aparece e como estimá-lo está em custo da dívida técnica.

Lift and shift vs replatform, refactor e modernização

Vocabulário mínimo, com as definições da AWS (7 Rs) e o contraste com a modernização por partes, que é como a Ithaca trabalha:

Caminho	O que muda	O que permanece	Quando faz sentido	Limite
Lift and shift (rehost)	Endereço e infraestrutura	Código, arquitetura, práticas	Prazo de datacenter; carga estável; primeira onda de portfólio grande	Dívida e acoplamento viajam juntos
Replatform ("lift, tinker, and shift", na AWS)	Ambiente de execução, com alguma otimização (ex.: banco gerenciado, contêiner)	A maior parte do código e do desenho	Cortar custo de operação ou de licença sem redesenhar	A regra continua sem testes de caracterização, se ninguém os criar
Refactor / re-architect	Arquitetura, aproveitando recursos nativos da nuvem	O comportamento de negócio que precisa ficar	Escalar, acelerar entregas, reduzir custo	Para a AWS, a estratégia mais complexa e cara; em migração grande, ela recomenda deixar para depois
Modernização por partes (como a Ithaca trabalha)	Arquitetura, stack e práticas, preservando a regra, com o novo ao lado do antigo	O que o negócio realmente precisa (o inventário marca o que será desligado)	Sistema que ainda precisa evoluir com segurança	Exige inventário, testes de caracterização, critério de corte e supervisão humana

Replatform e refactor já mudam alguma coisa além do endereço, e a própria CAF os conta como modernização. A diferença para a última linha é de escopo e de método: inventário, testes que fixam o comportamento atual, troca por partes e critério escrito para cada corte.

Sinais de que você só mudou de endereço

Depois do go-live na nuvem, estes sinais mostram que o projeto foi rehost, não modernização:

O mesmo executável (ou o mesmo artefato) sobe no novo ambiente, com a mesma linguagem e o mesmo acoplamento.
Não há testes de caracterização novos nas partes críticas; o time ainda teme tocar o núcleo.
O tempo por mudança nos pontos de maior juro não caiu; a sprint continua tomada por manutenção.
O deploy segue manual ou depende de uma pessoa que "sabe o ritual".
Os incidentes repetem os sintomas de antes; só a fatura de infraestrutura mudou de formato.
Ninguém registrou o que será modernizado na onda seguinte: o rehost virou destino, não etapa.

Se vários itens batem, o próximo passo não é otimizar a máquina. É escolher uma parte, fixar o comportamento atual com testes de caracterização e construir o novo ao lado. Para ver se a organização costuma parar no rehost ou já tem método, use o autodiagnóstico de maturidade.

Como combinar rehost e modernização por partes

Uma sequência que respeita os dois guias, a AWS para o volume e a CAF para cada carga:

Inventariar o que sai do datacenter, o que fica onde está (retain), o que é desligado (retire) e o que é estável o bastante para só mudar de endereço.
Separar as cargas problemáticas. O que já tem performance ruim, arquitetura frágil ou modernização provável nos próximos dois anos não é bom candidato a rehost como está (critério da CAF). Se o prazo do datacenter obrigar a levar assim mesmo, registre por escrito que é etapa, com data para a modernização.
Rehostar o que é estável e precisa sair rápido.
Modernizar por partes os pontos de maior juro, com o novo ao lado do antigo: testes de caracterização, equivalência, critério de corte escrito e volta testada.
Não chamar a etapa 3 de modernização na conversa com a diretoria. Chame de migração. Reserve a palavra modernização para quando arquitetura, stack ou práticas mudarem de propósito.

Quando falta gente que ainda programa em COBOL, Delphi ou VB6, trocar de provedor de infraestrutura não resolve: a escassez de conhecimento pede inventário, preservação da regra e modernização supervisionada. O que fazer nesse caso está em falta de desenvolvedor COBOL, Delphi e VB6; aqui basta o aviso de que o rehost não cria especialistas novos.

Onde entram os agentes de código

Agentes de código podem acelerar a leitura do sistema, a escrita de testes de caracterização e a construção da parte nova. Eles não transformam um rehost em modernização sozinhos. O desenho que a Ithaca usa:

Supervisão: pessoas do time do cliente definem os limites dos agentes e leem o que vai para produção. É o nível 4 da escala de autonomia de agentes de código proposta por Dan Shapiro, e não um modo em que o código vai para produção sem que ninguém o leia.
Rastreabilidade: cada sessão deixa registro de pedido, passos, modelo, custo, resultado e autoria.
A plataforma de desenvolvimento agentic é implantada lado a lado com o seu time; o método para sistemas que não podem parar está em Modernização de sistemas legados com IA, sem parar a operação.

Se o datacenter tem data e o núcleo ainda é caixa-preta, uma combinação possível: rehost agora das partes estáveis; em seguida, um piloto de modernização num módulo periférico de alto juro, com agentes supervisionados e registro de cada sessão.

Agendar demonstração

Perguntas frequentes

O que é lift and shift?

É a estratégia de migração, também chamada de rehost, em que o sistema muda de ambiente, em geral para a nuvem, sem mudar a aplicação. A AWS a descreve como mover a aplicação sem fazer mudanças nela; a Microsoft, como migração like-for-like, com mudança mínima. A regra de negócio e a dívida técnica viajam junto.

Lift and shift é o mesmo que modernização?

Não. Modernização preserva a regra de negócio e muda arquitetura, stack e práticas. Lift and shift muda o endereço. Pode ser o primeiro passo de um plano maior; sozinho, não moderniza. Os guias de migração da AWS e da Microsoft também tratam rehost e modernização como coisas diferentes.

Quando a migração pura para a nuvem ainda vale a pena?

Quando há prazo duro para sair do datacenter ou encerrar um contrato, a carga é estável e não deve precisar de modernização nos próximos dois anos (critério da CAF da Microsoft). Carga problemática, segundo a mesma CAF, não deve ser rehostada como está: a dívida vai junto e o retrabalho vem depois.

O que é replatform e em que difere do lift and shift?

Replatform (na AWS, "lift, tinker, and shift") move a aplicação e introduz algum nível de otimização, como trocar o banco por um serviço gerenciado, sem redesenhar a arquitetura. A CAF da Microsoft o descreve como modernizar o ambiente de hospedagem com mudança mínima de código. Fica aquém de uma modernização completa se a regra, os testes e a forma de entregar não mudarem.

Hospedagem na nuvem resolve a dívida técnica do legado?

Não por si. Trocar servidor, rede ou firewall muda custo e operação de infraestrutura; não cria testes, não documenta regra e não libera quem concentra o conhecimento. A dívida só cai quando você paga o principal nos pontos de maior juro ou moderniza por partes. A conta está em custo da dívida técnica.

Fontes

AWS, "About the migration strategies", AWS Prescriptive Guidance, guia de migrações grandes (documentação de fornecedor de nuvem; acessado em 15/10/2026). https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html (rehost = lift and shift, sem mudanças na aplicação; replatform = "lift, tinker, and shift"; refactor como a estratégia mais complexa e cara; em migrações grandes, modernizar depois da migração). Definições espelhadas no AWS Well-Architected Migration Lens: https://docs.aws.amazon.com/wellarchitected/latest/migration-lens/definitions.html
Microsoft, Cloud Adoption Framework, "Select your cloud migration strategies" (Microsoft Learn; documentação de fornecedor de nuvem; revisão de 15/07/2025; acessado em 15/10/2026). https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/select-cloud-migration-strategy (rehost like-for-like e seus indicadores; não rehostar carga problemática; pelo menos dois anos sem modernização prevista; replatform, rearchitect e refactor como modernização durante a migração).
Anthropic, "The Code Modernization Playbook" (material de fornecedor, sem data no documento; Cap. 2; acessado em 15/10/2026). https://resources.anthropic.com/code-modernization-download (crítica ao lift-and-shift; não jogar fora a regra de negócio; três pilares: arquitetura, stack e práticas; visão de fornecedor).