Seu core em COBOL sustenta o negócio — e cada vez menos gente sabe mexer.
Mantemos, integramos e migramos aplicações COBOL, JCL, CICS e DB2 — para Java ou .NET, quando fizer sentido, sem parar a operação.
Manter ou migrar, você decide. Comece por um diagnóstico.
O mainframe roda. O problema é quem vai manter amanhã.
Quem ainda depende de COBOL — e por quê não sai.
COBOL não é legado por preguiça: é legado porque funciona, processa volume absurdo e a reescrita é cara. O problema é a dependência, não a tecnologia.
Você escolhe o caminho — e não precisa decidir hoje.
Estabilizamos o que está no ar e migramos quando o negócio mandar.
Mantenha o core no ar
- Manutenção do batch JCL e do online CICS
- Análise de dump ABEND e correção de incidentes
- Documentação das regras de negócio enterradas no código
- Tuning de DB2: planos de acesso, índices, reorganização
- Bridge para canais digitais via API (REST sobre o core)
Saia do mainframe, no seu ritmo
- COBOL/CICS → Java Spring Boot ou .NET
- DB2/VSAM/IMS → PostgreSQL, Oracle ou SQL Server
- Batch JCL → scheduler moderno (Quartz, Spring Batch)
- Equivalência funcional comprovada, rollback a cada etapa
- Strangler Fig: módulo por módulo, legado no ar até o fim
O que torna COBOL diferente de qualquer outra migração.
Não é o volume de código — é o que o código assume que você já sabe e nunca documenta.
COMP-3 → BigDecimal: o erro de centavo que aparece meses depois
COBOL faz aritmética decimal exata com COMP-3 (packed decimal). Java não tem equivalente nativo. A conversão automática mapeia para double ou float, que têm erro de representação em ponto flutuante. Resultado: centavo de diferença por transação, que acumula por milhares de operações e aparece semanas depois num relatório de conciliação que ninguém consegue explicar.
JCL com dependências invisíveis: o mapa que não existe em lugar nenhum
Jobs de batch se chamam por nome de DATASET e de STEP, não por referência de código. Não há declaração de dependência — o scheduler (TWS, CA7) é quem sabe a ordem. Se você não tem o scheduler mapeado, qualquer alteração em nome de arquivo, em passo de job ou em catálogo pode quebrar uma cadeia inteira de forma silenciosa, só descoberta no dia seguinte quando o fechamento não fecha.
Como resolvemos: auditoria completa do JCL antes de qualquer mudança. Mapeamos o grafo de dependências e geramos documentação como artefato do diagnóstico.VSAM não é só um arquivo: é uma estrutura de acesso com semântica própria
KSDS, ESDS e RRDS têm semântica de acesso diferente — chave primária alternada, acesso sequencial com entrada relativa, registros de tamanho variável. Migrar o dado para SQL é relativamente simples. O problema é que o código COBOL usa essas semânticas diretamente e a lógica de acesso precisa ser redesenhada, não só traduzida.
Como resolvemos: mapeamento de cada VSAM por tipo de acesso, com equivalente SQL proposto e testes de equivalência funcional linha a linha.A bridge REST sobre CICS: onde 80% das integrações fracassam
O canal digital quer uma API REST que responde em menos de 500ms. O CICS processa transações que alocam recursos, fazem locks de banco e às vezes chamam módulos em batch. Colocar HTTP na frente de CICS sem entender o modelo de transação do CICS gera deadlock, timeout e inconsistência. A camada de tradução não é só protocolo — é gestão de contexto transacional.
Como resolvemos: wrapper REST com gestão de contexto transacional explícita, circuit breaker para falha do mainframe e fallback documentado para cada operação crítica.Segundo o relatório Kyndryl 2025, 70% das empresas não encontram profissionais com perfil híbrido (legado + moderno) e 74% recorrem a terceiros especializados. O problema não é falta de vontade de migrar — é falta de quem saiba fazer.
Sem parar a operação. Sem big-bang.
Rede de testes antes de mexer, migração módulo a módulo e rollback disponível em cada etapa.
1. Diagnóstico
Lemos o sistema, mapeamos o JCL, auditamos os VSAM e recomendamos manter ou migrar — com risco e custo estimados por módulo.
2. Rede de testes
Capturamos o comportamento atual (inputs/outputs reais) para proteger contra regressão. Nada muda antes dessa rede existir.
3. Execução
Sustentamos por chamado ou migramos módulo a módulo com o legado no ar. Cada módulo novo passa pela rede de testes antes de virar a chave.
4. Entrega
Código e documentação no seu repositório, runbook de operação e plano de rollback testado. Sem dependência de nós para operar.
Entregáveis que ficam com você.
Dúvidas comuns
Sim, e é o que a maioria precisa primeiro. Estabilizar, documentar e garantir continuidade já resolve 80% do problema. Migrar vem quando fizer sentido de negócio.
Acesso ao ambiente (mesmo que via emulador 3270 ou terminal TSO) é necessário para diagnóstico e execução. Todos os acessos são auditados e documentados. Trabalhamos com os controles de segurança que você já tem.
Não. A estratégia Strangler Fig mantém o batch original rodando enquanto o novo é construído e testado em paralelo. A virada de chave por módulo só acontece após a rede de testes estar verde.
É o ponto mais crítico e cuidamos com protocolo próprio: BigDecimal com arredondamento HALF_EVEN (que espelha o ROUNDED do COBOL) e rodagem paralela do sistema antigo e novo com o mesmo lote antes de qualquer corte. Centavo a centavo, antes de virar a chave.
Sim. Código COBOL é legível mesmo sem comentários — a estrutura de divisões e parágrafos é declarativa. Extraímos regras de negócio diretamente do código e do comportamento do sistema em execução.
Seus. Entregamos no repositório que você indicar, com documentação. Sem fidelidade contratual mínima e sem lock-in técnico — você pode contratar qualquer equipe no futuro para continuar o trabalho.
Tire o risco do seu mainframe da mesa.
Comece por um diagnóstico. Sem reunião de trabalho, sem compromisso.