[Pitch] O que aprendi construindo um agente para planejar migrações de bancos de dados

Projetos de migração de bancos de dados costumam ser apresentados como um processo de conversão entre duas tecnologias.

Na prática, a parte mais difícil geralmente acontece antes da migração propriamente dita: entender o esquema atual, identificar incompatibilidades, definir o modelo de destino e documentar as decisões técnicas.

Foi a partir desse problema que comecei a desenvolver o MigraFlow, um agente de IA para apoiar o planejamento de migrações de esquemas legados.

Neste artigo, vou explicar como estruturei esse processo, quais informações são analisadas, como os riscos são identificados e quais limitações encontrei durante o desenvolvimento.

O problema
Considere um banco de dados legado com tabelas, colunas e relacionamentos criados ao longo de vários anos.

É comum encontrar situações como:

Nomes de tabelas em letras maiúsculas;
Abreviações que não são mais utilizadas pela equipe atual;
Tipos de dados específicos do banco de origem;
Chaves estrangeiras não documentadas;
Colunas sem correspondência clara no banco de destino;
Diferenças entre os dialetos SQL;
Dependências que afetam a ordem de criação das tabelas.
Uma migração baseada apenas em regras simples de substituição pode gerar um resultado tecnicamente válido, mas incorreto do ponto de vista do projeto.

Por exemplo, converter NUMBER para NUMERIC pode ser simples. Porém, decidir a precisão e a escala adequadas exige uma análise mais cuidadosa.

Da mesma forma, alterar CD_CLI para cd_cli é uma transformação de nomenclatura. Já decidir se uma coluna deve ser preservada, renomeada ou removida exige contexto sobre o esquema.

A separação entre AS-IS e TO-BE
A primeira decisão de projeto foi separar claramente os dois lados da migração.

O modelo AS-IS representa o esquema atual:

Tabelas existentes;
Colunas;
Tipos de dados;
Chaves;
Índices;
Restrições;
Relacionamentos;
Dependências.

O modelo TO-BE representa a estrutura desejada no banco de destino.

Essa separação é importante porque evita misturar o que já existe com o que está sendo proposto. O sistema precisa primeiro compreender a origem e depois construir uma representação do destino.

O resultado esperado é uma relação explícita entre os dois modelos:

Origem Destino Transformação
TB_CLIENTE tb_cliente Ajuste de nomenclatura
CD_CLI cd_cli Ajuste de nomenclatura
NM_CLI nm_cli Ajuste de nomenclatura
DT_NASC dt_nasc Conversão de tipo
VL_LIMITE vl_limite Conversão numérica
FL_ATIVO fl_ativo Conversão de tipo

O objetivo não é apenas gerar uma tabela de correspondência, mas também registrar a justificativa e o grau de confiança de cada decisão.

O agente não analisa os dados dos registros
Uma decisão importante foi limitar o escopo do agente à estrutura do banco de dados.

O MigraFlow não lê o conteúdo dos registros. Ele trabalha com metadados, como:

Nomes de tabelas e colunas;
Tipos de dados;
Chaves primárias;
Chaves estrangeiras;
Índices;
Restrições;
Relacionamentos;
Dependências;
Informações do esquema de origem e destino.
Essa limitação foi pensada por dois motivos.

O primeiro é segurança. O planejamento da migração não precisa necessariamente acessar informações armazenadas nos registros.

O segundo é foco. O objetivo do agente é auxiliar a análise estrutural e o planejamento técnico, não substituir ferramentas de extração, carga, validação ou saneamento de dados.

Como o mapeamento é gerado
O processo pode ser dividido em algumas etapas.

1. Leitura do esquema de origem
   A primeira etapa consiste em obter a estrutura do banco de origem por meio de metadados ou scripts DDL.

Nesse momento, o sistema identifica objetos como:

Tabelas;
Colunas;
Tipos;
Chaves;
Relacionamentos;
Índices;
Restrições.

2. Normalização das informações
   Como diferentes bancos de dados representam suas estruturas de formas distintas, os dados precisam ser normalizados antes da análise.

Por exemplo, tipos como VARCHAR2, NUMBER, TIMESTAMP ou CHAR podem possuir equivalentes diferentes dependendo do banco de destino.

A normalização cria uma representação comum para que as regras de comparação sejam aplicadas de forma consistente.

3. Aplicação das convenções de nomenclatura
   Em muitos projetos, o banco de destino possui regras diferentes para nomes de tabelas e colunas.

As transformações podem incluir:

Conversão para letras minúsculas;
Remoção de prefixos;
Expansão de abreviações;
Padronização de separadores;
Conversão de nomes compostos;
Adequação aos padrões definidos pela equipe.
Essas regras não devem ser aplicadas de maneira cega. O sistema também precisa indicar quando uma transformação é apenas uma convenção ou quando existe uma ambiguidade.

4. Conversão de tipos
   A conversão de tipos é uma das etapas mais sensíveis.

Um mapeamento simples pode parecer suficiente:

VARCHAR2 -> VARCHAR
NUMBER -> NUMERIC
DATE -> TIMESTAMP
CHAR -> CHAR

No entanto, o tipo de origem pode possuir características que não estão representadas apenas pelo nome. Precisão, escala, tamanho e comportamento de valores nulos também precisam ser considerados.

Por isso, o resultado do mapeamento deve indicar possíveis riscos e casos que exigem revisão manual.

5. Análise de dependências
   A ordem das tabelas não pode ser definida apenas pela ordem em que aparecem no DDL.

Se uma tabela possui uma chave estrangeira para outra, essa dependência precisa ser considerada no planejamento.

Uma representação simplificada seria:

tb_cliente
|
└── tb_pedido
|
└── tb_item_pedido

Nesse exemplo, tb_cliente precisa ser considerada antes de tb_pedido, e tb_pedido antes de tb_item_pedido.

Essa informação pode ser utilizada para criar uma ordem inicial de migração ou para identificar ciclos que exigem tratamento especial.

Avaliação de risco
Além do mapeamento, o sistema gera uma avaliação dos riscos encontrados.

Alguns exemplos são:

Coluna sem correspondência no destino;
Tipo sem conversão direta;
Possível perda de precisão;
Chave estrangeira não identificada;
Tabela dependente de outra ainda não migrada;
Divergência entre a estrutura esperada e a estrutura encontrada;
Nomenclatura ambígua;
Objeto que exige intervenção manual.
Um exemplo de relatório pode ser representado assim:

Tabela: TB_CLIENTE
Risco geral: Alto

Problemas identificados:

• Uma coluna sem correspondência clara;
• Nenhuma linha inserida durante a execução;
• Necessidade de revisar o mapeamento;
• Necessidade de validar a lógica de transformação.
  O objetivo desse relatório não é apenas classificar o projeto como “seguro” ou “inseguro”. Ele deve explicar o motivo da classificação e indicar quais ações podem ser tomadas.

Um resultado negativo também pode ser útil
Durante os testes, um dos relatórios indicou que cinco linhas foram processadas, mas nenhuma foi inserida no destino.

O resultado foi uma taxa de sucesso de 0%.

Embora isso represente uma falha na execução, o relatório foi útil porque tornou o problema explícito. Em vez de considerar a migração concluída apenas porque o processo terminou, o sistema registrou a inconsistência e recomendou uma investigação do mapeamento e da lógica de transformação.

Esse comportamento é importante em processos automatizados. Uma execução concluída não significa necessariamente uma migração bem-sucedida.

É necessário verificar:

Quantas linhas foram processadas;
Quantas foram inseridas;
Quantas foram rejeitadas;
Quais exceções ocorreram;
Se os relacionamentos foram preservados;
Se o esquema final corresponde ao planejamento.
O papel da inteligência artificial
A inteligência artificial pode ajudar principalmente na interpretação e organização de informações que, em projetos maiores, seriam analisadas manualmente.

No entanto, ela não elimina a necessidade de regras determinísticas e validações técnicas.

No desenvolvimento do MigraFlow, procurei combinar:

Regras de conversão;
Validações estruturais;
Análise de dependências;
Convenções de nomenclatura;
Modelos de linguagem;
Relatórios estruturados;
Revisão humana.
Essa combinação é importante porque cada abordagem resolve um tipo diferente de problema.

As regras determinísticas são mais previsíveis para conversões conhecidas. O modelo de linguagem pode ajudar a interpretar nomes e sugerir correspondências. A validação estrutural verifica se o resultado é tecnicamente consistente. A revisão humana avalia se a decisão faz sentido no contexto do projeto.

Limitações
O agente não consegue resolver todos os problemas de uma migração apenas com o esquema.

Algumas decisões dependem de informações que não estão presentes nos metadados, como:

Regras de negócio;
Significado real de determinadas colunas;
Qualidade dos dados;
Dados duplicados;
Valores inválidos;
Requisitos de auditoria;
Necessidades de compatibilidade com aplicações existentes;
Regras de retenção e anonimização.
Por esse motivo, o MigraFlow não deve ser tratado como uma solução completa de ETL ou como substituto de uma estratégia de validação de dados.

Ele atua em uma etapa específica: análise estrutural, mapeamento, avaliação de riscos e planejamento.

O que aprendi durante o desenvolvimento
Algumas conclusões se tornaram evidentes ao longo do projeto.

1. Nomenclatura também carrega contexto
   O nome de uma coluna não é apenas um identificador técnico. Ele pode refletir uma convenção, uma regra de negócio ou uma decisão histórica da equipe.

2. Um mapeamento precisa ser justificável
   Não basta informar que uma coluna foi convertida. É importante registrar por que a conversão foi feita e qual é o nível de confiança da decisão.

3. Dependências devem ser analisadas antes da execução
   A ordem das tabelas influencia diretamente a criação das estruturas e a preservação dos relacionamentos.

4. Relatórios precisam explicar os problemas
   Classificar uma migração como “alto risco” sem apresentar os motivos não ajuda a equipe. O relatório precisa apontar o problema e sugerir os próximos passos.

5. A aprovação humana continua essencial
   A inteligência artificial pode acelerar a análise, mas decisões de migração devem ser revisadas por profissionais que conhecem o sistema e suas regras.

Conclusão
Migrar um esquema legado para uma arquitetura moderna exige mais do que converter nomes e tipos de dados.

É necessário compreender a estrutura existente, definir o modelo de destino, analisar dependências, identificar riscos e documentar as decisões antes de iniciar a execução.

O MigraFlow nasceu como uma tentativa de organizar esse processo com o apoio de inteligência artificial, sem acessar o conteúdo dos registros e sem retirar da equipe técnica a responsabilidade pela aprovação.

A proposta é simples:

Analisar o modelo AS-IS;
Construir uma proposta TO-BE;
Identificar riscos;
Gerar um plano de migração;
Permitir a revisão e a aprovação da equipe.
Ainda há muitos desafios a resolver, principalmente quando o significado das estruturas depende de regras de negócio que não estão documentadas no banco.

Mesmo assim, a experiência mostrou que uma etapa de análise mais estruturada pode reduzir incertezas e revelar problemas antes da execução.

Esse é o principal objetivo do projeto: ajudar equipes a entender melhor o que será migrado, quais decisões precisam ser tomadas e quais riscos devem ser tratados antes de avançar.