O Que É Fluxo Migratorio

Fluxo migratório: o que realmente é e como você não vai errar na prática

Fluxo migratório é basicamente o processo de mover dados de uma fonte legado para um destino novo, com a menor interrupção possível. Parece simples até você tentar fazer isso com 50 milhões de registros e um SLA de 4 horas. A definição técnica é straightforward: é a sequência ordenada de extração, transformação e carregamento (ou simplesmente extração e carregamento, se não houver transformações significativas) que leva dados de um sistema A para um sistema B. O termo "fluxo" vem do fato de que isso não acontece de uma vez — é contínuo, com checkpoints, retry logic e monitoramento. O problema é que todo mundo subestima a parte de "com a menor interrupção possível". Vou explicar por quê.

Eu estava migrando um banco Oracle 10g para Postgres 14 recentemente. Sistema financeiro, então transações atômicas eram obrigatórias. A documentação dizia "use migração em batch". O que eles não mencionavam era que os índices no Oracle estavam tão desbalanceados que cada batch de 100 mil linhas levava 23 minutos para ser transformado, porque o optimizer estava fazendo nested loop joins em tabelas com mais de 4 milhões de linhas sem estatísticas atualizadas. A solução que funcionou foi desativar temporariamente os triggers no target durante o carregamento e reconstruir os índices só no final. Isso cortou o tempo de 18 horas para 3 horas e 40 minutos. Ponto importante: você precisa entender o schema original antes de planejar qualquer coisa. Eu vi gente tentar migrar tabelas diretamente sem verificar constraints primeiro. Terminou com dados órfãos e horas de debugging.

Os componentes que você realmente precisa controlar

Extração: você precisa decidir entre full dump ou incremental. Full dump é mais simples, mas se o volume for grande demais, você vai gastar uma fortuna em I/O e memória. Incremental exige que a fonte tenha timestamps de update confiáveis ou CDC (change data capture) habilitado. Se não tiver nenhum dos dois, você tá ferrado — vai ter que fazer full mesmo. Transformação: aqui é onde a maioria dos projetos desbanca. Type casting entre engines diferentes é um pesadelo. Float do SQL Server vira double no BigQuery e perde precisão. Timestamp com timezone vs timestamp sem timezone gera inconsistências que só aparecem em produção. A regra que eu uso: nunca confie no cast automático. Force explicitamente, sempre. Carregamento: batch pequeno demais e você tem overhead de conexão. Batch grande demais e estoura a memória do target ou trava a lock table. O sweet spot depende totalmente do seu SGBD. Para Postgres,Batch de 50 mil a 100 mil linhas costuma funcionar bem. Para Redshift, aí sim você quer 500 mil ou mais.

Arquiteturas comuns e quando usar cada uma

Migração big bang: você migra tudo de uma vez, em uma janela de manutenção. Funciona para sistemas pequenos, com menos de 10 milhões de registros. É rápido, simples de validar, mas se der errado, você volta para o zero. Risco alto. Migração paralela: você mantém ambos os sistemas rodando, migra os dados e redireciona o tráfego gradualmente. Isso é o padrão ouro para sistemas críticos. Exige mais infraestrutura, mas o rollback é trivial — basta desligar o target e voltar o DNS para a source. Migração strangle: você vai mudando módulos ou tabelas uma por uma, isoladamente. Boa para sistemas muito grandes ou legados sem documentação. O problema é que table A pode depender de table B, e se você migrar B antes de A sem sincronizar, vai ter integridade quebrada no meio do caminho.

Eu recomendo paralela para quase tudo que não seja experimental. Strangle é útil mas exige um mapeamento de dependências extremamente preciso. Big bang é gambiarra bonita até dar erro.

Pitfalls que ninguém conta nos tutoriais

O primeiro: checksum. Sempre calcule um hash MD5 ou SHA-256 das linhas antes de migrar e compare depois. Sem isso, você não sabe se os dados chegaram corretos. Eu já vi projeto inteiro entregar sem validação e descobrir três semanas depois que 12% dos registros tinham sido truncados durante o transfer. O segundo: collation. Migração de MySQL para PostgreSQL com collation latin1 para UTF-8 pode corromper acentos e caracteres especiais. Configure o target com a mesma encoding desde o início. Não tente corrigir depois. O terceiro: foreign keys e constraints. Desative-as durante o carregamento e valide no final. Carregar com constraints ativas significa que cada insert vai verificar referências, o que transforma um processo de minutos em algo que leva dias. Eu perdi uma migração inteira porque esqueci de desativar FKs no target. Três dias parados esperando foreign key checks em tabela de 8 milhões de linhas.

Ferramentas que fazem sentido

Se o cenário é simples, Airbyte ou Meltano resolvem. São open source, têm connectors prontos, e a configuração inicial leva menos de uma hora. Para volumes maiores ou customizações complexas, você vai precisar de algo mais low-level. Um script Python com SQLAlchemy e Pandas dá controle total. Ou Cloud Dataflow / AWS Glue se estiver na nuvem. O que eu não recomendo: soluções prontas de vendor que prometem migração automática. Eles funcionam até você encontrar aquele edge case que o pipeline deles não trata. Aí você gasta mais tempo workaround do que construindo do zero.

Quando fluxo migratório simplesmente não funciona

Se a fonte não tem logs de transação, não tem CDC, não tem timestamps confiáveis e os dados são menores de 50 GB, ainda é viável fazer full batch. Acima disso sem ferramentas adequadas, o projeto vai atrasar. Se a fonte é um ERP legado sem API e o fornecedor não oferece exporte estruturado, você vai ter que fazer screen scraping ou parsing de arquivo texto — o que é extremamente frágil. Nesses casos, a alternativa mais realista é uma ponte: coloque um middleware entre a fonte e o destino, use um banco intermediário como staging, e faça a migração em camadas. Não é bonito, mas funciona quando o caminho direto é impossível.