Replicar um banco legado para um destino moderno parece assunto resolvido — até o dia em que a carga quebra toda noite por um motivo diferente. Ontem foi acentuação virando caractere estranho. Hoje, uma coluna que não coube. Amanhã, uma data que o banco novo recusa. O time descobre pela reclamação do usuário, reprocessa na mão e vira operador de retry.

Foi esse o cenário em um cliente do setor de seguros: replicações de um banco Progress legado para MySQL, orquestradas no Azure Data Factory, falhando a cada carga. Contamos aqui o que fizemos — mapear as falhas em oito classes, converter o dicionário de dados entre os dois mundos com apoio de IA, gerar pipelines em lote por linha de comando e deixar a replicação observável em vez de heroica.

O sintoma: cada carga falha de um jeito novo

Replicação legada é frágil por natureza. A origem tem trinta anos de decisões acumuladas — campos reaproveitados, tipos criados antes de existir padrão, tabelas sem chave primária declarada. O destino, moderno e rigoroso, recusa o que a origem tolerava em silêncio. Entre os dois, o orquestrador só informa que a atividade falhou.

O efeito prático é conhecido. A carga noturna quebra, alguém reprocessa de manhã, funciona “por acaso” e ninguém registra nada. Na semana seguinte o mesmo erro volta em outra tabela e a investigação recomeça do zero. Por isso a primeira decisão não foi técnica, foi de método: parar de corrigir e começar a classificar.

Por que classificar antes de corrigir

Sem classificação, todo incidente parece novo. Com ela, o padrão aparece rápido: oito classes de erro cobriam praticamente todas as falhas registradas.

• Conectividade e timeout — o runtime de integração perdia a sessão com o driver ODBC em cargas longas.
• Tipo sem equivalente direto — decimais e lógicos chegando ao destino com outra semântica.
• Truncamento — coluna de destino menor que o conteúdo real.
• Encoding — acentuação corrompida entre o legado e o charset do destino.
• Data inválida — datas zeradas ou fora de faixa, rejeitadas pelo modo estrito.
• Chave duplicada — tabelas sem chave primária real, com “identificador” repetido.
• Nulo em coluna obrigatória — campo opcional na origem virando NOT NULL no destino.
• Reprocesso sem idempotência — carga interrompida duplicava linhas ao rodar de novo.

Cada classe ganhou uma entrada no runbook: como identificar pela mensagem, qual consulta SQL confirma, qual é a correção e como validar depois. Esse documento é o entregável mais barato e mais subestimado do projeto — ele transforma “chamar quem entende” em “seguir o procedimento”, o mesmo princípio que aplicamos em sustentação de TI.

Conversão de dicionário assistida por IA

A parte mais trabalhosa da replicação não é mover linha, é traduzir o dicionário. Centenas de tabelas, milhares de colunas, três decisões por coluna: qual tipo no destino, qual codificação, o que fazer com chave e nulo. Feito à mão, é semana de planilha. Com um assistente de IA lendo o esquema exportado e devolvendo o DDL do destino, é uma tarde — desde que a saída seja tratada como proposta, não como verdade.

Três frentes dominam a tradução. Tipo sem equivalente direto: decimal de precisão arbitrária, lógico, texto sem limite declarado. Encoding: o legado grava em codificação de página única e o destino espera UTF-8; sem conversão explícita na leitura, cedilha e til chegam como lixo — e a carga termina com sucesso. Chave e nulo: onde a origem não declara chave primária, é preciso decidir entre identificador natural e chave técnica.

Essa parte é desenvolvimento puro apoiado por IA: o assistente propõe o mapeamento coluna a coluna, justifica cada escolha e gera o DDL. Nós revisamos — e é aí que o valor aparece, porque revisar mil linhas de proposta é bem mais rápido do que escrevê-las.

Validar a conversão em três camadas

Conversão sem validação é aposta. Usamos três camadas, nesta ordem.

1. Contagem — linhas por tabela, origem contra destino. Pega carga parcial e duplicação de reprocesso. É barato e deveria rodar em toda janela.
2. Checksum por coluna — soma dos campos numéricos e hash agregado dos textuais. Denuncia perda de precisão e corrupção de acentuação, ambas invisíveis na contagem.
3. Amostragem dirigida — em vez de amostra aleatória, escolher as linhas de borda: o maior texto da tabela, o valor com mais casas decimais, registros com acentuação, datas mínima e máxima, campos nulos. Erro de conversão mora nas bordas.

Pipelines em lote, não clique a clique

Com o dicionário fechado, sobra o trabalho mecânico: por tabela, um dataset de origem, um de destino e uma atividade de cópia. No portal, é clicar dezenas de vezes, com erro humano garantido no meio.

Fizemos diferente. Um template de dataset e um de pipeline, parametrizados por tabela, colunas e script de pré-carga; um gerador que lê o dicionário convertido e emite os JSON; e a publicação por linha de comando, versionando tudo no repositório. A correção que fecha a classe de reprocesso entrou aí: um TRUNCATE controlado como pré-script da cópia, tornando a carga completa idempotente — rodar duas vezes passa a ter o mesmo resultado de rodar uma. Seis pipelines corrigidos e republicados em uma janela.

O ganho é de ordem de grandeza. Corrigir um pipeline no portal levava horas, e a correção não se propagava para os outros. Com template, parâmetro e linha de comando, aplicar a mesma correção ao conjunto inteiro leva minutos — e fica registrada como mudança de código, não como memória de quem estava de plantão. É a disciplina de infraestrutura como código aplicada a dados.

O que fica depois da correção

O objetivo nunca foi zero falha, e sim que a falha vire evento tratável. Ao final, a replicação passou a ter quatro coisas que não tinha: classificação (toda falha cai em uma das oito classes), runbook (cada classe com diagnóstico e correção), alerta (quem precisa saber descobre antes do usuário) e validação automática na janela de carga.

Isso muda quem consegue atender. Antes, só quem conhecia o histórico resolvia. Depois, qualquer plantonista com o runbook trata as classes rotineiras e escala apenas o que é realmente novo.

Vale o limite honesto: a IA não substituiu ninguém aqui. Ela leu esquema, propôs mapeamento, gerou JSON e resumiu centenas de mensagens em oito padrões. As decisões que custam caro — o que é chave, o que pode arredondar, o que pode truncar — continuaram sendo de gente que responde pelo dado.

Para ir mais fundo, dois materiais da Inove Academy preparam o terreno. O guia rápido de migração para nuvem ajuda a decidir o que vai como está e o que merece redesenho antes de virar pipeline — replicação mal desenhada é dívida que se leva junto sem perceber. E a calculadora FinOps cobre o outro lado da conta: janela de carga malfeita é runtime ligado mais tempo do que precisa.

O aprendizado é simples de enunciar e difícil de praticar. Replicação confiável não vem de tentar de novo com mais capricho, e sim de reduzir as falhas a um conjunto pequeno e conhecido, converter o dicionário com validação real e corrigir em lote. A IA encurta cada uma dessas etapas — mas quem decide o que é dado correto continua sendo o time, e é bom que continue assim.