Qual É O Significado De Migração

O que é migração no contexto tecnológico

Quando você ouve a palavra migração, pode pensar em pássaros voando ou pessoas se mudando de cidade. No mundo da TI, migração é basicamente o processo de transferir dados, sistemas ou aplicações de um ambiente para outro. Pode ser uma mudança de servidor local para nuvem, atualização de uma versão antiga de software, reposição de banco de dados, ou qualquer coisa que envolva tirar algo do lugar e colocar em outro lugar novo. Qual é o significado de migração? Em resumo, é o ato de mover sistemas, dados ou infraestrutura de um ambiente para outro com o mínimo de interrupção possível. Parece simples quando você lê isso em um documento, mas na prática é um dos processos mais frágeis da área.

Migração de banco de dados: o que realmente acontece

O cenário mais comum é a migração de bancos de dados. Você pega os dados de um PostgreSQL 10 rodando em um servidor AWS EC2 e precisa levá-los para um Amazon RDS na versão 14. A teoria diz que basta exportar o dump e importar no destino. A prática é bem mais complicada. Na minha experiência, já migrei um banco de cerca de 800 gigabytes de um ambiente on-premise para o Google Cloud SQL. O problema não era o volume em si, mas as constraints e foreign keys que não estavam documentadas. Durante a importação, cerca de 14 mil linhas eram rejeitadas a cada execução porque referenciavam IDs que haviam sido deletados em tabelas filhas anos antes. Ninguém sabia disso porque o sistema legado tinha sido mantido por três desenvolvedores diferentes em dez anos.

A solução foi rodar um script Python que fazia uma varredura completa das relações, identificava os órfãos e criava uma tabela temporária com as correções antes da importação final. Isso economizou aproximadamente seis horas de tentativa e erro que eu já tinha perdido na primeira fase do projeto.

Tipos de migração que você encontra no dia a dia

Existem basicamente cinco categorias principais. Migração de banco de dados, que já expliquei. Migração de infraestrutura, quando você move servidores físicos ou VMs para outro datacenter ou provedor cloud. Migração de aplicações, que envolve levar um sistema legado para uma arquitetura diferente, como migrar de monolito para microsserviços. Migração de identidade, que é sobre transferir usuários, senhas e permissões entre sistemas de directory, como LDAP para Active Directory ou para soluções SaaS como Okta. E migração de dados, que é mais específica: foca apenas nos dados, não na infraestrutura ou aplicação que os acessa. Muitas vezes essas migrações acontecem juntas. Raramente você migra apenas dados sem precisar ajustar a aplicação também.

Pegadinhas que ninguém conta

O maior erro que vejo em projetos de migração é subestimar a parte de validação. As pessoas passam semanas planejando a execução em si e quase nenhuma hora pensando em como vão verificar se tudo funcionou depois. Migrar 2 terabytes de dados de MySQL para MongoDB parece impressionante até você descobrir que os tipos de dados não estão mapeados corretamente e campos JSON estão sendo truncados. Outro ponto que gera problema constante é o downtime. Todo mundo quer zero downtime, mas a realidade é que para migrações grandes você precisa aceitar alguma janela de indisponibilidade ou construir um mecanismo de replicação dupla. A técnica mais segura é manter os dois sistemas rodando em paralelo durante um período de sincronização. Você escreve nos dois, testa no novo, e só quando os dados estiverem consistentes você faz o switch final. Esse período de paralelismo costuma durar entre duas e quatro semanas dependendo do volume.

Tem uma limitação importante que precisa ser dita claramente: migração nunca é perfeita. Sempre sobra dado. Sempre tem alguma funcionalidade que não migrou corretamente e só aparece quando o sistema novo já está no ar. O segredo não é evitar isso completamente, é ter um plano de rollback funcionando antes de começar. Sem um rollback testado, você está executando uma operação irreversível e isso é irresponsável.

Passo a passo prático para uma migração de banco de dados

Vou descrever o fluxo que uso atualmente. Ele serve para migrações médias, algo entre 50 e 500 gigabytes. Para volumes menores o processo é mais rápido, para maiores você precisa de ajustes específicos. O primeiro passo é fazer um inventário completo do sistema original. Não confie no que está documentado. Rode queries para descobrir tabelas sem primary key, índices duplicados, stored procedures com dependências ocultas, e conexões de aplicaciones que não estão registradas em lugar nenhum. Esse inventário geralmente leva de dois a três dias para sistemas bem estruturados e até duas semanas para legados desorganizados.

Depois vem a instalação do ambiente de destino e a configuração inicial. Certifique-se de que o tamanho do buffer, o número de conexões e os parâmetros de escrita estão adequados antes de começar a migração. Já vi gente perder horas porque o destination instance estava com default configuration e o throughput de escrita caía para nada durante a importação massiva. O terceiro passo é a estratégia de cutover. Para bancos pequenos, um dump tradicional com pg_dump ou mysqldump resolve. Para bancos grandes, use ferramentas como AWS DMS, Flyway, ou Liquibase que permitem replicação contínua. A diferença é que com replicação contínua o downtime real cai de horas para minutos, dependendo da taxa de alteração dos dados durante a transferência.

O quarto passo, e aqui é onde a maioria erra, é a validação pós-migração. Rode checksums comparativos entre fonte e destino. Verifique contagens de linhas em tabelas críticas. Teste queries de negócio reais nos dois ambientes e compare os resultados. Se houver diferença superior a 0,1 por cento em volumes grandes, pare e investigue antes de liberar o tráfego. O quinto passo é o cutover final. Faça no horário de menor tráfego, preferencialmente madrugada de quinta para sexta. Mantenha o sistema antigo rodando mas ReadOnly por pelo menos sete dias. Anuncie para a equipe de suporte que podem surgir problemas e tenha alguém disponível para voltar atrás se algo crítico falhar.

Quando não migrar

Às vezes a melhor decisão é não migrar. Se o sistema atual está estável, os custos de operação são aceitáveis, e não há pressão real de upgrade, migração pode ser um gasto desnecessário. Migração custa dinheiro em horas técnicas, em risco de downtime, em retrabalho, e em problemas que aparecem meses depois. Use migração quando houver ganho claro: redução de custo operacional, necessidade de escalabilidade, fim do suporte do fabricante, ou requisito de compliance que o ambiente atual não atende. Se você está migrando apenas porque "é o ano novo e todo mundo tá migrando", provavelmente está cometendo um erro. Migração é uma decisão pesada. Trate como tal.