Migração de dados: como não perder nada no caminho

Migração de dados dá errado por três motivos, quase sempre nessa ordem: alguém descobriu tarde que os dados do sistema antigo estavam sujos, ninguém ensaiou a migração inteira antes do dia, e não havia como voltar atrás. O roteiro abaixo ataca os três. Ele vale para trocar de ERP, sair de planilhas, unificar bases ou mudar de fornecedor.

Fase 1: inventário e perfil dos dados

Antes de escrever qualquer script, você precisa saber o que existe.

Liste as entidades e os volumes. Clientes, produtos, pedidos, notas, anexos, usuários. Quantos registros cada uma tem. Esse número vira base para a reconciliação depois.

Faça o perfil de cada campo importante. Rode consultas que respondam: quantos estão nulos, quantos valores distintos existem, quais formatos aparecem, quais estão fora do intervalo esperado. É aqui que surgem as surpresas:

• CPF com e sem pontuação, e alguns inválidos
• Data em três formatos diferentes na mesma coluna
• Cliente duplicado com nome escrito de forma ligeiramente diferente
• Valor negativo em campo que deveria ser positivo
• Campo "observação" contendo informação estruturada que alguém precisava guardar

Decida o que fazer com cada anomalia antes de migrar, e registre a decisão. Corrigir na origem, corrigir na transformação, migrar como está com marcação, ou não migrar. Essa lista de decisões é o documento mais importante da migração.

Não deixe os anexos de fora. Arquivos, imagens e documentos costumam ser lembrados na véspera. Eles têm volume, caminho e vínculo com registros, tudo isso precisa migrar junto.

Fase 2: mapa de-para

Uma planilha, uma linha por campo de destino:

Esse mapa é o que permite a outra pessoa entender, seis meses depois, por que um dado ficou daquele jeito. Também é o insumo de todos os testes.

Preserve o identificador de origem. Guarde em cada registro migrado a chave que ele tinha no sistema antigo. Custa uma coluna e salva toda investigação futura.

Fase 3: ensaios com dados reais

A regra é: nenhuma migração acontece pela primeira vez no dia da migração.

1. Ensaio 1, amostra. Alguns milhares de registros. Objetivo: fazer o script rodar do começo ao fim.
2. Ensaio 2, volume total, sem prazo. Rode com a base inteira. Objetivo: descobrir quanto tempo leva de verdade e quais registros quebram. Esse número define a janela.
3. Ensaio 3, cronometrado, com a equipe. Ensaio geral, com as mesmas pessoas e os mesmos passos do dia real, incluindo a validação. Objetivo: confirmar a janela e treinar a execução.

Entre os ensaios, corrija tanto os dados de origem quanto o script. Migração de sistema de médio porte costuma exigir de três a seis rodadas até os números baterem.

Fase 4: reconciliação

É o que substitui "parece que deu certo" por evidência. Rode automaticamente depois de cada ensaio e no dia real:

Contagem por entidade. Registros na origem versus no destino, com a diferença explicada linha a linha. "Faltam 47" não serve; "faltam 47, sendo 45 duplicados intencionalmente unificados e 2 sem CNPJ válido, listados aqui" serve.

Soma de valores. Total faturado por mês nos últimos 24 meses, origem contra destino. Diferença financeira é o erro mais grave e o mais fácil de detectar assim.

Contagem por categoria. Quantos pedidos em cada status, quantos clientes por estado. Revela erro de conversão de código que a contagem total esconde.

Amostra conferida à mão. Trinta registros escolhidos por critério, o maior, o mais antigo, o mais recente, os com caractere especial, os com campo vazio, conferidos campo a campo por alguém que conhece o negócio.

Consistência interna. Nenhum pedido órfão, nenhum item apontando para produto inexistente, nenhum total divergente da soma dos itens.

Fase 5: o dia da virada

Escreva o roteiro em passos numerados, com responsável e horário previsto para cada um:

1. Comunicar a parada aos usuários, com antecedência real
2. Bloquear escrita no sistema antigo (e confirmar que bloqueou)
3. Backup completo do sistema antigo, o ponto de retorno
4. Exportar os dados
5. Rodar a migração
6. Rodar a reconciliação automática
7. Ponto de decisão: os números bateram? Se não, aborta
8. Validação funcional por usuários-chave, com casos escritos
9. Segundo ponto de decisão com horário limite definido
10. Liberar o acesso
11. Manter o sistema antigo em modo somente leitura

O item 11 é o que mais tranquiliza a equipe. Não desligue nada por pelo menos 30 a 90 dias.

Plano de volta

Precisa estar escrito antes, com dois elementos: o horário limite para decidir (por exemplo, "às 14h de domingo, se os números não baterem, voltamos") e quem decide. Sem hora e sem nome, a tendência é insistir até estourar a janela e liberar um sistema com dados errados.

Voltar significa: reabrir a escrita no sistema antigo, comunicar os usuários e remarcar. Sistema antigo intacto e backup feito antes do passo 4 tornam isso barato.

Depois da virada

• Rode a reconciliação de novo depois de uma semana de uso.
• Monitore o volume de chamados por dado divergente; um pico indica problema sistemático, não caso isolado.
• Mantenha a base antiga em consulta pelo prazo combinado, e verifique as obrigações de guarda antes de descartar.
• Guarde o mapa de-para, os scripts e os relatórios de reconciliação. Em auditoria, é o que explica a origem de cada número.