A Migração de COBOL Que Compilou Perfeitamente — e Ainda Assim Corrompeu o Razão

O código estava perfeito. Esse era todo o problema.

Um programa de transferência bancária havia sido traduzido de COBOL para Java. Ele compilou. Os testes unitários passaram. Passou por todos os portões que havíamos construído para pegar erros. Então, no teste de aceitação do usuário, a primeiríssima transação disparou a verificação de consistência do banco de dados e tudo desmoronou.

A autópsia demorou mais do que deveria, porque nada no Java parecia errado. O culpado era uma variável chamada TRN-LIMIT. A ferramenta de tradução a havia lido como um número comum e lhe dado um tipo inteiro padrão. Mas TRN-LIMIT nunca foi definida onde a ferramenta estava procurando. Ela foi declarada em um copybook — um arquivo de cabeçalho compartilhado — incluído milhares de linhas antes na cadeia de execução, e esse copybook carregava uma cláusula REDEFINES: uma construção COBOL que permite que o mesmo espaço de memória seja lido como dois tipos de dados completamente diferentes, dependendo de um flag definido em outro lugar totalmente distinto. No mainframe, esse endereço continha um decimal empacotado. O novo código Java escreveu binário corrompido na coluna do banco de dados, e a integridade referencial do razão cedeu.

O código estava sintaticamente impecável. A falha era contextual. A ferramenta havia perdido uma dependência que vivia fora de seu campo de visão — e, na modernização de COBOL legado, é quase sempre assim que o dinheiro desaparece.

Projetos de modernização geralmente não morrem no código que você consegue ver. Eles morrem no código que a ferramenta não conseguiu.

Esta é a história de por que parei de acreditar que uma tradução melhor era a resposta, e do que construímos na Veriprajna em vez disso.

Por que "Cole o COBOL, Receba Java" Sempre Impressiona na Demonstração?

Se você participou de qualquer reunião de modernização de mainframe nos últimos dois anos, já ouviu o discurso: cole o seu COBOL, receba Java de volta. É sedutor porque a demonstração sempre funciona. Alguém insere um programa organizado de 200 linhas, o modelo retorna um Java limpo e idiomático, e todos na sala respiram aliviados. Finalmente.

Eu também acreditei nisso, por um tempo. Quando minha equipe atacou isso pela primeira vez, fizemos o óbvio — tentamos tornar a tradução melhor. Alimentamos os modelos com mais contexto, os ajustamos para as peculiaridades do COBOL, avaliamos a qualidade da saída. Existe até um modelo aberto ajustado chamado XMainframe, construído especificamente para isso, que pontua cerca de 30% mais alto que os modelos de código de uso geral em tarefas de COBOL. As traduções ficaram mais limpas. O Java ficou mais legível.

E mesmo assim quebrava no UAT. Repetidamente, exatamente naquele tipo de dependência oculta que afundou aquele programa de transferência bancária. Foi o mês em que percebi que estávamos polindo a coisa errada. A qualidade da tradução nunca foi o gargalo. O código que compila é a parte fácil. A parte difícil é o código que a ferramenta não consegue ver.

Os números em torno disso são brutais e consistentes: 70 a 80% dos projetos de modernização de mainframe fracassam em atingir seus objetivos. Não é que 70% atrasem — 70% fracassam. O diagnóstico habitual culpa testes subestimados ou migração de dados desorganizada, e isso é real. Mas por baixo de quase todos eles está a mesma causa raiz que eu acabara de ver ao vivo: as ferramentas tratam uma base de código como texto a ser convertido, quando na verdade é uma topologia a ser compreendida.

O Que "Cole o COBOL, Receba Java" Não Consegue Ver

Uma vez que você começa a procurar por cegueira contextual, você a vê por toda parte. Três padrões nos derrubaram com mais frequência, e nenhum deles é visível no arquivo de origem que um tradutor está encarando.

Comece pelo problema do copybook que já descrevi. Um único programa COBOL pode referenciar mais de quarenta copybooks, e esses copybooks incluem outros copybooks, então a definição real de uma variável pode estar vários níveis abaixo na cadeia de inclusão. Uma ferramenta baseada em texto lê a instrução à sua frente e infere um tipo. Ela não tem como saber que, em um campo de decimal empacotado, essa inferência está silenciosamente errada.

Depois há a aritmética. O decimal empacotado COMP-3 do COBOL não tem equivalente nativo em Java. Recorra a um double e você acabou de introduzir arredondamento de ponto flutuante em um sistema que movimenta dinheiro. Mesmo o BigDecimal, a ferramenta correta, não corresponde ao COBOL por padrão — você precisa fixar explicitamente seu modo de arredondamento em HALF_EVEN para espelhar a cláusula ROUNDED do COBOL. Erre isso e você fica errado por um centavo por transação. Esse centavo se acumula ao longo de milhões de transações até que, semanas depois, um relatório de reconciliação sinaliza uma variação que ninguém consegue explicar.

O padrão que quase todos esquecem é aquele que de fato derruba a produção: seu COBOL não roda sozinho. Um agendador — CA-7 ou TWS — orquestra algo entre dois mil e cinco mil jobs de batch, com cadeias de dependência entrelaçadas por eles. O Job A escreve um dataset à 1h da manhã que o Job B lê às 2h. Você pode migrar cada linha de COBOL impecavelmente e ainda assim derrubar o banco à meia-noite, porque ninguém mapeou a rede de jobs. O grafo de produção nunca esteve no código-fonte. Estava no JCL.

O job que quebra a produção às 2h da manhã nunca é aquele que você estava olhando.

É isso que quero dizer com topologia. O artefato que de fato executa o seu negócio é uma teia de relacionamentos — programas, copybooks, datasets, jobs agendados, tabelas DB2, transações CICS — e o código-fonte COBOL é apenas um fio dela.

Por que Parei de Confiar no Tradutor e Comecei a Desenhar o Mapa

O ponto de virada para nós foi decidir que o mapa é o produto.

Antes de traduzirmos uma única linha, construímos um grafo de conhecimento de toda a base de código — cada programa, cada aresta de copybook, cada dependência JCL, cada passagem de dataset, cada ponto de contato DB2 — e resolvemos os relacionamentos transitivos que os arquivos-fonte escondem. Quando você consegue ver que um programa tem mais de quarenta arestas de copybook e que uma delas carrega um REDEFINES a dois módulos de distância, o desastre do TRN-LIMIT simplesmente não acontece, porque você sabia que o campo era decimal empacotado antes de digitar um caractere de Java.

Quero ser preciso sobre por que isso é diferente do que o resto do mercado vende, porque o mercado é lotado e a maior parte dele é genuinamente boa na parte que resolve.

O watsonx Code Assistant for Z da IBM é o incumbente mais sério — um sistema agêntico, com agentes de orquestração, arquitetura e código, que lida com COBOL para Java e até PL/I e IMS, e que analisa o consumo de CPU indo até dentro dos copybooks. É também um compromisso de mais de US$ 2 milhões que roda em z/OS e se apoia nas ferramentas ADDI da IBM, o que silenciosamente prende você ao mainframe durante a migração que deveria libertá-lo dele. Ele não faz teste de equivalência comportamental, e não mapeia a sua rede de jobs JCL.

Depois há o momento que remodelou todo o mercado. Em fevereiro de 2026, a Anthropic publicou um manual de modernização de COBOL para o Claude Code; as ações da IBM caíram 13,2% no dia do anúncio, e uma rede de parceiros de US$ 100 milhões veio na sequência em março. O Claude Code é excelente em descoberta, documentação e leitura de código desconhecido — genuinamente útil nas fases iniciais. Mas é uma ferramenta de uso geral. Não tem um grafo de conhecimento embutido para resolver dependências transitivas, e não pretende resolver o agendamento de JCL, a equivalência comportamental ou as trilhas de auditoria que um banco regulado precisa produzir.

A fábrica de migração Azure da Microsoft mira o Java Quarkus e prende sua plataforma-alvo ao Azure. Os grandes integradores de sistemas — a DXC com seu motor de conversão patenteado, a TCS com o MasterCraft, a Infosys com o Cobalt, a Accenture — conduzem contratos de US$ 500 mil a mais de US$ 5 milhões e implementam ferramentas de fornecedores em vez de construir inteligência sobre o seu sistema; a Accenture liderou a migração do núcleo do Commonwealth Bank of Australia, que custou cerca de US$ 749,9 milhões e levou cinco anos. E o Visual COBOL da Micro Focus, frequentemente apresentado como ponto de partida, não é modernização de forma alguma — é re-hospedagem. Seu COBOL continua sendo COBOL, apenas em um novo runtime. A dívida técnica e o problema de mão de obra estão exatamente onde você os deixou.

Cada um desses faz algo real. O que nenhum deles faz é construir a topologia completa de dependências — JCL, CICS, DB2, copybooks e tudo mais — primeiro, independente de qualquer plataforma-alvo, e tratar esse mapa como a fundação sobre a qual todo o resto se apoia.

A maioria dos fornecedores vende a você um tradutor melhor. A tradução nunca foi a parte que falhava.

O Relógio Que Ninguém Consegue Parar

Aqui está a parte que transforma isso de um problema de engenharia em uma emergência.

As pessoas que entendem esses sistemas estão indo embora. O desenvolvedor COBOL médio nos EUA tem por volta de 55 anos. Aproximadamente 10% dessa força de trabalho se aposenta a cada ano, e 85% das universidades removeram o COBOL do currículo lá nos anos 1990, então quase ninguém os está substituindo. Sessenta por cento das organizações agora dizem que encontrar desenvolvedores COBOL qualificados é seu maior desafio de modernização — e 58% dos desenvolvedores que ainda conhecem esses stacks dizem que estão considerando pedir demissão por causa deles.

Já estive diante da versão disso que me assombra: a festa de aposentadoria da única pessoa que realmente entendia a janela de batch. Todos sorrindo, tem um bolo, e em algum canto da minha cabeça uma voz está dizendo esse conhecimento acabou de sair pela porta e não está escrito em lugar nenhum. Um grafo de conhecimento é, entre outras coisas, uma maneira de capturar o que está na cabeça daquela pessoa antes da festa — de fazer o mapa de dependências sobreviver às pessoas que o memorizaram.

E o que está em jogo não é pequeno nem abstrato. Cerca de 220 bilhões de linhas de COBOL ainda estão em produção ativa. Ele executa 95% das transações de caixas eletrônicos e processa cerca de US$ 3 trilhões por dia. Quarenta e três por cento dos sistemas bancários são construídos sobre ele. A dívida técnica dos EUA está em um valor estimado de US$ 1,52 trilhão, e a empresa média queima cerca de US$ 370 milhões por ano com ineficiência de sistemas legados, com as firmas de serviços financeiros gastando de 70 a 75% de seus orçamentos de TI apenas mantendo os sistemas antigos respirando. As equipes que acertam a migração relatam retornos de 114 a 225% e cerca de US$ 25 milhões por ano em economia — mas essa vantagem só existe do outro lado de uma migração que não fracassou. Esta é a rara modernização em que não fazer nada é a opção cara.

As Novas Ferramentas de IA Não Vão Simplesmente Resolver Isso?

Esta é a pergunta que mais recebo, e é justa, especialmente depois de o anúncio da Anthropic fazer parecer que o problema tinha acabado de ser declarado resolvido.

Minha resposta honesta: as novas ferramentas tornaram a fase de descoberta dramaticamente mais rápida, e isso é um progresso real — eu as uso. Mas a IA agêntica ficar boa em ler COBOL não muda a coisa que de fato mata os projetos. O Gartner espera que 40% dos aplicativos corporativos incluam agentes de IA para tarefas específicas até 2026; mais agentes traduzindo código mais rápido não ajuda se todos eles estão cegos para a mesma dependência JCL. Velocidade no problema errado é apenas uma maneira mais rápida de chegar ao UAT e fracassar lá.

A outra pergunta que recebo é sobre regulação, e é aquela que os bancos de médio porte subestimam. O Digital Operational Resilience Act da UE — DORA — entrou em vigor em janeiro de 2025 e exige resiliência operacional e testes de penetração conduzidos por ameaças que os sistemas legados simplesmente nunca foram projetados para passar. Os examinadores dos EUA na FFIEC e na OCC tratam a infraestrutura envelhecida como uma lacuna de conformidade ativa, e sistemas com mais de dez anos carregam cerca de três vezes a probabilidade de violação. Uma migração que não consegue produzir uma trilha de auditoria comprovando que o novo sistema se comporta de forma idêntica ao antigo não é uma modernização — é um novo passivo com sintaxe melhor.

É por isso que o teste de equivalência comportamental importa tanto quanto o mapa. A técnica é simples de descrever e difícil de fazer bem: capturar entradas e saídas reais do sistema legado — um dataset dourado — e reproduzi-las contra o novo até que o comportamento coincida, caso extremo por caso extremo. Esses casos extremos, acumulados ao longo de décadas, frequentemente codificam lógica regulatória que existe em nenhum outro lugar — nem em uma especificação, nem na cabeça de uma pessoa, apenas no código em execução. Já vi isso morder uma seguradora mais forte que um banco: a regra de tarifação que só dispara para um endosso de apólice de 1998, o cálculo de reserva de sinistros cujo arredondamento ninguém vivo consegue explicar, mas do qual toda auditoria depende. Perca-os silenciosamente e você vai descobrir quais importavam no dia em que um regulador perguntar.

Qual Tijolo Você Puxa Primeiro?

Uma vez que você tem o mapa, ele lhe diz algo que nenhum tradutor consegue: onde é seguro começar.

A estratégia dominante agora — por bons motivos — é a figueira estranguladora: em vez de uma reescrita big-bang, você extrai uma capacidade de cada vez, roda o antigo e o novo lado a lado, e mantém o sistema legado como um fallback ativo até que a nova peça tenha conquistado confiança. Mas todo fornecedor que recomenda a figueira estranguladora deixa de fora a pergunta mais difícil — qual módulo você estrangula primeiro? Escolha um profundamente acoplado e você recriou o risco do big-bang com passos extras.

O grafo de conhecimento responde a isso diretamente. Ele revela os módulos de menor acoplamento — aqueles com o menor número de dependências de entrada — para que você possa extrair uma peça real do sistema, provar a abordagem e construir confiança organizacional antes de tocar no núcleo perigoso. O mapa não é apenas um seguro contra a falha do TRN-LIMIT. Ele é o plano de sequenciamento.

Construímos tudo isso — o grafo de conhecimento de dependências, o sequenciamento de figueira estranguladora, o arcabouço de equivalência comportamental, deliberadamente independente de qualquer plataforma-alvo — na prática de modernização de COBOL legado da Veriprajna, voltada diretamente para os bancos e seguradoras de médio porte que os incumbentes com piso de US$ 2 milhões e os integradores de sistemas de sete dígitos tratam como pequenos demais para se incomodar.

Sobre o Que Eu Sou Honesto

Não vou fingir que a tecnologia resolve tudo, porque as falhas mais caras que já vi não eram nem um pouco técnicas.

Nenhuma ferramenta — a nossa incluída — conserta o engajamento organizacional, limpa anos de dados ruins ou vence a briga política de convencer duzentos desenvolvedores a mudar como trabalham. Projeta-se que o mercado cresça de cerca de US$ 9 bilhões em 2026 para o dobro disso até o fim da década, precisamente porque grande parte do gasto vai para a camada humana e organizacional, não para o compilador. E nenhum parser sobre a Terra, de código aberto ou comercial, cobre perfeitamente cada construção no IBM Enterprise COBOL — as instruções ALTER pré-1985, os REDEFINES mais profundos. Quem lhe disser o contrário está vendendo a você a lacuna. A tecnologia é necessária. Ela nunca foi suficiente.

Mas a parte que a tecnologia consegue assumir, ela precisa assumir completamente. A razão pela qual migrações queimam milhões e não entregam nada raramente é que alguém escreveu Java ruim. É que traduziram um sistema que nunca haviam de fato mapeado — convertendo fios de uma teia enquanto a própria teia permanecia invisível até a noite em que se rasgou.

Desenhe o mapa primeiro. Um sistema que sobreviveu às pessoas que o escreveram não perdoa uma dependência esquecida, e não existe versão deste trabalho que seja segura antes de você conseguir ver o que se conecta ao quê. Aprendemos isso com um razão desfeito por um único campo de decimal empacotado que ninguém sabia que estava ali. Encontre esses campos antes que eles encontrem você.