Valide Antes da Virada: Seis Camadas de Evidência na Migração de Dados

A transferência terminou. O log está verde. As contagens batem. Dá para virar a produção?

Ainda não. Contagem igual prova só que as duas tabelas têm o mesmo número de linhas. Elas ainda podem ter clientes diferentes, valores diferentes, ou o mesmo pedido duas vezes e outro faltando. A validação é onde a migração conquista o direito de virar, e merece plano, responsáveis e tempo próprios no cronograma.

Esta nota aprofunda o passo 8 do nosso guia de estratégia de migração de dados.

Primeiro, fixe a fronteira de comparação

Antes de comparar, combine qual momento está sendo comparado. Se a origem continua recebendo gravações durante a validação, cada diferença encontrada pode ser só tempo, não defeito.

• Virada offline: gravações paradas; compare depois da última carga.
• Carga inicial + atualização: congele uma fronteira (um horário, uma chave máxima ou uma pausa curta) e compare

só o que está dentro dela.

• Migração em fases: compare uma entidade, um cliente ou um serviço por vez.

Regra prática: diferença que você não explica é defeito até prova em contrário. Diferença que você explica (uma linha gravada depois da fronteira) entra no relatório com o motivo.

As seis camadas

1. Cobertura — está tudo lá?

Tabelas, partições, períodos e faixas de chave exigidos existem no destino. A contagem mora aqui, como triagem: barata, rápida e boa para achar uma tabela que ficou de fora.

SELECT COUNT_BIG(*) FROM dbo.orders WHERE created_at < '2026-11-01';   -- SQL Server: contagem em 64 bits
SELECT COUNT(*)     FROM public.orders WHERE created_at < '2026-11-01'; -- PostgreSQL

Em tabelas muito grandes, use contadores de 64 bits (COUNT_BIG no SQL Server) e conte por faixa, para uma consulta lenta não segurar a conferência inteira.

2. Identidade — as linhas certas, chave a chave

Compare chaves, não contagens: quais chaves faltam no destino, quais sobram e quais aparecem duas vezes. É aqui que aparece a maioria dos problemas silenciosos: um lote que falhou no meio, um filtro restritivo demais, uma nova tentativa que inseriu em dobro.

No dbSlice, a Comparação confere duas tabelas chave a chave e lista o que falta no destino, o que sobra no destino e o que tem valor diferente. As chaves saem separadas por vírgula, prontas para um WHERE id IN (…) e para ressincronizar só aquelas linhas.

3. Valores — o conteúdo certo

Chave igual com conteúdo diferente é a próxima armadilha: texto truncado, decimal arredondado por um mapeamento de tipo, horário deslocado por fuso. Compare as colunas críticas segundo as regras de conversão documentadas. Escreva as regras: "NUMBER(12,2) do Oracle → numeric(12,2) do PostgreSQL, sem arredondamento" é testável; "os tipos parecem certos" não é.

4. Relacionamentos — nada órfão

Filho sem pai quebra a aplicação de um jeito que contagem nenhuma mostra. Verifique órfãos no destino:

SELECT i.order_id
FROM   order_items i
LEFT   JOIN orders o ON o.order_id = i.order_id
WHERE  o.order_id IS NULL;

Depois confirme que as restrições desligadas para a carga em massa voltaram e foram validadas.

5. Significado de negócio — os números em que a área confia

Pergunte ao dono do negócio que totais ele conferiria primeiro: faturas em aberto, saldos, estoque, pedidos por status. Calcule dos dois lados, na mesma fronteira.

Números ilustrativos. Dois pedidos "enviados" a menos é exatamente o tipo de diferença que a comparação chave a chave localiza em seguida.

6. Prontidão da aplicação — funciona, não só bate

Aponte uma instância de teste da aplicação para o destino e rode os fluxos críticos: login, busca, cadastro, alteração, relatório, integração. Diferenças de banco (collation, maiúsculas e minúsculas, conversões implícitas) aparecem aqui e em nenhum outro lugar.

Torne repetível, não heroico

Validação feita uma vez, à mão, às 3 da manhã, é frágil. Rode em todo ensaio e guarde o resultado:

• Salve a comparação como job somente leitura e agende no Agendador de Tarefas do Windows ou no cron. Os jobs de

status do dbSlice relatam diferenças sem alterar dados e podem enviar o relatório por e-mail ou webhook.

• Mantenha o registro de evidências: fronteira, horários, contagens, diferenças, como cada uma foi explicada ou

corrigida e quem aprovou.

• Reserve tempo e capacidade: validar lê os dois bancos de novo. Rode as conferências pesadas numa réplica quando der.

Quando uma conferência falha

Corrija só o escopo afetado e rode de novo: ressincronize as chaves listadas, recarregue uma partição, corrija um mapeamento. Depois repita a camada que falhou e todas as seguintes. Conferência verde sobre evidência velha não é conferência verde.

Para levar

• Contagem faz triagem; chave prova. Compare chave a chave antes de confiar numa tabela.
• Congele a fronteira antes de comparar uma origem que ainda muda.
• Totais de negócio convencem quem assina a virada.
• Automatize as conferências e guarde as evidências: você vai rodá-las mais de uma vez.

O guia do Replicator mostra a conferência de chaves depois de uma execução com várias tabelas. A versão gratuita do dbSlice está na Microsoft Store; gravar num banco de destino exige licença Desktop ou Server.

Vai trocar de sistema e precisa de ajuda para desenhar a convivência dos dados? A Thinwork conduz o projeto com você.