A PROCERGS queria desligar o mainframe. O COBOL ficou. E o mainframe também.
Em 2009, a PROCERGS, empresa de tecnologia do governo do Rio Grande do Sul, tinha uma parte importante de seus sistemas rodando em um mainframe Unisys. Eram cerca de 2,3 milhões de linhas de código COBOL, segundo as informações divulgadas na época.
De acordo com a cobertura daquele período, a manutenção desses sistemas no Unisys representava um custo de aproximadamente R$ 10 milhões por ano para o Estado. O então presidente da PROCERGS, Ronei Ferrigolo, associava esse custo à dependência tecnológica de uma plataforma proprietária.
A solução parecia clara: desligar aquela plataforma e aproveitar a oportunidade para substituir a linguagem e reconstruir os sistemas em uma nova arquitetura.
Naquele momento, modernizar significava, muitas vezes, migrar para Java ou .NET. Uma estimativa inicial projetava um investimento de aproximadamente R$ 30 milhões para isso.
O valor, por si só, talvez nem inviabilizasse o projeto diante dos custos atribuídos à dependência da Unisys. Mas havia uma alternativa muito mais barata para atingir o objetivo imediato.
O COBOL poderia ficar
Mantendo o COBOL e automatizando cerca de 90% da conversão para Micro Focus, a migração para plataforma baixa foi orçada em aproximadamente R$ 3,4 milhões.
A PROCERGS poderia atacar primeiro o problema que motivava o projeto — a dependência da plataforma Unisys — sem assumir naquele momento o custo e o risco de reescrever milhões de linhas em outra linguagem. Java e .NET continuavam sendo considerados como uma possível etapa posterior.
Em março de 2010, a CPS Consultoria venceu a disputa por aproximadamente R$ 3,4 milhões.
A diferença em relação aos R$ 30 milhões estimados para Java/.NET ajuda a entender a mudança de estratégia, mas as fontes disponíveis não permitem afirmar que os dois valores correspondiam exatamente ao mesmo escopo.
Não bastava recompilar COBOL
A PROCERGS trabalhava com a família Unisys ClearPath/MCP. Documentação da própria empresa mostra um ecossistema formado por COBOL Unisys, DMS II, COMS, WFL e CANDE.
Portanto, não se tratava simplesmente de recompilar alguns milhões de linhas de COBOL para outro servidor. Os sistemas estavam inseridos em um ecossistema proprietário. A migração precisava lidar com diferenças do dialeto COBOL, banco de dados, processamento, comunicação e outras dependências da plataforma.
Mais de quinze anos depois, a discussão continua extremamente atual.
Replatform ou rewrite?
Hoje usamos termos como rehost, replatform, refactor e rewrite para distinguir estratégias de modernização que frequentemente aparecem nas RFPs. A PROCERGS estava, essencialmente, diante dessa mesma escolha.
A opção mais conservadora: sair do Unisys, mas preservar a lógica das aplicações, convertendo o código para Micro Focus COBOL e executando-o na nova plataforma. A própria direção dizia que a mudança de linguagem poderia ocorrer posteriormente. A diferença estava na ordem das coisas. Primeiro, retirar a dependência da plataforma. Depois, decidir o que realmente precisava ser reescrito.
Linguagem, plataforma e arquitetura são problemas relacionados, mas não são o mesmo problema.
Deu certo?
O contrato de 2010 não representou o desligamento do Unisys. Em 2024, a empresa ainda relacionava a “Desativação/Migração mainframe Unisys” entre seus projetos estratégicos. No Relatório Integrado de Gestão de 2025, finalmente, a migração aparece como concluída.
Mas o Unisys certamente chegou vivo até 2025. Registros oficiais mostram pagamentos à Unisys Brasil descritos como “Clear Path – Suporte Técnico Software”, em julho, e “ClearPath MCP – Locação de Equip.”, em agosto. É possível que esses registros sejam anteriores à efetiva conclusão da migração. Vamos ver o que dirá o relatório de gestão de 2026.
Também não sabemos, pelas informações públicas disponíveis, quais aplicações foram efetivamente convertidas para Micro Focus COBOL em 2010, quanto daquele ambiente permaneceu por necessidade técnica ou quanto do escopo original foi alterado posteriormente. Seria precipitado concluir que o projeto fracassou.
Mas a longa sobrevivência do Unisys ilustra um fenômeno que vi acontecer muitas vezes ao longo da minha carreira.
Sistemas legados raramente são apenas milhões de linhas esperando para serem traduzidas. Ao longo de décadas, acumulam regras de negócio, dados históricos, interfaces, rotinas batch, exceções operacionais e dependências que nem sempre são completamente conhecidas quando o projeto começa.
Os cronogramas se alongam, o escopo muda e, SMP atrás de SMP, logo surge a sensação de que o poço não tem fundo.
De um lado, o cliente acredita na viabilidade do projeto, pressionado por metas de redução de custos, modernização tecnológica e time to market. Do outro, fornecedores enxergam uma oportunidade grande demais para deixar passar. Premissas otimistas viram compromissos, riscos são empurrados para as próximas fases e aquilo que começou como incerteza técnica acaba transformado em novas versões de cronograma, proposta e preço.
Na área de tecnologia costumamos chamar isso, elegantemente, de “risco calculado”.
E o resultado quase sempre é o mesmo.
Conclusão
Algumas funções são migradas. Outras se revelam mais complexas do que o previsto. Interfaces precisam ser mantidas. Dados históricos permanecem no ambiente antigo. Alguns processos simplesmente não justificam economicamente a conversão.
Aquilo que havia sido planejado como substituição acaba se transformando em coexistência.
O sistema novo assume parte do workload, enquanto o legado continua processando aquilo que ainda não foi — ou talvez nem valha a pena ser — migrado.
Já vi essa história começar muitas vezes com um objetivo inequívoco: desligar o mainframe. Alguns anos depois, a apresentação executiva muda. Já não se fala tanto em substituição, mas em coexistência, arquitetura híbrida, modernização progressiva ou preservação estratégica de determinados workloads.
O mainframe não permanece necessariamente por resistência à mudança, porque o COBOL seja impossível de substituir ou porque a tecnologia nova tenha fracassado. Muitas vezes ele permanece porque, depois de gastar tempo e dinheiro tentando substituí-lo, a empresa descobre quanto daquele “legado” era, na verdade, o seu próprio negócio acumulado durante décadas.
Eu poderia passar o resto da vida escrevendo artigos sobre projetos em que isso aconteceu.
Talvez escreva alguns.
