Modernização de Mainframe Legado
70-80% dos projetos de modernização de mainframe fracassam. Não porque a tecnologia esteja errada, mas porque as ferramentas tratam o código como texto em vez de topologia. Construímos o mapa da sua base de código antes de tocar em uma única linha, para que sua migração tenha êxito onde outras queimaram milhões e não entregaram nada.
US$ 1,52 trilhão
Dívida Técnica dos EUA
Pragmatic Coders, 2025
10%/ano
Atrito da Força de Trabalho COBOL
IEEE Spectrum, 2025
70-80%
Taxa de Fracasso da Modernização
Meta-Análise do Setor, 2025
As ferramentas que prometem "cole COBOL, receba Java" produzem código que compila. Essa é a parte fácil. A parte difícil é o código que elas não conseguem enxergar.
Considere um programa de processamento de transferências eletrônicas. Ele contém uma instrução COMPUTE usando uma variável chamada TRN-LIMIT. Um assistente de codificação por IA traduz a instrução para uma operação Java BigDecimal . O código compila. Os testes unitários passam.
Em UAT, a primeira transação derruba a verificação de consistência do banco de dados.
A autópsia: TRN-LIMIT não estava definido no arquivo-fonte que a IA traduziu. Ele estava definido em um copybook incluído milhares de linhas antes na cadeia de execução. Esse copybook continha uma cláusula REDEFINES , uma construção COBOL que permite que o mesmo endereço de memória seja interpretado como dois tipos de dados diferentes, dependendo de um flag definido em um módulo completamente diferente.
A IA enxergou TRN-LIMIT como um campo numérico simples e assumiu um tipo inteiro padrão. No mainframe, esse endereço de memória continha um decimal compactado (COMP-3). A aplicação Java gravou dados binários corrompidos na coluna do banco de dados, disparando uma falha de integridade referencial.
O código estava sintaticamente perfeito. A falha foi cegueira contextual. A IA deixou escapar uma dependência que existia fora do seu campo de visão.
Um único programa COBOL pode referenciar mais de 40 copybooks. Cada copybook pode fazer COPY de outros copybooks. As definições de variáveis podem estar 5 níveis abaixo na cadeia de inclusão. Ferramentas de IA baseadas em texto não enxergam nada disso.
Seu COBOL não roda de forma autônoma. CA-7 ou TWS agenda de 2.000 a 5.000 jobs JCL com cadeias de dependência. O Job A grava um dataset que o Job B lê às 2h da manhã. Migre o COBOL, mas deixe de lado o JCL, e a produção quebra à meia-noite.
O decimal compactado COMP-3 do COBOL não tem equivalente em Java. Um double Java introduz erros de arredondamento de ponto flutuante. Mesmo BigDecimal exige a configuração explícita do modo de arredondamento (HALF_EVEN) para corresponder à cláusula ROUNDED do COBOL. Um centavo errado se acumula ao longo de milhões de transações.
Todo grande fornecedor de tecnologia agora vende modernização de mainframe. Veja o que cada um realmente entrega, e onde permanecem as lacunas.
| Fornecedor / Abordagem | O Que Faz | Custo Típico | O Que Deixa Escapar |
|---|---|---|---|
| IBM Watsonx Code Assistant for Z | Tradução agêntica de COBOL para Java com análise de dependências ADDI. Arquitetura multiagente (agentes Orchestrate, Architect, Code). Suporta PL/I e IMS. | US$ 2M+ (licenciamento corporativo + requisito de z/OS) | O ADDI roda em z/OS, criando dependência de fornecedor durante a migração. O parser tem dificuldades com construções COBOL pré-85 (instruções ALTER). Sem testes de equivalência comportamental. Sem mapeamento de dependências JCL. |
| Anthropic Claude Code | Análise de código com IA, documentação, mapeamento de dependências. Forte nas fases de descoberta e exploração. Suporta migração incremental e empacotamento de API. | Preço de API baseado em uso | IA de propósito geral. Sem grafo de conhecimento integrado para resolução de dependências transitivas. Não aborda agendamento JCL, testes de equivalência comportamental nem trilhas de auditoria regulatória. |
| Microsoft Azure Migration Factory | Agentes agênticos modulares via Semantic Kernel. Agentes COBOL Expert + Java Expert. Mira em Java Quarkus. Agente de migração Azure Copilot em prévia. | Consumo do Azure + consultoria | Dependência do Azure para a plataforma de destino. Os agentes de código aberto são implementações de referência, não prontos para produção em ambientes regulados. Suporte limitado a CICS/IMS. |
| DXC Technology | Conversão automática de código patenteada (COBOL/RPG/JCL para Java). Décadas de expertise em mainframe. Modelos de nuvem híbrida + mainframe-as-a-service. | US$ 1M-US$ 10M+ | Ferramentas proprietárias, transparência limitada sobre a lógica de conversão. Foco em grandes corporações. Prazos de engajamento de 18-36 meses são comuns. |
| TCS / Infosys / Accenture | Práticas de grandes integradores de sistemas com frameworks proprietários (MasterCraft, Cobalt). Equipes de entrega massivas. Gestão de programa de ponta a ponta. | US$ 500K-US$ 5M+ | Abordagem centrada em plataforma. Eles implementam ferramentas de fornecedores, não constroem inteligência customizada. Sobrecarga do modelo de engajamento de grandes SIs. Um SI conduziu a migração de um banco de AUD$ 1 bilhão que levou 5 anos e dobrou seu orçamento. |
| Micro Focus (OpenText) Visual COBOL | Execute COBOL nativamente em .NET/JVM. Ponto de partida pragmático de "figueira estranguladora". Líder de mercado de compiladores COBOL. | US$ 200K-US$ 500K de licenciamento | Não é modernização, é re-hospedagem. A lógica COBOL continua sendo COBOL. A dívida técnica persiste. Não resolve o problema de força de trabalho. |
| DIY com IA de código aberto | XMainframe LLM (7B/10,5B de parâmetros, 30% melhor que o DeepSeek em COBOL). Análise sintática com Tree-sitter. Pipelines customizados. | Tempo de engenharia + infraestrutura | Exige profunda expertise em COBOL + engenharia de grafos. Nenhum parser COBOL de nível de produção cobre todas as construções do IBM Enterprise COBOL v6.x. Alto risco de incorporar lacunas do parser à fundação. |
Cinco capacidades, cada uma abordando uma lacuna específica na cadeia de ferramentas de modernização. Somos neutros em relação a fornecedores: o grafo de conhecimento funciona independentemente de seu destino ser AWS, Azure, GCP ou Java on-premises.
Ingerimos seu código-fonte COBOL, copybooks, bibliotecas JCL, exportações do catálogo DB2, definições de transações CICS e hierarquias de segmentos IMS em um banco de dados de grafo unificado. Cada variável, cada cadeia PERFORM, cada cláusula REDEFINES, cada dependência de batch torna-se uma aresta explícita do grafo. Recorremos ao Neo4j quando consultas complexas de fecho transitivo dominam o caso de uso, e ao Memgraph quando a velocidade de travessia em tempo real importa para a exploração interativa.
O grafo processa aproximadamente 200K-300K linhas por dia durante a ingestão. Para uma base de código de 2M de LOC, espere de 8 a 12 semanas desde a primeira ingestão até um grafo validado e consultável. A saída é um ativo permanente: sua base de código como topologia pesquisável, não arquivos de texto opacos.
Antes que qualquer tradução de código comece, executamos a análise de grafo em quatro dimensões: pontuação de acoplamento (quantos outros módulos dependem deste), densidade de REDEFINES/COMP-3 (quantas armadilhas de tipo de dados existem), percentual de código morto (tipicamente 20-30% da base de código) e criticidade do agendamento de batch (quais jobs JCL tocam este módulo e quando).
A saída é uma sequência de extração classificada para a migração por figueira estranguladora. Os módulos com o menor acoplamento e os tipos de dados mais simples são extraídos primeiro. Os "programas-deus", chamados por mais de 50 outros módulos, são extraídos por último. Esse sequenciamento é a diferença entre uma implantação controlada e uma falha em cascata.
Nossos agentes de tradução consultam o grafo de conhecimento antes de gerar cada módulo Java, puxando o fecho transitivo completo de dependências. O agente enxerga a cláusula REDEFINES no copybook três diretórios adiante. Ele enxerga a definição de decimal compactado que determina o comportamento de arredondamento. Ele gera Java com passagem explícita de parâmetros (injeção de dependência) em vez do estado global implícito do COBOL. Em seguida, compila em um sandbox, executa testes de equivalência comportamental e se autocorrige.
Usamos o modelo de fundação que melhor se ajustar à complexidade do módulo. Para conversões simples de PERFORM-para-método, um modelo menor funciona bem. Para módulos com REDEFINES aninhados, espaguete de GOTO que exige a linearização do fluxo de controle ou lógica de transações embutida EXEC CICS, trazemos o modelo mais capaz disponível e o aumentamos com o contexto completo do grafo.
A parte que a maioria dos fornecedores pula e em que a maioria das migrações fracassa. Construímos um sistema de validação em três camadas: testes unitários simbólicos gerados a partir de caminhos de fluxo de controle derivados do grafo, replay de dataset dourado usando transações de produção capturadas e comparadas campo a campo com precisão de centavo perfeito, e execuções paralelas em produção em que ambos os sistemas processam transações ao vivo por 30-90 dias antes de o módulo do mainframe ser desativado.
Cálculos financeiros exigem BigDecimal com modo de arredondamento HALF_EVEN para corresponder à cláusula ROUNDED do COBOL. Cálculos de data exigem o tratamento do formato de data de 6 dígitos do COBOL (YYMMDD) com lógica de janelamento de século. Construímos essas regras de conversão na bancada de testes, e não em patches ad-hoc descobertos durante o QA.
Analisamos suas redes de jobs JCL, cadeias de dependência CA-7/TWS/Control-M e sequências de processamento batch no grafo de conhecimento. Cada job JCL torna-se um nó com arestas para os programas COBOL que ele executa, os datasets que ele lê e grava, e as condições de agendamento das quais ele depende (gatilhos de tempo, disponibilidade de dataset, conclusão de predecessor).
Quando um módulo COBOL migra para Java, construímos simultaneamente o agendamento equivalente na sua plataforma de orquestração de destino (Apache Airflow, AWS Step Functions, Azure Data Factory ou Control-M em ambiente distribuído). A cadeia de dependência é preservada e verificada em relação à definição CA-7/TWS original. Um banco típico de médio porte tem de 2.000 a 5.000 jobs JCL. Já vimos todos eles.
Um passo a passo de como a resolução de dependências baseada em grafo previne o padrão de falha de migração mais comum.
O parser processa PROG-WIRE-01.cbl, encontra COPY CB-ACCT-LIMITSe segue a cadeia de inclusão. Ele constrói nós de AST para cada declaração de variável, incluindo aquelas em copybooks aninhados 3 níveis abaixo.
O motor do grafo cria arestas: PROG-WIRE-01 → IMPORTA → CB-ACCT-LIMITS. TRN-LIMIT → REDEFINE → TRN-LIMIT-ALPHA. LIMIT-TYPE-FLAG → CONTROLA_O_TIPO_DE → TRN-LIMIT. Isso captura o fato de que o tipo de dados de TRN-LIMIT depende de um flag em tempo de execução em um campo diferente.
O grafo percorre para fora: quais outros programas também fazem COPY de CB-ACCT-LIMITS? Quais programas definem LIMIT-TYPE-FLAG? Quais jobs JCL executam esses programas, e em que sequência? O resultado é uma cadeia de impacto completa. Mudar como TRN-LIMIT é traduzido afeta todos os programas dessa cadeia.
Quando o agente de tradução processa PROG-WIRE-01, o GraphRAG recupera não apenas o arquivo-fonte, mas a definição do copybook, o relacionamento REDEFINES, o campo de flag e todos os programas que definem o flag. O agente gera uma classe Java com um padrão de união type-safe: um objeto TransactionLimit que verifica o flag antes de interpretar os bytes subjacentes como um BigDecimal (modo de decimal compactado) ou uma String (modo alfanumérico).
Sem o grafo: a IA assume que TRN-LIMIT é um campo numérico simples, gera um long em Java, e a primeira transferência eletrônica corrompe o banco de dados. Com o grafo: a IA enxerga a cadeia de dependência completa e gera código type-safe que trata corretamente ambas as interpretações. Esta é a diferença entre uma migração que funciona em UAT e uma que funciona em produção.
Quatro fases, cada uma com entregáveis claros. Não cotamos um prazo de 3 anos e desaparecemos. Cada fase produz artefatos que você possui e pode usar de forma independente.
Entregável: Relatório de Avaliação + protótipo preliminar de grafo de conhecimento
Entregável: Grafo de conhecimento consultável + sequência de extração classificada + ferramenta de análise de impacto
Entregável: Módulos Java migrados em produção + grafo de conhecimento atualizado + equivalentes de agendamento
Entregável: Implantação em produção validada + pacote de documentação regulatória + grafo atualizado
Responda a sete perguntas sobre o seu ambiente. A avaliação identifica o seu nível de prontidão e os bloqueadores específicos a serem resolvidos antes de iniciar um engajamento de migração, com ou sem a Veriprajna.
Para uma base de código de 2M de LOC com complexidade típica (IBM Enterprise COBOL v6.x, SQL embutido DB2, 500+ copybooks), a construção do grafo leva de 8 a 12 semanas. As primeiras 3 semanas são de configuração e validação do parser. Os dialetos COBOL variam o suficiente para que precisemos verificar se o parser lida com o seu uso específico de REDEFINES, OCCURS DEPENDING ON e blocos EXEC CICS/SQL antes de ingerir a base de código completa.
As semanas 4 a 8 são de ingestão automatizada, extração de entidades e mapeamento de relacionamentos. O parser processa aproximadamente 200K-300K linhas por dia, mas o gargalo é a resolução de entidades, especificamente determinar que ACCT-NUM no Programa A e ACCT-NUM no Copybook CB-ACCT-01 são a mesma variável.
As semanas 9 a 12 são de cálculo de fecho transitivo e validação. Executamos verificações de completude do grafo: todo alvo PERFORM deve resolver para um parágrafo, toda instrução COPY deve resolver para um copybook, toda referência a tabela DB2 deve mapear para uma definição de esquema. As lacunas são sinalizadas para revisão manual. A saída é um grafo de conhecimento consultável onde você pode fazer perguntas como "O que acontece se eu mudar INTEREST-RATE em CB-GLOBAL-01?" e obter uma cadeia de impacto completa em todos os programas que o referenciam, direta ou transitivamente.
Sim, e recomendamos fortemente. O padrão da figueira estranguladora é a única abordagem com histórico comprovado para a migração de mainframe. Reescritas completas fracassam 70-80% das vezes porque tentam substituir tudo simultaneamente, criando um único e enorme ponto de falha.
Com a abordagem da figueira estranguladora, o grafo de conhecimento identifica quais módulos têm as menores pontuações de acoplamento, ou seja, o menor número de dependências de entrada de outros módulos. Esses são os seus candidatos à extração. Normalmente começamos com módulos de relatórios batch ou rotinas de cálculo autônomas que leem do DB2, mas não atualizam o estado compartilhado. O novo serviço Java roda ao lado do mainframe. O tráfego de produção é roteado para o novo serviço para aquela função específica, enquanto o mainframe continua lidando com todo o resto. Você valida a equivalência comportamental em dados reais de produção antes de desativar o módulo COBOL.
A maioria das organizações extrai de 15 a 20 módulos no primeiro ano, reduzindo o consumo de MIPS em 20-30% e gerando economia suficiente para financiar a próxima fase. O grafo de conhecimento torna isso seguro porque mostra o raio de impacto de cada extração. Se o Módulo A é chamado por 47 outros programas, esse não é o seu primeiro candidato à extração. Se o Módulo B é chamado por 2 programas e lê de 1 tabela DB2, comece por aí.
Esta é a camada onde a maioria dos projetos de modernização sofre falhas inesperadas de 6 a 12 meses após o início. Seus programas COBOL não rodam isoladamente. Eles são orquestrados por fluxos de jobs JCL gerenciados por CA-7, TWS (Tivoli Workload Scheduler) ou Control-M. Um banco típico de médio porte tem de 2.000 a 5.000 jobs JCL com cadeias de dependência complexas: o Job A deve concluir antes de o Job B iniciar, o Job C roda apenas no último dia útil do mês, o Job D dispara uma transação CICS que atualiza um arquivo VSAM lido pelo Job E.
Analisamos o JCL junto com o COBOL no mesmo grafo de conhecimento. Cada job JCL torna-se um nó com arestas para os programas COBOL que ele executa, os datasets que ele lê e grava, e as condições de agendamento das quais ele depende. Quando migramos um módulo COBOL para Java, construímos simultaneamente o agendamento equivalente na sua plataforma de destino, seja ela Apache Airflow, AWS Step Functions ou Azure Data Factory. A cadeia de dependência é preservada e verificada em relação à original.
Já vimos projetos em que a migração de código teve êxito perfeito, mas a produção quebrou porque ninguém mapeou o job CA-7 que executava uma etapa de pré-processamento todas as noites às 2h da manhã.
O IBM Watsonx Code Assistant for Z (atualmente v2.8.20, com o Project Bob chegando ainda em 2026) é um produto forte com profunda integração de mainframe. Ele exige o IBM ADDI (Application Discovery and Delivery Intelligence) para construir sua análise de dependências, e o ADDI roda em z/OS. Isso significa que sua ferramenta de análise de dependências vive no mesmo mainframe do qual você está tentando migrar. Também significa que a IBM controla a camada de análise, o que cria dependência de fornecedor durante a fase mais crítica da migração.
Nosso grafo de conhecimento roda fora do mainframe. Ingerimos exportações de código-fonte, bibliotecas JCL, exportações do catálogo DB2 e repositórios de copybooks. O grafo vive no seu ambiente de nuvem ou infraestrutura on-premises, independente do licenciamento da IBM. Segundo, o Watsonx foca na tradução de COBOL para Java. Nós focamos primeiro no entendimento, depois na tradução. O grafo de conhecimento é um ativo permanente que serve à análise de impacto, à geração de documentação e à governança arquitetural muito depois de a migração estar concluída.
Terceiro, o parser COBOL do ADDI tem limitações documentadas com construções COBOL pré-85, particularmente instruções ALTER e certos padrões de REDEFINES aninhados. Construímos extensões customizadas de parser para o dialeto de cada cliente.
Por fim, o preço da IBM mira em grandes corporações. Nosso modelo de engajamento funciona para instituições de médio porte onde um engajamento IBM de US$ 2M+ não cabe no orçamento.
A equivalência comportamental é onde a maioria das migrações assistidas por IA desmorona. Código que compila e passa nos testes unitários ainda pode produzir resultados errados por causa de diferenças no arredondamento de decimal compactado, incompatibilidades de codificação EBCDIC-para-ASCII ou semântica de sobreposição de memória REDEFINES que não se traduz para objetos Java.
Construímos uma bancada de validação em três camadas. A Camada 1 é a equivalência simbólica: geramos testes unitários a partir do grafo de conhecimento que cobrem cada ramificação no fluxo de controle original do COBOL, incluindo casos extremos como valores negativos, proteções contra divisão por zero e cálculos de data de ano bissexto. A Camada 2 é o replay de dataset dourado: capturamos um conjunto representativo de transações de produção do mainframe (registros de entrada, leituras DB2, interações CICS) e as reproduzimos no novo serviço Java. As saídas são comparadas campo a campo. Para cálculos financeiros, verificamos a precisão de centavo perfeito usando BigDecimal com arredondamento HALF_EVEN para corresponder ao comportamento da cláusula ROUNDED do COBOL.
A Camada 3 é a execução paralela em produção: ambos os sistemas processam as mesmas transações ao vivo simultaneamente por 30 a 90 dias. As discrepâncias são registradas, investigadas e corrigidas antes de o módulo do mainframe ser desativado. Esta é a fase mais longa, mas é também a fase que captura os casos extremos acumulados ao longo de 30 anos de produção que nenhuma suíte de testes consegue antecipar plenamente.
A DORA (Digital Operational Resilience Act) está plenamente em vigor desde 17 de janeiro de 2025, e impacta diretamente qualquer entidade financeira regulada na UE que opere sistemas de mainframe. O Artigo 11 exige frameworks de gestão de riscos de TIC que incluam testes regulares de resiliência e testes de penetração liderados por ameaças com base em cenários de ataque do mundo real. A maioria dos ambientes de mainframe não foi projetada para esse tipo de teste. Você não pode facilmente subir um ambiente z/OS réplica para executar testes de penetração sem custos significativos de licenciamento e infraestrutura.
A DORA também exige inventários detalhados de ativos de TIC, comunicação de incidentes dentro de prazos específicos e gestão de riscos de terceiros para provedores críticos de serviços de TIC, o que inclui o seu fornecedor de mainframe. A modernização ajuda de duas maneiras. Primeiro, o próprio grafo de conhecimento serve como o inventário de ativos de TIC que a DORA exige. Ele mapeia cada programa, cada fluxo de dados, cada dependência externa. Os reguladores podem consultá-lo diretamente.
Segundo, os componentes migrados que rodam em infraestrutura de nuvem são inerentemente mais fáceis de testar quanto à resiliência. Você pode subir ambientes de teste sob demanda, executar cenários de engenharia do caos e validar procedimentos de recuperação sem afetar a produção. Já vimos instituições usarem o grafo de conhecimento como evidência em exames regulatórios para demonstrar que compreendem seu patrimônio tecnológico, mesmo antes de a migração estar concluída.
A metodologia por trás desta página de solução está fundamentada em nossa pesquisa publicada sobre modernização de sistemas legados e arquiteturas de grafos de conhecimento.
Como grafos de conhecimento cientes do repositório e o GraphRAG superam a síndrome do "Lost in the Middle" que faz a tradução de código por IA fracassar em sistemas COBOL corporativos.
Uma redução de 20-30% de MIPS no Ano 1 normalmente economiza de US$ 500K a US$ 2M anualmente para uma instituição de médio porte.
A avaliação do grafo de conhecimento leva de 4 a 6 semanas. Você recebe um mapa completo de dependências da sua base de código, um relatório de código morto e uma sequência de extração classificada, prosseguindo com a migração ou não. A avaliação em si é um ativo permanente.