<\/p>\n
O lift and shift<\/strong> continua sendo uma das estrat\u00e9gias mais utilizadas por empresas que precisam migrar cargas do data center pr\u00f3prio para a nuvem sem interromper a opera\u00e7\u00e3o. Segundo a proje\u00e7\u00e3o de gastos globais de TI publicada pela Gartner em abril de 2026<\/a>, o investimento mundial em tecnologia deve chegar a US$6,31 trilh\u00f5es em 2026, crescimento de 13,5% no ano. Os sistemas de data center avan\u00e7am 55,8%, refor\u00e7ando o movimento de renova\u00e7\u00e3o da infraestrutura.<\/p>\n A press\u00e3o por prazo<\/strong> costuma pesar nessa decis\u00e3o: contratos pr\u00f3ximos do vencimento, hardware no fim da vida \u00fatil e exig\u00eancias de continuidade podem exigir a migra\u00e7\u00e3o em meses, e n\u00e3o em anos. Nesse cen\u00e1rio, reescrever aplica\u00e7\u00f5es antes da mudan\u00e7a pode n\u00e3o ser vi\u00e1vel, e mover o ambiente existente com o m\u00ednimo de altera\u00e7\u00f5es se torna uma alternativa para acelerar a opera\u00e7\u00e3o em nuvem.<\/p>\n Mas velocidade n\u00e3o significa necessariamente menor custo. Uma aplica\u00e7\u00e3o desenvolvida para servidores f\u00edsicos 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\u00e7\u00e3o antes da migra\u00e7\u00e3o \u00e9 fundamental para avaliar se o lift and shift<\/strong> realmente faz sentido.<\/p>\n Ao longo deste conte\u00fado, voc\u00ea vai entender o que \u00e9 lift and shift, como essa estrat\u00e9gia funciona na pr\u00e1tica, quais fatores influenciam seus custos e em quais cen\u00e1rios ela \u00e9 mais adequada<\/strong> entre as diferentes estrat\u00e9gias de migra\u00e7\u00e3o para a nuvem:<\/p>\n Lift and shift \u00e9 a estrat\u00e9gia de migra\u00e7\u00e3o para a nuvem que transfere uma aplica\u00e7\u00e3o do ambiente atual para a nuvem sem alterar seu c\u00f3digo ou sua arquitetura.<\/strong> Servidores, sistema operacional, banco de dados e demais depend\u00eancias s\u00e3o reproduzidos no novo ambiente, preservando o funcionamento da aplica\u00e7\u00e3o. Por exigir poucas mudan\u00e7as, \u00e9 uma das estrat\u00e9gias de migra\u00e7\u00e3o com menor risco de altera\u00e7\u00e3o funcional e menor tempo de execu\u00e7\u00e3o.<\/p>\n Na classifica\u00e7\u00e3o de estrat\u00e9gias de migra\u00e7\u00e3o adotada pelo mercado, o lift and shift corresponde ao rehost<\/strong>.\u00a0Na pr\u00e1tica, a estrat\u00e9gia pode ser aplicada a diferentes componentes do ambiente, como:<\/p>\n O rehost n\u00e3o elimina a necessidade de moderniza\u00e7\u00e3o; ele pode ser a primeira etapa de um processo mais amplo<\/strong>. Depois da migra\u00e7\u00e3o, a empresa pode avaliar mudan\u00e7as de arquitetura, c\u00f3digo ou infraestrutura com mais tempo e menor press\u00e3o operacional. Essa separa\u00e7\u00e3o entre migrar primeiro e modernizar depois \u00e9 especialmente relevante em projetos de grande porte.<\/p>\n O lift and shift funciona em quatro movimentos: invent\u00e1rio do ambiente atual, replica\u00e7\u00e3o das m\u00e1quinas para a nuvem, valida\u00e7\u00e3o funcional e virada de tr\u00e1fego.<\/strong> Ferramentas de replica\u00e7\u00e3o copiam discos e configura\u00e7\u00f5es enquanto o ambiente antigo continua em produ\u00e7\u00e3o, reduzindo a janela de indisponibilidade no momento da troca:<\/p>\n A etapa de invent\u00e1rio merece aten\u00e7\u00e3o especial<\/strong>, porque uma aplica\u00e7\u00e3o aparentemente isolada pode depender de autentica\u00e7\u00e3o, compartilhamentos de arquivos, bancos de dados ou mesmo rotinas executadas em outros servidores. Por isso, identificar essas rela\u00e7\u00f5es antes da migra\u00e7\u00e3o reduz o risco de falhas ap\u00f3s a virada e evita que depend\u00eancias esquecidas ampliem o prazo do projeto.<\/p>\n Sim. Lift and shift e rehost s\u00e3o nomes diferentes para a mesma estrat\u00e9gia de migra\u00e7\u00e3o para a nuvem.<\/strong> Rehost<\/em> \u00e9 o termo t\u00e9cnico usado em modelos formais de migra\u00e7\u00e3o, enquanto lift and shift<\/em> \u00e9 a express\u00e3o mais comum no mercado. Em ambos os casos, a aplica\u00e7\u00e3o \u00e9 transferida para a nuvem sem altera\u00e7\u00f5es significativas no c\u00f3digo ou na arquitetura. A diferen\u00e7a fica mais clara quando comparamos as estrat\u00e9gias:<\/p>\n Por isso, levar uma aplica\u00e7\u00e3o para a nuvem e fazer pequenas mudan\u00e7as na infraestrutura pode deixar de ser um rehost e passar a ser um replatform<\/strong>. J\u00e1 o relocate se diferencia por ocorrer entre ambientes que j\u00e1 est\u00e3o na nuvem, enquanto o lift and shift \u00e9 normalmente associado \u00e0 migra\u00e7\u00e3o de ambientes locais para a nuvem.<\/p>\n Para entender como essas estrat\u00e9gias se relacionam e quando cada uma \u00e9 indicada, consulte o guia de migra\u00e7\u00e3o para AWS<\/a>.<\/p>\n O custo de um projeto de lift and shift<\/strong> se divide em duas frentes: o investimento necess\u00e1rio para realizar a migra\u00e7\u00e3o e o custo recorrente de opera\u00e7\u00e3o no novo ambiente.<\/strong> A primeira etapa \u00e9 finita e pode ser estimada a partir do escopo, enquanto a segunda depende do dimensionamento dos recursos, do modelo de contrata\u00e7\u00e3o e do perfil de uso da infraestrutura.<\/p>\n Avaliar as duas perspectivas permite comparar o lift and shift com outras estrat\u00e9gias de migra\u00e7\u00e3o de forma mais consistente, mas existem fatores a se mapear que podem ajudar a dimensionar valores, como explicamos a seguir.<\/p>\n Os principais fatores que influenciam o custo de um projeto de lift and shift<\/strong> s\u00e3o o volume de servidores, a complexidade das depend\u00eancias entre sistemas <\/strong>e o n\u00edvel de disponibilidade exigido durante a virada.<\/strong> Um ambiente com muitas m\u00e1quinas simples e bem documentadas tende a exigir menos esfor\u00e7o por servidor, enquanto sistemas fortemente acoplados demandam mais etapas de investiga\u00e7\u00e3o, testes e planejamento:<\/p>\n Depois da virada, o custo<\/strong> passa a ser principalmente recorrente<\/strong> e depende do dimensionamento dos recursos provisionados<\/strong>, do modelo de contrata\u00e7\u00e3o e do padr\u00e3o de uso da aplica\u00e7\u00e3o. Como o lift and shift preserva a configura\u00e7\u00e3o existente, alguns ambientes podem chegar \u00e0 nuvem com capacidade superior \u00e0 demanda real. Nesse cen\u00e1rio, a otimiza\u00e7\u00e3o p\u00f3s-migra\u00e7\u00e3o ajuda a alinhar os recursos utilizados ao consumo efetivo. Essa etapa pode incluir diferentes a\u00e7\u00f5es de otimiza\u00e7\u00e3o:<\/p>\n Por isso, a gest\u00e3o de custos deve fazer parte do planejamento da opera\u00e7\u00e3o desde o in\u00edcio, e n\u00e3o ser tratada apenas depois da migra\u00e7\u00e3o. Ferramentas de gerenciamento de custos podem apoiar a identifica\u00e7\u00e3o de recursos subutilizados e recomendar ajustes com base em dados de utiliza\u00e7\u00e3o. O tema \u00e9 aprofundado no conte\u00fado sobre FinOps.<\/a><\/p>\n As principais vantagens do lift and shift s\u00e3o a velocidade, a previsibilidade e o baixo impacto sobre o funcionamento da aplica\u00e7\u00e3o.<\/strong> Como o c\u00f3digo e a arquitetura s\u00e3o preservados, a estrat\u00e9gia reduz o risco de altera\u00e7\u00f5es funcionais e permite executar a migra\u00e7\u00e3o em prazos menores do que abordagens que exigem mudan\u00e7as mais profundas. Na pr\u00e1tica, os principais ganhos s\u00e3o:<\/p>\n Esses benef\u00edcios tornam o lift and shift uma alternativa para empresas que precisam acelerar a sa\u00edda do data center ou reduzir mudan\u00e7as durante a migra\u00e7\u00e3o<\/strong>, deixando otimiza\u00e7\u00f5es e moderniza\u00e7\u00f5es mais profundas para uma etapa posterior.<\/p>\n O lift and shift \u00e9 mais indicado quando a prioridade \u00e9 migrar para a nuvem rapidamente, com baixo impacto sobre a aplica\u00e7\u00e3o e sem necessidade de mudan\u00e7as arquiteturais imediatas.<\/strong> A estrat\u00e9gia faz sentido principalmente quando existe uma press\u00e3o concreta para deixar o ambiente atual, mas n\u00e3o h\u00e1 tempo ou necessidade de modernizar o sistema antes da migra\u00e7\u00e3o.<\/p>\n Os cen\u00e1rios mais comuns incluem:<\/p>\n Nesses casos, o lift and shift permite separar a urg\u00eancia da migra\u00e7\u00e3o da moderniza\u00e7\u00e3o da aplica\u00e7\u00e3o<\/strong>: primeiro, a empresa transfere as cargas para um ambiente mais adequado; depois, pode avaliar otimiza\u00e7\u00f5es de infraestrutura, arquitetura ou c\u00f3digo de forma planejada.<\/p>\n O lift and shift tende a ser menos adequado quando a aplica\u00e7\u00e3o j\u00e1 apresenta limita\u00e7\u00f5es de escala, alto custo de manuten\u00e7\u00e3o ou depend\u00eancia de tecnologias sem suporte.<\/strong> Nesses casos, a migra\u00e7\u00e3o sem mudan\u00e7as estruturais pode transferir as limita\u00e7\u00f5es existentes para a nuvem, sem aproveitar os benef\u00edcios que uma moderniza\u00e7\u00e3o poderia trazer.<\/p>\n Alguns sinais indicam que outra estrat\u00e9gia pode ser mais adequada:<\/p>\n Nesses cen\u00e1rios, vale avaliar estrat\u00e9gias que permitam mudan\u00e7as durante a migra\u00e7\u00e3o, como o replatforming<\/a>, ou abordagens mais profundas, como refatora\u00e7\u00e3o<\/a> e recodifica\u00e7\u00e3o<\/a>.<\/p>\n Aplica\u00e7\u00f5es monol\u00edticas e fortemente acopladas tamb\u00e9m exigem uma an\u00e1lise espec\u00edfica<\/strong>, porque suas depend\u00eancias podem aumentar a complexidade da migra\u00e7\u00e3o e reduzir os benef\u00edcios de uma transfer\u00eancia sem altera\u00e7\u00f5es. O guia de migra\u00e7\u00e3o de mon\u00f3lito para cloud<\/a> apresenta as principais alternativas para esse cen\u00e1rio.<\/p>\n Executar um lift and shift com previsibilidade demanda um invent\u00e1rio rigoroso, plano de virada testado e disciplina de otimiza\u00e7\u00e3o de custo depois da migra\u00e7\u00e3o. A UDS Tecnologia, com 23 anos de mercado, \u00e9 AWS Advanced Consulting Partner e mant\u00e9m certifica\u00e7\u00f5es ISO 27001 e PCI DSS, credenciais que sustentam projetos de migra\u00e7\u00e3o em opera\u00e7\u00f5es com exig\u00eancia formal de disponibilidade e conformidade.<\/p>\n Esse trabalho aparece em entregas com resultado medido. No case da Verocard<\/a>, a plataforma de benef\u00edcios constru\u00edda com arquitetura serverless em microsservi\u00e7os e migrada para a AWS registrou 35% de economia em infraestrutura de nuvem e 100% de disponibilidade. Empresas que est\u00e3o planejando essa jornada podem conhecer os servi\u00e7os de consultoria cloud<\/a> e a atua\u00e7\u00e3o completa da UDS no site oficial<\/a>.<\/p>\n \u00c9 a estrat\u00e9gia de mover uma aplica\u00e7\u00e3o para a nuvem sem alterar c\u00f3digo nem arquitetura, replicando o ambiente atual no novo provedor. Corresponde ao rehost nos modelos formais de migra\u00e7\u00e3o e \u00e9 a abordagem com menor risco funcional e menor prazo de execu\u00e7\u00e3o.<\/p>\n \u00c9 mais barato no projeto, porque envolve menos horas de engenharia e prazo menor, mas pode ser mais caro na opera\u00e7\u00e3o mensal se o dimensionamento n\u00e3o for ajustado. A compara\u00e7\u00e3o correta considera o custo total ao longo de dois ou tr\u00eas anos, e n\u00e3o apenas o investimento inicial.<\/p>\n O prazo varia conforme o n\u00famero de servidores, o volume de dados e a complexidade das depend\u00eancias entre sistemas. Ambientes bem documentados e com cargas independentes avan\u00e7am bem mais r\u00e1pido do que parques legados sem invent\u00e1rio atualizado.<\/p>\n Ferramentas de replica\u00e7\u00e3o cont\u00ednua permitem manter o ambiente antigo em produ\u00e7\u00e3o enquanto os dados s\u00e3o sincronizados, reduzindo a parada ao momento da virada. Opera\u00e7\u00f5es cr\u00edticas costumam ensaiar essa virada em ambiente de teste antes de execut\u00e1-la em produ\u00e7\u00e3o.<\/p>\n Sistemas operacionais e bancos de dados comerciais podem ter regras espec\u00edficas de licenciamento em ambiente de nuvem. Esse ponto precisa ser verificado no invent\u00e1rio, porque afeta tanto a viabilidade quanto o custo mensal depois da migra\u00e7\u00e3o.<\/p>\n Funciona e \u00e9 frequentemente usado para tirar sistemas antigos de data centers em desativa\u00e7\u00e3o sem exigir reescrita imediata. O cuidado necess\u00e1rio \u00e9 planejar a moderniza\u00e7\u00e3o posterior, para que a aplica\u00e7\u00e3o n\u00e3o permane\u00e7a indefinidamente com a mesma limita\u00e7\u00e3o em outro ambiente.<\/p>\n Essa \u00e9 justamente a sequ\u00eancia recomendada em migra\u00e7\u00f5es de grande porte, com o movimento r\u00e1pido primeiro e a moderniza\u00e7\u00e3o por ondas depois. Manter o roadmap de moderniza\u00e7\u00e3o registrado evita que a etapa seguinte seja indefinidamente adiada ap\u00f3s a estabiliza\u00e7\u00e3o.<\/p>\n A estimativa parte do invent\u00e1rio de m\u00e1quinas, com o consumo real de processamento, mem\u00f3ria e armazenamento observado no ambiente atual. Dimensionar pela utiliza\u00e7\u00e3o m\u00e9dia, e n\u00e3o pela capacidade instalada, evita reproduzir na nuvem a folga comprada para o hardware f\u00edsico.<\/p>\n Aplica\u00e7\u00f5es com limite de escala j\u00e1 conhecido, depend\u00eancia de tecnologia sem suporte ou custo de manuten\u00e7\u00e3o elevado tendem a render mais com ajuste durante a migra\u00e7\u00e3o. Nesses casos, mover sem alterar preserva a limita\u00e7\u00e3o e adiciona custo recorrente.<\/p>\n Lift and shift descreve principalmente a sa\u00edda de um ambiente local para a nuvem, enquanto relocate trata da transfer\u00eancia de servidores entre ambientes j\u00e1 em nuvem. As duas mant\u00eam a aplica\u00e7\u00e3o inalterada, mudando apenas o ponto de partida do movimento.<\/p>\n \u00c9 poss\u00edvel quando o plano de retorno \u00e9 definido antes da virada e o ambiente de origem permanece dispon\u00edvel por um per\u00edodo combinado. Projetos que desligam a infraestrutura antiga imediatamente ap\u00f3s a troca perdem essa alternativa e assumem risco desnecess\u00e1rio.<\/p>\nO que \u00e9 lift and shift?<\/h2>\n
\n
Como funciona o lift and shift?<\/h3>\n
\n
Lift and shift \u00e9 a mesma coisa que rehost?<\/h2>\n
\n
Quanto custa um projeto de lift and shift?<\/h2>\n
Quais fatores podem aumentar o custo do projeto?<\/h3>\n
\n
O que muda no custo depois da migra\u00e7\u00e3o?<\/h3>\n
\n
Quais as vantagens do lift and shift?<\/h2>\n
\n
Quando fazer lift and shift?<\/span><\/h2>\n
Quando o lift and shift \u00e9 indicado?<\/h3>\n
\n
<\/h3>\n
Quando o lift and shift n\u00e3o \u00e9 a melhor escolha?<\/h3>\n
\n
Migra\u00e7\u00e3o para nuvem com a UDS<\/h2>\n
Perguntas frequentes sobre lift and shift<\/h2>\n
O que \u00e9 lift and shift na computa\u00e7\u00e3o em nuvem?<\/h3>\n
Lift and shift \u00e9 mais barato que refatorar?<\/h3>\n
Quanto tempo leva uma migra\u00e7\u00e3o lift and shift?<\/h3>\n
Preciso parar a opera\u00e7\u00e3o durante a migra\u00e7\u00e3o?<\/h3>\n
O que acontece com o licenciamento de software na migra\u00e7\u00e3o?<\/h3>\n
Lift and shift funciona para sistemas legados?<\/h3>\n
D\u00e1 para fazer lift and shift e modernizar depois?<\/h3>\n
Como estimar o custo mensal ap\u00f3s a migra\u00e7\u00e3o?<\/h3>\n
Quais aplica\u00e7\u00f5es n\u00e3o devem passar por lift and shift?<\/h3>\n
Qual a diferen\u00e7a entre lift and shift e relocate?<\/h3>\n
\u00c9 poss\u00edvel reverter uma migra\u00e7\u00e3o lift and shift?<\/h3>\n