O que acontece quando você precisa migrar à força
Migração forçada é, basicamente, quando você não tem opção de fazer as coisas do jeitinho tradicional. Você pega um sistema legado, um banco de dados obsoleto ou uma infraestrutura inteira e precisa movê-la para outro ambiente, mas as condições não são ideais. O servidor fonte tá morrendo. O vendor não dá mais suporte. A licença expirou semana passada e o contrato de maintenance tá no fim. O termo aparece com frequência em contextos de migração de bancos de dados, migração para nuvem, e migração de aplicações monolíticas para microsserviços. O "forçada" vem da urgência ou da falta de alternativa, não de uma técnica específica.
O que é migração forçada na prática
Na prática, migração forçada envolve quatro componentes principais. Primeiro, o coletor de dados do ambiente antigo. Segundo, um transformador que converte o formato. Terceiro, o validador que checa se nada quebrou. Quarto, o roteador que direciona o tráfego pro novo ambiente. O problema é que raramente você tem os quatro prontos ao mesmo tempo. O que a maioria das pessoas não entende é que migração forçada nunca é só técnica. Sempre tem implicações operacionais enormes. Uma vez eu precisei migrar um sistema de faturamento que rodava em Oracle 9i num Red Hat Linux 2.6 que ninguém mais conseguia patchear. O cliente tinha 47 tabelas com procedures armazenadas escritas em PL/SQL puro, sem versionamento, sem documentação. O plano original era uma migração big bang num sábado. A realidade foi diferente.
A procedure principal de conciliação bancária tinha um loop aninhado de oito níveis que processava cerca de 2 milhões de registros por noite. Quando converti pra PostgreSQL 14, simplesmente não funcionou. O optimizer do Postgres não segue a mesma lógica de execução do Oracle, então o plano de query era completamente diferente. O que levava 12 minutos no Oracle levou 47 minutos no Postgres na primeira versão. E isso aconteceu porque eu não tinha rodado o comando EXPLAIN ANALYZE nas queries críticas antes de migrar. A solução foi refatorar a procedure em batches de 50 mil registros, com commit intermediário, e adicionar um índice.partial que o Oracle não usava mas o Postgres precisava. Cortei o tempo de 47 minutos pra 3 minutos e meio. Mas precisei de duas semanas extras e do desenvolvedor original que tava de férias na Tailândia.
Como executar uma migração forçada
Vamos começar pelo que realmente importa, não pela teoria. O passo zero é mapear todas as dependências. Não confie na documentação. A documentação é mentirosa. Vá direto pro código, pro schema, pro cron job, pro shell script, pro arquivo de configuração que todo mundo esquece que existe. No meu caso do Oracle pro Postgres, eu usei uma combinação de dbms_metadata.get_ddl pra extrair o DDL original, depois rodei um grep recursivo em todos os diretórios de aplicação procurando referências cruzadas. Encontrei quatro jobs Oracle Scheduler que não apareciam em nenhum documento. Um deles disparava uma rotina de limpeza noturna que ninguém sabia que existia.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O passo seguinte é escolher a estratégia de migração. Existem basicamente três abordagens. Big bang, onde você migra tudo de uma vez num janela planejada. Dupla escrita, onde o sistema novo grava junto com o antigo simultaneamente por um período. E migração em camadas, onde você move módulos isolados sequencialmente. Big bang é o que todo mundo quer fazer mas raramente funciona. Dupla escrita é segura mas complexa. Camadas exige que seu sistema seja modular de alguma forma. Se você tá migrando banco de dados, o ferramenta mais comum é o postgres_fdw pra conexão em fase dual, ou o AWS DMS pra migração contínua. Num projeto recente migrei um cluster MongoDB 3.6 pro Atlas. O problema era que tínhamos indices geoespaciais customizados que o driver antigo do PHP não suportava direito. O workaround foi manter um mongo shim rodando em Docker que traduzia as queries incompatíveis enquanto o sistema novo ia sendo estabilizado. Rodou em paralelo por seis semanas antes do switch definitivo.
Pegadinhas que ninguém conta
A primeira pegadinha é a diferença de timezone. Migrei um sistema de agendamento onde os timestamps eram armazenados como Unix epoch em UTC no servidor antigo, mas a aplicação fazia conversão manual pros timezone do cliente brasileiro. Quando movi pra cloud, um serviço de logging automático converteu tudo pra UTC novamente, e o relatório mensal ficou com datas erradas pra aproximadamente 38% dos registros. A correção foi criar uma view de compatibilidade no novo banco que reconvertia os valores pra UTC-3 nas consultas históricas. A segunda pegadinha é a memória. Servidores antigos rodam com workloads que nunca foram otimizados pra memória. Quando você sobe pra cloud com menos RAM, o comportamento muda drasticamente. Um query que no servidor antigo fazia full table scan porque não tinha memória pro buffer cache passou a usar índice no novo ambiente, mas o índice era estatisticamente ruim porque os dados tinham se dessincronizado durante a migração parcial. Resultado: consultas que antes levavam 8 segundos passaram a levar 45.
O workaround aqui é sempre manter uma janela de paralelo entre o ambiente antigo e o novo. Por menor que seja. Duas semanas deoverlap salvaram aquele projeto do Oracle. Sem essa janela, eu teria que refazer o deploy em produção em cima da hora, com o sistema já rodando e users reclamando. Também vale mencionar que migração forçada tem um custo de oportunidade que raramente entra no orçamento. Enquanto sua equipe gasta três semanas migrando, não tá desenvolvendo features novas. Num sistema legado, isso significa que o débito técnico acumula enquanto você tá ocupado mantendo o sistema vivo em outro lugar. É um ciclo vicioso. A alternativa mais sensata, quando possível, é a estratégia de strangler fig — ir substituindo módulos gradualmente até o sistema antigo morrer naturalmente, sem um grande salto de migração.
O problema é que nem todo sistema permite isso. Sistemas acoplados de forma apertada, APIs fechadas, vendor lock-in real. Aí a migração forçada é a única saída. E quando é a única saída, o plano de rollback tem que ser tão bem construído quanto o plano de migração. Eu já vi times que passaram duas semanas construindo a migração e zero minutos pensando no que aconteceria se fosse tudo pro inferno. Na prática, sempre acontece alguma coisa que dá errado.
Checklist rápido de migração forçada
Mapeie todas as dependências antes de escrever uma linha de código. Rode profiling no ambiente legado pra ter baseline de performance. Teste a migração pelo menos três vezes em ambiente idêntico ao production. Prepare um rollback automatizado, não manual. Mantenha overlap entre ambientes. Valide dados após cada etapa, não só no final. E acima de tudo: não subestime a diferença de comportamento entre ambientes diferentes, mesmo que a versão do software seja a mesma.
