Modernização de batch legado em VB6 com agentes de IA

Problema

Processos batch legados em VB6 na Techne, disparados como executáveis .exe por uma interface Java. São 97 processos, e esse volume inviabilizava a reescrita havia anos: grande demais para um big-bang e arriscado demais para tocar sem rede de segurança, porque o comportamento precisa continuar idêntico enquanto o sistema roda em produção. Era o tipo de projeto que ficava anos na gaveta.

Abordagem

Em vez de reescrever tudo de uma vez, meu entregável foi a arquitetura, o esqueleto e o processo de migração, de forma que a reescrita virasse um trilho incremental que um time consegue executar. Três decisões sustentam isso.

A primeira é um contrato arquitetural versionado no repositório: um catálogo canônico que mapeia cada processo VB ao pacote Java de destino e previne colisões de nome, mais um roteiro de migração por processo. O trabalho foi estruturado para agentes de IA, com skills reutilizáveis e acesso ao banco real via MCP, para os agentes validarem contra o banco de verdade em vez de suposições.

A segunda é a rede de segurança: testes de caracterização. O binário VB original roda no Windows via SSH e PowerShell e gera o gabarito, arquivos .csv e logs semânticos; o Job Spring Batch precisa reproduzir a mesma saída para a mesma entrada. A paridade exigida é funcional, no nível de domínio: mesma saída de negócio para a mesma entrada, com diferenças de timestamp fora de escopo. Sete cenários, do caminho feliz à idempotência, comparação de 6 campos de negócio por registro e uma comparação semântica do log que normaliza timestamp e encoding e casa cada linha com a categoria equivalente do log VB. Tudo roda contra um SQL Server real via Testcontainers.

A terceira é fidelidade onde importa e divergência onde compensa. O Step usa chunk-size=1, uma transação por registro, para preservar a semântica de commit e rollback do VB. O acesso a dados é JdbcTemplate puro, sem ORM, para manter as queries fiéis às originais. Um proxy de DataSource replica o bootstrap de sessão por conexão do legado, para as views de segurança do sistema antigo continuarem se comportando igual. A divergência é deliberada: skip-limit=100, para um registro problemático não abortar o lote inteiro como acontecia no VB.

A entrega troca o disparo de processo do sistema operacional por REST. A interface consumidora cria uma execução assíncrona, o POST devolve 202 e um identificador, consulta o status e recupera o log persistido por HTTP, com autenticação JWT. O serviço roda em container, Java 25 sobre Alpine, publicado por um pipeline no Azure DevOps.

Tecnologia

Java 25 LTS, Spring Boot 4 e Spring Batch 6 no núcleo. SQL Server acessado por JdbcTemplate, sem ORM; Flyway apenas para o schema de metadados do próprio Batch; Testcontainers para os testes de caracterização; autenticação JWT; empacotamento em container (eclipse-temurin:25-jre-alpine) com pipeline no Azure DevOps e imagem no Azure Container Registry. Do lado de IA, um contrato versionado para agentes, skills reutilizáveis e MCP para o SQL Server real.

Resultado

A arquitetura, o esqueleto e o método de migração estão de pé, validados de ponta a ponta em 1 dos 97 processos do backlog, com um gate de caracterização que prova a paridade antes de qualquer merge. Foi isso que tirou a reescrita da gaveta: o que era um big-bang inviável virou um trilho incremental, com contrato e rede de segurança, que o time executa processo a processo. Os desenvolvedores já estão sendo alocados para migrar o restante do backlog contra o mesmo contrato e o mesmo gate.

Não está terminado, e o ponto é esse: entreguei o caminho, não a migração inteira. O custo do trilho é concreto: cada processo exige capturar o gabarito do binário original num host Windows e manter um SQL Server real no circuito de teste.