Core Legado em COBOL vs. Nativo em Nuvem: A Matemática do Custo para CTOs em 2026

Justificar um orçamento de migração de core bancário para uma diretoria focada em EBITDA é, provavelmente, a reunião mais difícil que um CTO de banco médio enfrenta em 2026. O argumento "o sistema é antigo" não cola mais. O Mainframe IBM z16 atualizado processa transações com uma eficiência energética e velocidade de bruta dificilmente contestáveis por uma arquitetura malfeita em nuvem. O problema não é o que o mainframe faz, é o que ele impede que você faça.

O erro mais comum nas planilhas de TCO (Custo Total de Propriedade) apresentadas ao board é comparar apenas o custo de hospedagem e licenciamento. Isso é uma falácia contábil. Em 2026, o custo real de um sistema legado em COBOL mede-se na velocidade com que seu banco perde mercado para neobanks que conseguem lançar um novo produto em duas semanas. O custo de ownership diverge silenciosamente em três vetores que raramente aparecem na mesma linha do Excel: manutenção especializada, velocidade de lançamento (time-to-market) e a rigidez de escala.

O imposto da escassez técnica na manutenção

Manter um sistema COBOL funcional hoje tem um preço que vai muito além da licença de software. Estamos falando de uma crise de mão de obra que se aprofundou nos últimos três anos. Um desenvolvedor Java sênior ou especialista em Go/Golang com experiência em fintech custa, na média do mercado de São Paulo, entre R$ 18.000 e R$ 26.000 mensais. Um consultor COBOL sênior com conhecimento profundo do sistema específico do seu banco? As diárias passaram dos R$ 1.500, o que empurra o mensal para cima de R$ 35.000 a R$ 45.000, quando você consegue encontrar alguém.

A especificidade aqui é cruel: você não está pagando apenas pelo código, está pagando pelo "conhecimento tribal". O programador que sabe por que a conta 401.01 não pode atualizar no dia 30 é um ativo refém. Quando essa pessoa sai (ou se aposenta), o risco operacional dispara. Além disso, a manutenção corretiva é lenta. Corrigir uma vulnerabilidade em um monolito de 30 milhões de linhas de código exige testes de regressão que duram semanas, pois o impacto colateral é imprevisível. Em um core nativo em nuvem, baseado em microsserviços, uma correção de segurança em um módulo de "cadastro" não afeta o módulo de "processamento de pagamentos", reduzindo o janela de risco de semanas para horas.

Velocidade de lançamento: o fator que mata o lucro

Este é o ponto onde a matemática do mainframe falha. Em 2026, o mercado exige produtos hipersonderizados. Se o departamento de produtos quer lançar uma conta digital focada em criptomoedas para a Geração Z com regras de alavancagem específicas, o caminho no legado é árduo.

Geralmente, é necessário alterar tabelas DB2 que são compartilhadas por todo o banco, criar novos "batches" noturnos para processar essas regras e, quase sempre, criar um "wrapper" em uma camada mais moderna (Java ou .NET) só para traduzir o JSON do aplicativo para o formato fixo do COBOL. Esse processo, em uma instituição tradicional, leva de 4 a 6 meses. Enquanto isso, um concorrente usando Banking-as-a-Service (BaaS) sobre um core cloud-native configura o produto via API em 10 dias e começa a faturar.

O custo dessa lentidão é a perda de market share. Se você leva seis meses para lançar um recurso que seu concorrente lançou em duas, você não perdeu apenas o lucro desse período, você perdeu o mindshare do cliente. O usuário que migrou para o app do concorrente para pegar o recurso novo raramente volta. A imobilidade técnica do legado transforma-se em imobilidade comercial.

Escalabilidade: o medo do pico de transações

Na nuvem, escalabilidade elástica é commodity. Se o seu banco vai fazer uma campanha de Black Friday ou pagar o 13º salário da Bolsa Família, você provisiona mais contêineres Kubernetes, paga pelo uso por hora e desliga tudo depois. No modelo mainframe, o jogo é diferente.

A escalabilidade vertical (comprar mais MIPS — Milhões de Instruções Por Segundo) é cara e "frágil". Você contrata capacidade de pico baseada em uma previsão de crescimento, e essa capacidade fica ociosa nos meses de baixa. O problema é que a previsão de pico em 2026 ficou mais volátil. Virais nas redes sociais podem derrubar a aplicação de um banco médio se o rate limiter não estiver perfeitamente sintonizado. Num mainframe, um pico inesperado pode travar o processamento de toda a instituição (caixa, cartão, pix). Em arquiteturas cloud, bem desenhadas, a falha em um microsserviço de "onboarding" não derruba o serviço de PIX.

O custo financeiro de "overprovisioning" (superdimensionar) o mainframe para evitar queda na Black Friday é um desperdício de milhões de reais anuais em capacidade que dorme. É como manter uma usina termelétrica ligada o ano todo só para atender a demanda de três dias no verão.

O dilema da migração: "Strangler Fig" é o único caminho viável

Se eu tivesse que dar minha recomendação hoje para um CTO de banco digital ou médio porte, seria: mantenha o COBOL apenas como livro razão estático e comece a estrangular o resto do sistema. Não tente um "big bang" (substituir tudo de uma vez). Esse é o caminho para o desastre e para o headline no jornal: "Banco X clients transactions fail after migration".

A abordagem do "Strangler Fig" (figueira estranguladora) envolve construir novas capacidades no core nativo em nuvem. Toda nova funcionalidade (novo tipo de conta, novo produto de crédito, integração com Open Banking) vai para o mundo novo. O legado fica lá, servindo apenas o que já existe, sem ser mexido. Aos poucos, você migra os dados e os processos antigos para a nova arquitetura, módulo por módulo. Em 18 a 24 meses, você tem um banco operando majoritariamente em nuvem, com a resiliência e a velocidade que o mercado de 2026 exige, mantendo o legado apenas como um banco de dados de leitura eventual.

A divergência de custo de ownership não está na primeira fatura da nuvem (que vai parecer alta se você comparar linha a linha com o aluguel do mainframe já depreciado). O prejuízo do legado é invisível no financeiro, mas gritante no estratégico: é o produto que não saiu, a geração Z que não se cadastrou e a vulnerabilidade que não foi corrigida a tempo. Em 2026, quem segura o mainforce por economia, está queimando o futuro para pagar o passado.