O lift and shift continua sendo uma das estratégias mais utilizadas por empresas que precisam migrar cargas do data center próprio para a nuvem sem interromper a operação. Segundo a projeção de gastos globais de TI publicada pela Gartner em abril de 2026, o investimento mundial em tecnologia deve chegar a US$6,31 trilhões em 2026, crescimento de 13,5% no ano. Os sistemas de data center avançam 55,8%, reforçando o movimento de renovação da infraestrutura.
A pressão por prazo costuma pesar nessa decisão: contratos próximos do vencimento, hardware no fim da vida útil e exigências de continuidade podem exigir a migração em meses, e não em anos. Nesse cenário, reescrever aplicações antes da mudança pode não ser viável, e mover o ambiente existente com o mínimo de alterações se torna uma alternativa para acelerar a operação em nuvem.
Mas velocidade não significa necessariamente menor custo. Uma aplicação desenvolvida para servidores físicos dedicados pode consumir recursos ociosos quando executada na nuvem e gerar uma fatura maior do que a esperada. Por isso, entender os custos do projeto e da operação antes da migração é fundamental para avaliar se o lift and shift realmente faz sentido.
Ao longo deste conteúdo, você vai entender o que é lift and shift, como essa estratégia funciona na prática, quais fatores influenciam seus custos e em quais cenários ela é mais adequada entre as diferentes estratégias de migração para a nuvem:
O que é lift and shift?
Lift and shift é a estratégia de migração para a nuvem que transfere uma aplicação do ambiente atual para a nuvem sem alterar seu código ou sua arquitetura. Servidores, sistema operacional, banco de dados e demais dependências são reproduzidos no novo ambiente, preservando o funcionamento da aplicação. Por exigir poucas mudanças, é uma das estratégias de migração com menor risco de alteração funcional e menor tempo de execução.
Na classificação de estratégias de migração adotada pelo mercado, o lift and shift corresponde ao rehost. Na prática, a estratégia pode ser aplicada a diferentes componentes do ambiente, como:
- Servidores: máquinas virtuais são transferidas para uma infraestrutura de nuvem equivalente.
- Bancos de dados: a base existente é migrada preservando sua estrutura e configuração, quando houver compatibilidade.
- Aplicações legadas: sistemas antigos podem ser levados para a nuvem sem exigir uma reescrita imediata.
- Dependências: componentes necessários ao funcionamento da aplicação são mantidos no novo ambiente para reduzir mudanças durante a transição.
O rehost não elimina a necessidade de modernização; ele pode ser a primeira etapa de um processo mais amplo. Depois da migração, a empresa pode avaliar mudanças de arquitetura, código ou infraestrutura com mais tempo e menor pressão operacional. Essa separação entre migrar primeiro e modernizar depois é especialmente relevante em projetos de grande porte.
Como funciona o lift and shift?
O lift and shift funciona em quatro movimentos: inventário do ambiente atual, replicação das máquinas para a nuvem, validação funcional e virada de tráfego. Ferramentas de replicação copiam discos e configurações enquanto o ambiente antigo continua em produção, reduzindo a janela de indisponibilidade no momento da troca:
- Inventário do ambiente: mapeie servidores, aplicações, dados, configurações e dependências antes de iniciar a migração.
- Replicação das máquinas: copie os ambientes para a nuvem, mantendo a infraestrutura atual em funcionamento durante a preparação.
- Validação funcional: teste aplicações, integrações, acessos e rotinas no novo ambiente antes da virada.
- Virada de tráfego: direcione os usuários para o ambiente em nuvem e monitore o funcionamento após a mudança.
A etapa de inventário merece atenção especial, porque uma aplicação aparentemente isolada pode depender de autenticação, compartilhamentos de arquivos, bancos de dados ou mesmo rotinas executadas em outros servidores. Por isso, identificar essas relações antes da migração reduz o risco de falhas após a virada e evita que dependências esquecidas ampliem o prazo do projeto.
Lift and shift é a mesma coisa que rehost?
Sim. Lift and shift e rehost são nomes diferentes para a mesma estratégia de migração para a nuvem. Rehost é o termo técnico usado em modelos formais de migração, enquanto lift and shift é a expressão mais comum no mercado. Em ambos os casos, a aplicação é transferida para a nuvem sem alterações significativas no código ou na arquitetura. A diferença fica mais clara quando comparamos as estratégias:
- Rehost (lift and shift): move a aplicação para a nuvem com o mínimo de alterações;
- Replatform: introduz otimizações durante a migração, como usar um banco de dados gerenciado ou atualizar componentes da infraestrutura;
- Relocate: transfere cargas entre ambientes de nuvem sem modificar a aplicação, como na mudança entre plataformas de virtualização.
Por isso, levar uma aplicação para a nuvem e fazer pequenas mudanças na infraestrutura pode deixar de ser um rehost e passar a ser um replatform. Já o relocate se diferencia por ocorrer entre ambientes que já estão na nuvem, enquanto o lift and shift é normalmente associado à migração de ambientes locais para a nuvem.
Para entender como essas estratégias se relacionam e quando cada uma é indicada, consulte o guia de migração para AWS.
Quanto custa um projeto de lift and shift?
O custo de um projeto de lift and shift se divide em duas frentes: o investimento necessário para realizar a migração e o custo recorrente de operação no novo ambiente. A primeira etapa é finita e pode ser estimada a partir do escopo, enquanto a segunda depende do dimensionamento dos recursos, do modelo de contratação e do perfil de uso da infraestrutura.
Avaliar as duas perspectivas permite comparar o lift and shift com outras estratégias de migração de forma mais consistente, mas existem fatores a se mapear que podem ajudar a dimensionar valores, como explicamos a seguir.
Quais fatores podem aumentar o custo do projeto?
Os principais fatores que influenciam o custo de um projeto de lift and shift são o volume de servidores, a complexidade das dependências entre sistemas e o nível de disponibilidade exigido durante a virada. Um ambiente com muitas máquinas simples e bem documentadas tende a exigir menos esforço por servidor, enquanto sistemas fortemente acoplados demandam mais etapas de investigação, testes e planejamento:
- Inventário e mapeamento de dependências: o esforço necessário para identificar servidores, aplicações, integrações e fluxos de dados.
- Licenciamento de software: sistemas operacionais e bancos de dados comerciais podem ter regras e modelos de contratação específicos para ambientes em nuvem.
- Testes de validação: ambientes críticos ou regulados podem exigir testes mais abrangentes e evidências formais de funcionamento.
- Janela de virada e plano de retorno: operações com baixa tolerância à indisponibilidade exigem ensaios, planejamento detalhado e um caminho de reversão validado.
- Transferência de dados: grandes volumes podem aumentar o prazo da migração e exigir estratégias de sincronização incremental.
O que muda no custo depois da migração?
Depois da virada, o custo passa a ser principalmente recorrente e depende do dimensionamento dos recursos provisionados, do modelo de contratação e do padrão de uso da aplicação. Como o lift and shift preserva a configuração existente, alguns ambientes podem chegar à nuvem com capacidade superior à demanda real. Nesse cenário, a otimização pós-migração ajuda a alinhar os recursos utilizados ao consumo efetivo. Essa etapa pode incluir diferentes ações de otimização:
- Rightsizing: ajustar o tamanho das instâncias de acordo com a utilização real.
- Recursos ociosos: identificar e desligar ambientes que não precisam permanecer ativos continuamente.
- Compromissos de uso: avaliar Savings Plans ou Reserved Instances para cargas com consumo previsível.
- Monitoramento contínuo: acompanhar consumo, desempenho e custos para identificar novas oportunidades de ajuste.
Por isso, a gestão de custos deve fazer parte do planejamento da operação desde o início, e não ser tratada apenas depois da migração. Ferramentas de gerenciamento de custos podem apoiar a identificação de recursos subutilizados e recomendar ajustes com base em dados de utilização. O tema é aprofundado no conteúdo sobre FinOps.
Quais as vantagens do lift and shift?
As principais vantagens do lift and shift são a velocidade, a previsibilidade e o baixo impacto sobre o funcionamento da aplicação. Como o código e a arquitetura são preservados, a estratégia reduz o risco de alterações funcionais e permite executar a migração em prazos menores do que abordagens que exigem mudanças mais profundas. Na prática, os principais ganhos são:
- Migração mais rápida: a aplicação é transferida sem exigir uma reescrita ou mudanças estruturais antes da virada.
- Menor risco funcional: preservar o código e a arquitetura reduz a possibilidade de introduzir novos comportamentos ou falhas durante a migração.
- Maior previsibilidade: o escopo tende a ser mais controlado, facilitando a estimativa de esforço, prazo e recursos.
- Escalabilidade da migração: a abordagem pode ser aplicada a grandes parques de servidores, inclusive em projetos com centenas de máquinas.
- Menor dependência de hardware próprio: a empresa deixa de concentrar sua infraestrutura em ciclos de compra, renovação e manutenção de equipamentos.
- Recursos de infraestrutura sob demanda: a nuvem permite provisionar ambientes de teste, recuperação e réplica conforme a necessidade, sem exigir a mesma estrutura física dedicada.
Esses benefícios tornam o lift and shift uma alternativa para empresas que precisam acelerar a saída do data center ou reduzir mudanças durante a migração, deixando otimizações e modernizações mais profundas para uma etapa posterior.
Quando fazer lift and shift?
Quando o lift and shift é indicado?
O lift and shift é mais indicado quando a prioridade é migrar para a nuvem rapidamente, com baixo impacto sobre a aplicação e sem necessidade de mudanças arquiteturais imediatas. A estratégia faz sentido principalmente quando existe uma pressão concreta para deixar o ambiente atual, mas não há tempo ou necessidade de modernizar o sistema antes da migração.
Os cenários mais comuns incluem:
- Saída de data center: contratos de colocation próximos do vencimento ou decisão de desativar a infraestrutura própria.
- Hardware em fim de vida: servidores antigos que precisam ser substituídos sem esperar uma modernização completa da aplicação.
- Necessidade de continuidade: ambientes que precisam reduzir a janela de indisponibilidade durante a mudança.
- Consolidação após fusões e aquisições: migração de diferentes ambientes para uma infraestrutura de nuvem comum.
- Migração em grande escala: parques com muitos servidores em que mudanças individuais aumentariam significativamente o prazo e a complexidade do projeto.
Nesses casos, o lift and shift permite separar a urgência da migração da modernização da aplicação: primeiro, a empresa transfere as cargas para um ambiente mais adequado; depois, pode avaliar otimizações de infraestrutura, arquitetura ou código de forma planejada.
Quando o lift and shift não é a melhor escolha?
O lift and shift tende a ser menos adequado quando a aplicação já apresenta limitações de escala, alto custo de manutenção ou dependência de tecnologias sem suporte. Nesses casos, a migração sem mudanças estruturais pode transferir as limitações existentes para a nuvem, sem aproveitar os benefícios que uma modernização poderia trazer.
Alguns sinais indicam que outra estratégia pode ser mais adequada:
- Limite de escala: a arquitetura atual não acompanha o crescimento esperado da aplicação.
- Custo elevado de manutenção: a infraestrutura ou os componentes existentes exigem esforço recorrente para permanecerem operacionais.
- Tecnologia sem suporte: versões antigas de sistemas operacionais, runtimes ou bancos de dados dificultam a sustentação do ambiente.
- Necessidade de ganhos arquiteturais: a empresa precisa melhorar escalabilidade, disponibilidade ou eficiência como parte da própria migração.
Nesses cenários, vale avaliar estratégias que permitam mudanças durante a migração, como o replatforming, ou abordagens mais profundas, como refatoração e recodificação.
Aplicações monolíticas e fortemente acopladas também exigem uma análise específica, porque suas dependências podem aumentar a complexidade da migração e reduzir os benefícios de uma transferência sem alterações. O guia de migração de monólito para cloud apresenta as principais alternativas para esse cenário.
Migração para nuvem com a UDS
Executar um lift and shift com previsibilidade demanda um inventário rigoroso, plano de virada testado e disciplina de otimização de custo depois da migração. A UDS Tecnologia, com 23 anos de mercado, é AWS Advanced Consulting Partner e mantém certificações ISO 27001 e PCI DSS, credenciais que sustentam projetos de migração em operações com exigência formal de disponibilidade e conformidade.
Esse trabalho aparece em entregas com resultado medido. No case da Verocard, a plataforma de benefícios construída com arquitetura serverless em microsserviços e migrada para a AWS registrou 35% de economia em infraestrutura de nuvem e 100% de disponibilidade. Empresas que estão planejando essa jornada podem conhecer os serviços de consultoria cloud e a atuação completa da UDS no site oficial.
Perguntas frequentes sobre lift and shift
O que é lift and shift na computação em nuvem?
É a estratégia de mover uma aplicação para a nuvem sem alterar código nem arquitetura, replicando o ambiente atual no novo provedor. Corresponde ao rehost nos modelos formais de migração e é a abordagem com menor risco funcional e menor prazo de execução.
Lift and shift é mais barato que refatorar?
É mais barato no projeto, porque envolve menos horas de engenharia e prazo menor, mas pode ser mais caro na operação mensal se o dimensionamento não for ajustado. A comparação correta considera o custo total ao longo de dois ou três anos, e não apenas o investimento inicial.
Quanto tempo leva uma migração lift and shift?
O prazo varia conforme o número de servidores, o volume de dados e a complexidade das dependências entre sistemas. Ambientes bem documentados e com cargas independentes avançam bem mais rápido do que parques legados sem inventário atualizado.
Preciso parar a operação durante a migração?
Ferramentas de replicação contínua permitem manter o ambiente antigo em produção enquanto os dados são sincronizados, reduzindo a parada ao momento da virada. Operações críticas costumam ensaiar essa virada em ambiente de teste antes de executá-la em produção.
O que acontece com o licenciamento de software na migração?
Sistemas operacionais e bancos de dados comerciais podem ter regras específicas de licenciamento em ambiente de nuvem. Esse ponto precisa ser verificado no inventário, porque afeta tanto a viabilidade quanto o custo mensal depois da migração.
Lift and shift funciona para sistemas legados?
Funciona e é frequentemente usado para tirar sistemas antigos de data centers em desativação sem exigir reescrita imediata. O cuidado necessário é planejar a modernização posterior, para que a aplicação não permaneça indefinidamente com a mesma limitação em outro ambiente.
Dá para fazer lift and shift e modernizar depois?
Essa é justamente a sequência recomendada em migrações de grande porte, com o movimento rápido primeiro e a modernização por ondas depois. Manter o roadmap de modernização registrado evita que a etapa seguinte seja indefinidamente adiada após a estabilização.
Como estimar o custo mensal após a migração?
A estimativa parte do inventário de máquinas, com o consumo real de processamento, memória e armazenamento observado no ambiente atual. Dimensionar pela utilização média, e não pela capacidade instalada, evita reproduzir na nuvem a folga comprada para o hardware físico.
Quais aplicações não devem passar por lift and shift?
Aplicações com limite de escala já conhecido, dependência de tecnologia sem suporte ou custo de manutenção elevado tendem a render mais com ajuste durante a migração. Nesses casos, mover sem alterar preserva a limitação e adiciona custo recorrente.
Qual a diferença entre lift and shift e relocate?
Lift and shift descreve principalmente a saída de um ambiente local para a nuvem, enquanto relocate trata da transferência de servidores entre ambientes já em nuvem. As duas mantêm a aplicação inalterada, mudando apenas o ponto de partida do movimento.
É possível reverter uma migração lift and shift?
É possível quando o plano de retorno é definido antes da virada e o ambiente de origem permanece disponível por um período combinado. Projetos que desligam a infraestrutura antiga imediatamente após a troca perdem essa alternativa e assumem risco desnecessário.
