Lift and shift (ou rehosting) é a migração de um sistema para cloud sem mudança de arquitetura ou código, o sistema é 'levantado' do ambiente atual e 'movido' para cloud exatamente como está. É a abordagem mais rápida e de menor risco para migração, adequada para sistemas estáveis que não se beneficiam de refatoração. A desvantagem é não aproveitar os benefícios nativos de cloud (elasticidade, serviços managed), o sistema funciona em cloud mas com arquitetura de on-premises.
Sistemas que precisam escalar horizontalmente, adicionar instâncias para absorver mais carga, geralmente requerem refatoração. Lift and shift de um monolito apenas move o gargalo para cloud, sem resolver o problema de escalabilidade.
Sistemas que dependem de hardware físico específico (dongles de licença, processadores específicos, portas COM/LPT) não funcionam em cloud sem adaptação. Esses sistemas exigem refatoração antes da migração.
Sistemas com tecnologias obsoletas (aplicações ASP, Java EE antigo, frameworks descontinuados) têm a migração como oportunidade de modernização. Lift and shift preserva a dívida técnica, às vezes é o trade-off correto, às vezes é perda de oportunidade.
Documente todos os componentes do sistema: serviços, portas, caminhos de arquivo, variáveis de ambiente, integrações externas. Esse inventário é o checklist de validação pós-migração.
No destino em cloud, provisione o mesmo SO, mesmas versões de runtime e aplicação, mesma configuração de rede e firewall. A paridade de ambiente é o que garante que o sistema funciona no destino como no origem.
Migre dados de produção para o ambiente de homologação e valide com usuários de negócio os fluxos críticos. Problemas descobertos em homologação são resolvidos em dias; problemas descobertos no cutover de produção são incidentes.
Defina antes do cutover: se em X horas a validação não fechar com sucesso, revertemos para o ambiente antigo. Esse critério de go/no-go previne que problemas descubertos no cutover se transformem em incidentes prolongados.
A Boreal Tecnologias é especializada em lift and shift para cloud privada no Brasil, ambiente de homologação incluso, suporte no cutover e diagnóstico gratuito do ambiente atual. A maioria dos projetos de ERP que conduzimos são lift and shift executados em 2 a 4 semanas.
Depende da causa da performance ruim. Se o problema é hardware (disco lento, RAM insuficiente), lift and shift para cloud com NVMe e RAM adequados resolve. Se o problema é arquitetura ou código (queries ineficientes, arquitetura monolítica), lift and shift não resolve, e em alguns casos pode piorar se o sizing não for calibrado corretamente.
Para ERP padrão (SAP B1, Protheus, Sankhya) sem integrações complexas: 2 a 3 semanas (1 semana de preparação + 1 semana de homologação + 1 janela de cutover). Com integrações externas complexas (NF-e, bancos, sistemas legados): 4 a 6 semanas.
Para ERPs e sistemas de negócio com carga estável e usuários no Brasil, cloud privada nacional é geralmente melhor no lift and shift, latência mais baixa, preço em reais e sem egress. Cloud pública é melhor para sistemas que precisam de presença global ou elasticidade extrema.
Tecnicamente sim, mas isso não é lift and shift, é refactoring de plataforma. Lift and shift mantém o mesmo SO. Para sistemas Windows Server, o destino em cloud também é Windows Server. Mudar de Windows para Linux exige validação extensiva de compatibilidade de aplicação.
Receba um diagnóstico estratégico gratuito e descubra o que está limitando performance, estabilidade e escala hoje.
Sem compromisso. Resposta em até 15 minutos em horário comercial.