Migração de banco de dados: por que a validação pode mentir

Um script de validação de migração pode reportar "sucesso" mesmo quando o banco de destino está incompleto, comparando dados contra a origem errada ou construído a partir de uma cópia mais antiga do que se pensa. Isso acontece porque a maioria dos scripts de validação confere que algo rodou até o fim, não se o resultado ainda representa a produção — e é exatamente nessa diferença que uma migração aparentemente bem-sucedida esconde um destino incompleto.

Isso apareceu de forma concreta numa revisão recente de um runbook de migração de um banco de produção do Azure SQL Database, de alguns terabytes, para SQL Server on-premises via dbatools. O runbook tinha sete estágios em PowerShell — inventário, cópia isolada, exportação, importação, migração de logins, validação — e passava em todos os testes. A revisão de código encontrou quatro pontos em que a validação podia aprovar uma migração que não deveria ser aprovada. Nenhum deles derrubava o script. Todos apareciam como sucesso.

O problema não é o script quebrar, é o script mentir

Um script que falha é fácil de tratar: ele para, alguém olha o erro, corrige e roda de novo. O problema real está nos scripts que terminam normalmente e emitem uma mensagem de aprovação sem que essa aprovação signifique o que deveria significar. Isso é particularmente comum em runbooks de migração porque eles têm muitas etapas, cada uma gerando algum tipo de contagem, diferença ou checksum — e a lógica que decide se essas métricas viram "erro" ou apenas "informação" costuma ser a parte menos revisada do processo.

Quatro padrões apareceram na mesma revisão, e nenhum deles é específico dessa migração — todos se repetem em qualquer runbook que combine cópia, exportação e validação.

Os quatro pontos que mais escondem falha

Validação compara contra o banco errado. A cópia isolada gerada no início do processo é a origem real da exportação — é dela que o pacote de dados sai. Ainda assim, o script de validação comparava contagens de linha contra o banco de produção, que continua recebendo gravações durante toda a migração. Depois de algum tempo, qualquer produção diverge da cópia por motivo completamente normal: gravações novas que aconteceram depois que a cópia foi tirada. O script tratava essa divergência esperada como falha de migração — ou, dependendo do momento em que rodava, podia deixar passar uma migração que de fato perdeu dados, se a comparação caísse num instante de baixa atividade.

Diferenças de objeto são calculadas, mas não contam. O script calculava corretamente a diferença de stored procedures, views e outros objetos entre origem e destino — a variável existia, o número existia, aparecia no relatório. Mas esse valor nunca era somado ao total de erros que decidia se a migração passava ou não. Um destino sem cinco procedures terminava com a mesma mensagem de sucesso de um destino completo.

Reexecutar no mesmo dia reaproveita uma cópia antiga sem avisar. O nome da cópia temporária usada para gerar o pacote de exportação incluía apenas a data, não um identificador único de execução. Rodar o processo duas vezes no mesmo dia — algo comum quando a primeira tentativa falha por qualquer outro motivo, de rede a permissão — reaproveitava silenciosamente a cópia criada na primeira tentativa, com os dados daquele momento, não os mais recentes.

Falha de autenticação vira aviso, não bloqueio. A checagem de pré-requisitos testava se o servidor de destino aceitava a credencial específica exigida pelo processo. Quando essa credencial não estava disponível no ambiente onde o script rodava, ele caía para autenticação Windows por padrão, a conexão "funcionava" no sentido técnico, e a falha real — a credencial exigida não foi testada — virava apenas um aviso no log em vez de interromper a execução. O relatório de pré-requisitos dizia que o ambiente estava pronto sem ter checado o que deveria checar.

Por que isso não aparece no primeiro teste

Um runbook de migração costuma ser testado uma vez, num ambiente calmo, sem gravações concorrentes, sem reexecução no mesmo dia e com todas as credenciais já configuradas corretamente. Nessas condições, os quatro pontos acima são invisíveis: não há gravação nova para gerar divergência contra produção, não há objeto faltando para testar se o contador soma no total, não há segunda execução no mesmo dia para expor o reaproveitamento de cópia, e a credencial certa está disponível, então o caminho de autenticação alternativo nunca é exercitado.

É só na produção real — com gravações acontecendo, com uma primeira tentativa que falhou por outro motivo, com uma credencial temporariamente indisponível — que esses pontos deixam de ser teóricos.

O que uma validação confiável precisa ter

Três mudanças resolvem os quatro pontos sem reescrever o runbook inteiro:

• Comparar sempre contra a cópia congelada, nunca contra a produção em movimento. A cópia isolada é o contrato do que deveria ter sido migrado; a produção já seguiu em frente.
• Somar toda métrica de diferença ao total que decide aprovação. Se uma variável existe para contar algo, esse algo precisa entrar na conta final — calcular e não usar é pior do que não calcular, porque cria a aparência de que foi checado.
• Fazer nomes de execução únicos, não apenas datados, e falhar alto — não rebaixar para aviso — quando uma credencial exigida não está disponível.

Nenhuma dessas mudanças é cara ou lenta de aplicar. O custo real está em não aplicá-las antes de confiar no relatório final.

Próximo passo

Se existe um runbook de migração — de nuvem para on-premises, entre versões, ou entre motores — rodando com base num relatório de "validação concluída", vale reler a lógica que decide esse veredito antes da próxima execução real. Veja também como isso se conecta com a escolha entre BACPAC completo e uma migração por schema com carga incremental quando o banco tem vários terabytes.

Para quem quer essa revisão feita por quem lida com migração de SQL Server no dia a dia, a H1 Data oferece um diagnóstico gratuito do ambiente SQL Server: levantamento do runbook atual, dos pontos que podem gerar falso positivo e do que precisa mudar antes da próxima migração.