Migração de banco de dados legado, sem perder dado.

Em quase toda migração de software legado, o maior risco não está no código: está nos dados. Uma tela mal reconstruída aparece no primeiro dia e é corrigida. Um saldo migrado errado aparece no fechamento do mês, depois de dezenas de decisões tomadas em cima dele. Por isso a migração de banco de dados é tratada como frente própria, com método próprio, e não como um "exporta e importa" no fim do projeto.

Os bancos típicos de sistema legado

Cada família traz um tipo de problema. Saber qual é o seu ajuda a prever onde está o trabalho.

Um exemplo de diferença sutil: no Oracle, texto vazio é tratado como NULL; no PostgreSQL e no SQL Server, não. Uma consulta que filtra "campo é nulo" passa a devolver outro resultado depois da migração, sem erro nenhum. É esse tipo de detalhe que só aparece em ensaio com dado real.

A sujeira que todo banco legado tem

Banco que está em produção há quinze anos acumula de tudo. Não é descuido de ninguém: é o resultado de versões, de gente diferente mexendo e de urgências resolvidas no improviso. O que mais encontramos:

• Duplicidade. O mesmo cliente cadastrado quatro vezes, com grafias diferentes, cada cadastro com parte do histórico.
• Campos multiuso. O campo OBS que guarda telefone, e-mail e um código de rota; o COMPLEMENTO que virou flag de cliente especial.
• Datas problemáticas. Datas guardadas como texto em formatos misturados, datas impossíveis, e o famoso 30/12/1899, que é a data "zero" do Delphi e do Access e aparece onde a data deveria estar vazia.
• Codificação e acentuação. Texto gravado em Latin1 ou Windows-1252, às vezes num banco que declara outra coisa. Na conversão para UTF-8, "ação" vira "ação" se a origem for lida com a codificação errada.
• Registros órfãos. Itens de pedido cujo pedido não existe mais, movimentos de um produto apagado. O banco antigo aceitava porque não havia chave estrangeira declarada; o novo, com integridade, recusa.

Nada disso se resolve com uma ferramenta de exportação. Cada caso pede uma decisão: corrigir, unificar, arquivar ou manter como está, e quem decide é quem conhece o negócio.

Regras escondidas em triggers e procedures

Em muitos sistemas, parte importante da regra de negócio não está na aplicação: está no banco. Um trigger que baixa o estoque quando o pedido é faturado. Uma procedure que calcula comissão. Uma view que a contabilidade consulta todo mês sem saber de onde vem.

Migrar só as tabelas e esquecer esses objetos é o jeito mais rápido de ter um sistema que "funciona" e calcula errado. No levantamento, cada trigger, procedure e view é lido e documentado. Depois decidimos, um por um, se ele é reescrito no banco novo ou se a regra sobe para a aplicação, onde fica mais fácil de testar e de manter.

O processo de migração de dados

A NasteSoft e seus parceiros já migraram bancos de dados e aplicações em Delphi, VB6 e .NET. O processo que usamos segue a mesma ideia de todo o nosso trabalho com legado: entender e documentar antes de mover qualquer coisa.

1. Levantamento e dicionário de dados. Mapeamos tabelas, campos, relacionamentos (os declarados e os que só existem na cabeça da aplicação), volumes, triggers, procedures e integrações. O resultado é um dicionário de dados que diz o que cada campo significa de verdade, não o que o nome sugere.
2. Mapeamento origem → destino. Para cada campo do banco novo, de onde vem, com qual transformação. Tipos, tamanhos, codificação, regras de conversão, valores padrão. Esse mapeamento é um documento revisado com a sua equipe, não um script que só o programador entende.
3. Saneamento. Duplicidades, órfãos, datas e campos multiuso são tratados com regras explícitas. O que não pode ser decidido automaticamente vira uma lista de pendências para quem conhece o negócio.
4. Ensaios repetidos com conferência automática. A migração completa roda muitas vezes, sobre cópias recentes da produção. Cada ensaio termina com conferência entre origem e destino: contagem de registros por tabela, somas de valores e quantidades, saldos, e comparação de registros por amostragem. O ensaio só é considerado bom quando os números batem.
5. Corte. Com o tempo de carga conhecido pelos ensaios, escolhemos a estratégia: janela de corte num horário combinado, quando a carga cabe nela, ou carga inicial com sincronização e escrita dupla quando a operação não pode parar.
6. Plano de retorno. O banco antigo não é desligado na virada. Existe um plano definido, e ensaiado, de como e até quando voltar para ele se algo der errado.

Sem parar a operação

A migração do banco raramente acontece sozinha. Quando ela faz parte de uma troca de sistema, segue o mesmo padrão de substituição incremental: o sistema novo assume uma área por vez, e os dados daquela área passam a ter um único dono. Durante a transição, sincronizações controladas mantêm os dois lados coerentes, e cada etapa pode ser revertida.

Quando a troca é só do banco, como sair de um SQL Server sem suporte ou de um Firebird antigo, a aplicação pode continuar a mesma, com ajustes pontuais no acesso a dados. Isso é comum em sistemas .NET, e é tratado em conjunto com a migração de .NET Framework para .NET moderno. Em sistemas desktop antigos, a troca do banco costuma vir junto com a da aplicação, como descrevemos na migração de sistemas Delphi.

Ferramentas: úteis, não suficientes

Existem boas ferramentas para mover esquema e dados, como o SQL Server Migration Assistant (SSMA), da Microsoft, para Access e Oracle, e o ora2pg, de código aberto, para Oracle → PostgreSQL. Nós usamos quando ajudam. Elas convertem estrutura e copiam registros; não sabem que o campo OBS guarda o telefone, que aquele cliente duplicado precisa ser unificado nem que a procedure de comissão tem uma exceção para um representante específico. Essa parte é trabalho de levantamento e de conversa com quem opera.

O que fica com você

• Banco atual, PostgreSQL ou SQL Server, com integridade referencial declarada.
• Dicionário de dados e mapeamento origem → destino documentados.
• Regras de triggers e procedures documentadas, reescritas ou levadas para a aplicação.
• Relatórios de conferência de cada ensaio e do corte final.
• Histórico preservado e o banco antigo arquivado, acessível para consulta.

Perguntas frequentes