Migração de banco de dados legado sem perder dado: Access, Paradox, Firebird e SQL Server antigo

Por que migração de dados legado dá errado

Em toda migração de software legado, o banco de dados é o ativo mais valioso e o mais subestimado. O código pode ser reescrito; o cadastro de clientes, o histórico fiscal e os saldos de estoque não. E é comum o plano tratar a migração de dados como uma etapa técnica de fim de projeto — "a gente roda um script e importa" —, quando ela deveria começar no primeiro dia.

Os problemas raramente são de ferramenta. São de significado: um campo STATUS com valores que ninguém mais sabe explicar, um trigger que recalcula o saldo e que ninguém lembrou que existia, datas gravadas como texto em três formatos diferentes. A conversão de banco de dados funciona; o sistema novo começa a operar; e três semanas depois o financeiro descobre que os títulos baixados parcialmente voltaram como abertos.

Os bancos típicos desses sistemas — Access, Paradox (das aplicações Delphi com BDE), Firebird/InterBase e SQL Server de versões antigas — têm, cada um, suas armadilhas. Mas o método para atravessá-las é o mesmo.

1. Comece pelo dicionário de dados

Antes de qualquer script, monte o dicionário: cada tabela, cada campo, o tipo, o que significa, quem grava, quem lê, e os valores possíveis. Parte disso vem do próprio banco (o esquema), mas a parte que importa vem de ler o código da aplicação e de conversar com quem usa o sistema.

• Quais tabelas estão vivas? Sistemas antigos acumulam tabelas abandonadas, cópias de segurança feitas à mão (CLIENTES_OLD, PEDIDOS_2014) e tabelas temporárias que viraram permanentes.
• Quais relacionamentos existem de fato? Em Access e Paradox, muitas vezes não há chave estrangeira declarada; a relação só existe no código.
• O que cada código significa? TIPO = 3 é o quê? E por que existe o valor 7, que não aparece em nenhuma tela?

Esse levantamento é o mesmo trabalho que descrevemos em como documentar um sistema legado — e o dicionário de dados é uma das peças da documentação que fica com o cliente depois do projeto.

2. Ache as regras escondidas no banco

Em muitos sistemas, parte da regra de negócio não está na aplicação: está no banco. E ela não aparece numa olhada rápida nas tabelas.

• Triggers que atualizam saldo, gravam auditoria, geram número sequencial ou bloqueiam exclusão. No Firebird são comuns e escritos em PSQL; no SQL Server, em T-SQL.
• Stored procedures que fazem o fechamento do mês, o cálculo de comissão, a geração de parcelas.
• Campos calculados e colunas que são "cache" de outra informação — o total do pedido gravado no cabeçalho, que precisa bater com a soma dos itens (e às vezes não bate).
• Geradores e sequências (os generators do Firebird, o AutoNumeração do Access, o IDENTITY do SQL Server), cujos valores atuais precisam ser levados para o destino para que a numeração não colida.
• "Flags" mágicas: o cliente com CODIGO = 0 que significa "consumidor final", o registro com data 01/01/1900 que significa "sem data", o campo OBS que começa com * para indicar cancelado.

Cada uma dessas regras precisa de uma decisão explícita: vai para o código do sistema novo, continua no banco, ou deixa de existir. O que não pode é ser esquecida.

3. Conheça a sujeira antes que ela conheça você

Bancos que rodaram por quinze ou vinte anos acumulam sujeira. Não é desleixo de ninguém; é o efeito de versões diferentes do sistema, importações, correções manuais e falta de restrições. A sujeira típica:

• Encoding. Acentos corrompidos ("JOSÉ" no lugar de "JOSÉ") ou bancos Firebird criados com charset NONE guardando texto em WIN1252. Precisa ser identificado e convertido de forma consistente, não corrigido no olho.
• Datas. Datas inválidas, datas como texto, anos com dois dígitos, o 30/12/1899 que é o "zero" de data do Delphi e do Access aparecendo onde deveria haver nulo. No Firebird em dialeto 1, o tipo DATE carrega também hora.
• Duplicidades. O mesmo cliente cadastrado três vezes, com CPF/CNPJ formatado de jeitos diferentes ou sem dígito verificador válido.
• Registros órfãos. Itens de pedido cujo pedido foi apagado, parcelas sem título, movimentos de um produto excluído. Sem chave estrangeira, o banco deixou acontecer.
• Nulos e vazios. Em alguns bancos (o Oracle é o exemplo clássico), texto vazio e nulo são a mesma coisa; em outros, não. Num campo booleano do Access, verdadeiro é -1.
• Ordenação e comparação. O SQL Server costuma ser configurado sem diferenciar maiúsculas e acentos; o PostgreSQL, por padrão, diferencia maiúsculas. Uma busca que funcionava pode parar de achar registros.

4. Mapeamento e transformação

Com o dicionário e o perfil em mãos, escreve-se o mapeamento: para cada tabela e campo do destino, de onde vem, que transformação sofre e o que acontece com o registro que não se encaixa. Esse documento é o contrato da migração e precisa ser revisado por quem conhece o negócio.

Para migrar Access para SQL Server, a Microsoft oferece o SQL Server Migration Assistant (SSMA), que cria o esquema e copia os dados. Para migrar Firebird para PostgreSQL, a conversão de tipos é direta na maior parte dos casos; o trabalho está nas procedures e triggers, que precisam ser reescritas em PL/pgSQL ou levadas para a aplicação. Em qualquer caso, a ferramenta faz a parte mecânica — o mapeamento de significado continua sendo seu.

Uma regra prática: a transformação deve ser um processo repetível (scripts ou um programa de carga versionado), nunca uma sequência de passos manuais. Ela vai rodar muitas vezes.

5. Ensaios repetidos com conferência automática

A migração de dados não é executada uma vez; é ensaiada várias vezes sobre cópias recentes da produção, até rodar limpa. Cada ensaio produz um relatório de conferência automático:

• Contagens: quantidade de registros por tabela e por grupo relevante (clientes ativos, pedidos por ano, títulos por situação) na origem e no destino.
• Somas de controle: totais financeiros — valor de títulos em aberto, saldo de estoque por produto, faturamento por mês. Precisam bater ao centavo, ou a diferença precisa estar explicada.
• Amostragem: registros escolhidos ao acaso, comparados campo a campo, e uma lista de casos conhecidamente difíceis (o cliente com dez endereços, o pedido com devolução parcial) verificados um a um.
• Rejeitados: todo registro que não pôde ser migrado vai para uma tabela de rejeitos com o motivo. Rejeito silencioso é perda de dado.
• Tempo: quanto a carga completa demorou. É esse número que dimensiona a janela de corte.

A cada ensaio, o número de divergências cai. Quando duas ou três execuções seguidas saem sem divergência não explicada e com tempo previsível, a migração está pronta para o corte. E, num ensaio, quem valida os relatórios são também as pessoas do negócio: o financeiro confere os títulos, o estoque confere os saldos.

6. Estratégia de corte

Há três formas principais de fazer a passagem definitiva, com custos e riscos diferentes:

Na migração incremental de sistemas — o sistema novo assumindo um módulo por vez —, o corte também é por módulo: os dados de cadastro de produto passam primeiro, depois os de pedido, e assim por diante, com sincronização entre as partes durante a convivência. Cada corte é menor e menos arriscado.

7. Rollback: planeje a volta antes da ida

Todo corte precisa de um plano de volta escrito, testado e com critério de acionamento definido antes: "se a conferência apontar diferença acima de tal limite, ou se o faturamento não rodar até tal hora, voltamos". Isso inclui:

• Backup verificado da origem imediatamente antes do corte — restaurado em teste, não só gerado.
• Decisão sobre o que fazer com o que foi gravado no destino depois do corte, se for preciso voltar.
• Quem decide, e até quando a volta ainda é possível sem perda.

O banco antigo fica disponível em modo somente leitura por um período depois do corte. É a forma mais barata de responder a "como estava isso antes?".

8. O que fazer com o histórico

Nem todo dado precisa passar por toda a transformação. Uma divisão útil:

• Dados vivos — cadastros ativos, saldos, títulos em aberto, pedidos em andamento: migrados com todo o rigor.
• Histórico consultado — vendas e movimentos dos últimos anos que aparecem em relatórios: migrados, às vezes de forma simplificada.
• Histórico de guarda — o que só precisa existir por obrigação legal ou eventual consulta: pode ir para uma base somente leitura, com uma tela de consulta simples, em vez de entrar no modelo novo.

O prazo de guarda é decisão do negócio, com orientação contábil e jurídica. A migração só precisa garantir que o dado continue acessível e íntegro.

Checklist da migração de banco de dados

1. Inventário de tabelas vivas, mortas e duplicadas.
2. Dicionário de dados com significado de campos e códigos, validado por quem usa.
3. Lista de triggers, procedures, views, geradores e campos calculados, com decisão para cada um.
4. Perfil dos dados: nulos, distintos, faixas, órfãos, duplicidades, encoding.
5. Regras de limpeza acordadas com o negócio (o que corrigir, o que descartar, o que rejeitar).
6. Documento de mapeamento origem → destino revisado.
7. Processo de carga repetível e versionado.
8. Relatório automático de conferência: contagens, somas, amostras, rejeitados, tempo.
9. Pelo menos dois ensaios completos sem divergência não explicada.
10. Estratégia de corte escolhida e janela medida nos ensaios.
11. Plano de rollback escrito, com critério de acionamento e backup restaurado em teste.
12. Decisão sobre o histórico e acesso somente leitura ao banco antigo.
13. Validação pós-corte pelas áreas de negócio nos primeiros dias de operação.

Se a troca de banco vem junto com a troca do sistema — um Delphi ou um VB6 saindo de cena, ou uma aplicação migrando do .NET Framework para o .NET moderno —, o plano de dados se encaixa no plano maior de migração de sistemas legados, módulo a módulo. E, se a proposta que você recebeu for "convertemos tudo automaticamente", vale ler antes por que o conversor automático não resolve.

Perguntas frequentes