Insights · Modernização de legado

Falta de desenvolvedor COBOL, Delphi e VB6: o que fazer com o sistema legado

Publicado em 15 de outubro de 2026

A falta de desenvolvedor COBOL, Delphi e VB6 é o descompasso entre sistemas que seguem em produção nessas tecnologias e o número cada vez menor de pessoas capazes de mantê-los. O risco maior não é a linguagem em si: é a regra de negócio que só existe no código e na cabeça de poucas pessoas. Quando uma delas sai, a empresa perde a capacidade de mudar o sistema com segurança, mesmo que ele continue rodando. Este texto explica por que a escassez acontece, que riscos ela cria e quais são as opções, de contratar a modernizar por partes.

O que é um sistema legado e os sinais de risco mais comuns estão em Sistema legado: o que é, sinais de risco e quando modernizar. O passo a passo da modernização, em Como modernizar um sistema legado: guia passo a passo. A conta da dívida, em Custo da dívida técnica: quanto a empresa paga, e como estimar. O nível de maturidade da organização, em Maturidade em modernização de legado: 4 níveis e autodiagnóstico. A diferença entre migrar e modernizar, em Lift and shift vs modernização: o que muda de verdade. Aqui o foco é só: o que fazer quando falta gente para manter o sistema.

Por que falta desenvolvedor COBOL, Delphi e VB6

Três movimentos se somam: pouca gente nova entra, quem sabe vai saindo e a tecnologia em volta envelhece em ritmos diferentes.

Pouca gente nova entra. Na Stack Overflow Developer Survey 2026, 1,1% de quem respondeu à pergunta sobre linguagens (150 de 14.099 pessoas) disse ter trabalhado bastante com COBOL no último ano. O Delphi ficou em 1,9% (267 pessoas). Para comparar, Python ficou em 58,0%. É uma pesquisa online, global, com amostra autosselecionada pelo público do Stack Overflow; não mede o mercado brasileiro nem o total de profissionais. Mostra só que essas linguagens estão longe do dia a dia da maioria de quem programa. O VB6 nem aparece como opção: o Visual Basic da lista é o .NET, outra plataforma.

O guia público The Code Modernization Playbook, da Anthropic (fornecedor de modelos de IA para esse tipo de trabalho), descreve o mesmo movimento: quem se forma hoje aprende linguagens e arquiteturas atuais, e as vagas que pedem as antigas ficam cada vez mais difíceis de preencher. É a visão de um fornecedor, não pesquisa.

Quem sabe vai saindo. Aposentadoria, troca de emprego, mudança de área. Em 2018, o escritório do Inspetor-Geral da Previdência Social dos EUA (SSA) informou ao Congresso que a agência mantinha mais de 60 milhões de linhas de COBOL nos sistemas que processam aposentadorias e benefícios por incapacidade, e que, com a rotatividade, o conhecimento dos funcionários sobre as tecnologias antigas, e a capacidade de trabalhar com elas, diminui. Em 2025, o GAO, órgão de auditoria do Congresso americano, escreveu que COBOL e assembly têm um número cada vez menor de pessoas com as habilidades necessárias para mantê-los. São casos do governo americano, que publica esses dados; não encontramos número público equivalente para empresas no Brasil.

A tecnologia em volta envelhece em ritmos diferentes. As três linguagens não estão na mesma situação:

COBOL segue rodando em sistemas centrais, como os da Previdência Social americana (SSA) e os do Tesouro americano citados pelo GAO. O gargalo é gente que entenda aquele código específico.
Delphi segue com empresa por trás e versões novas: a Embarcadero lançou o Delphi 13 em 10 de setembro de 2025. Na nossa leitura, o risco está menos na linguagem e mais no projeto parado numa versão antiga, com componentes de terceiros sem manutenção, e no conhecimento concentrado em quem o escreveu.
VB6 perdeu o suporte ao ambiente de desenvolvimento em 8 de abril de 2008, e a Microsoft recomenda substituir as aplicações por tecnologia atual. O runtime continua suportado nas versões de Windows com suporte, mas só para regressões graves e falhas críticas de segurança, e só em 32 bits.

Os riscos práticos para quem tem sistema legado

A falta de gente nem sempre derruba o sistema. Ela aparece em cinco riscos, que se reforçam:

Conhecimento concentrado em poucas pessoas. Se só uma ou duas pessoas sabem por que um cálculo arredonda daquele jeito, a saída de uma delas vira risco operacional. O GAO registra que a falta de especialistas para manter um sistema crítico cria risco significativo para a missão das agências.
Documentação ausente ou desatualizada. A regra mudou dezenas de vezes no código e o documento ficou parado. O playbook da Anthropic descreve o padrão: a documentação se perde com a rotatividade, e a regra crítica fica presa em código que poucos entendem e menos ainda conseguem mudar com segurança (visão de fornecedor).
Cada mudança custa mais. Segundo o GAO, as agências têm dificuldade de encontrar quem conheça essas tecnologias e podem precisar pagar mais caro por especialistas ou terceirizados.
Mudança urgente sem gente para fazer. Em abril de 2020, com a alta dos pedidos de seguro-desemprego na pandemia, o governador de Nova Jersey pediu voluntários com conhecimento de COBOL, e outros estados fizeram o mesmo, segundo o Open Mainframe Project, da Linux Foundation, que abriu um fórum para ligar esses profissionais, inclusive aposentados, a quem precisava. O sistema funcionava; o problema era mudá-lo rápido.
Medo de tocar o núcleo. Sem testes e sem quem entenda o desenho, o time evita mexer e empilha contornos. Cada contorno aumenta a dependência de quem conhece o sistema. Onde esse custo aparece e como estimá-lo está em custo da dívida técnica.

As opções, lado a lado

Não existe resposta única. As opções abaixo resolvem problemas diferentes e podem ser combinadas:

Opção	O que resolve	O que não resolve	Quando faz sentido
Contratar especialista	Capacidade imediata para manter e corrigir	A oferta é menor e mais cara (GAO); o conhecimento continua concentrado, só muda de pessoa	Sistema estável, com pouca mudança prevista
Treinar gente da casa	Quem já conhece o negócio aprende a linguagem	Leva tempo até a fluência naquele sistema; não documenta a regra; quem aprende também pode sair	Junto com documentação e testes, nunca como aposta única
Terceirizar a manutenção	Tira a fila de chamados de dentro de casa	O conhecimento passa a morar no fornecedor; a dependência muda de endereço	Quando o contrato exige documentar as regras, escrever testes e transferir conhecimento
Mudar de servidor ou ir para a nuvem	Custo e operação da infraestrutura	Não cria especialista nem documenta regra; o código continua o mesmo	Prazo para sair do datacenter, com plano para o que vem depois
Modernizar por partes	Leva a regra para código atual, com testes, e reduz a dependência de poucas pessoas	Exige inventário, tempo do especialista para conferir e critério escrito para cada troca	Sistema que ainda precisa mudar, com regra crítica e poucas pessoas que o entendem

Uma combinação possível: manter um especialista, contratado ou terceirizado, para o dia a dia, enquanto as partes de maior risco são documentadas e modernizadas uma de cada vez. Mudar de servidor muda onde o sistema roda, não quem o entende; a comparação completa está em lift and shift vs modernização.

Para migrar Delphi ou VB6, vale o mesmo critério: trocar a linguagem sem antes registrar a regra só transfere o problema para um código novo que ninguém conferiu.

Antes de qualquer opção: tirar a regra da cabeça das pessoas

Seja qual for o caminho, o primeiro passo é o mesmo, e tem prazo: o tempo que os especialistas de hoje ainda ficam.

Inventário. O que o sistema faz para o negócio, quem depende de cada função, onde estão as regras e o que ninguém usa mais. O roteiro está no passo 1 do guia de modernização.
Regras escritas a partir do código e conferidas por quem opera. Uma regra encontrada no código pode ser um bug que virou funcionalidade; só quem conhece a operação sabe a diferença.
Testes de caracterização nas partes críticas. Eles registram o que o sistema faz hoje, certo ou errado, para que qualquer mudança futura seja conferida contra esse comportamento.
Mapa de dependências. Arquivos, tabelas, rotinas agendadas e outros sistemas que conversam com o legado.
Mapa de quem sabe o quê. Quais partes dependem de uma pessoa só. É por ali que a documentação deve começar e, se fizer sentido, a modernização também.

Isso vale mesmo se a decisão for manter o sistema como está por mais alguns anos: documentação e testes reduzem a dependência de qualquer pessoa, inclusive de um fornecedor. Se a organização só olha para o legado quando um especialista anuncia a saída, o autodiagnóstico de maturidade ajuda a situar o ponto de partida.

Onde entram os agentes de código

Agentes de código podem baratear essa etapa. Eles leem o sistema inteiro, mapeiam dependências, propõem a descrição das regras de negócio e escrevem testes de caracterização, e podem fazer isso mais rápido do que uma pessoa lendo programa por programa. O playbook da Anthropic (visão de fornecedor) aponta esse uso: extrair do código o conhecimento institucional, gerar documentação compreensível e apoiar a migração com testes.

O ganho principal está no papel do especialista. Em vez de ser o único que escreve e corrige, ele passa a conferir: o agente propõe, quem conhece o sistema confirma, corrige ou descarta. A hora escassa vai para o que só essa pessoa sabe fazer. O desenho que a Ithaca usa:

Supervisão: pessoas do time do cliente, inclusive quem conhece o legado, definem os limites dos agentes e leem o que vai para produção. É o nível 4 da escala de autonomia de agentes de código proposta por Dan Shapiro, e não um modo em que o código vai para produção sem que ninguém o leia.
Rastreabilidade: cada sessão deixa registro de pedido, passos, modelo, custo, resultado e autoria. Quando uma regra extraída vira documentação ou código novo, dá para saber de onde ela veio e quem a aprovou.
A plataforma de desenvolvimento agentic é implantada lado a lado com o seu time; o método para sistemas que não podem parar está em Modernização de sistemas legados com IA, sem parar a operação.

Um começo possível: escolher o módulo que depende de uma pessoa só, documentar as regras e cobri-lo com testes de caracterização, e então construir a parte nova ao lado, com o especialista conferindo cada passo.

Agendar demonstração

Perguntas frequentes

Por que está faltando desenvolvedor COBOL?

Porque pouca gente nova aprende a linguagem e quem a domina vai saindo do mercado, enquanto sistemas centrais seguem em produção. Em 2025, o GAO, órgão de auditoria do Congresso dos EUA, escreveu que COBOL e assembly têm cada vez menos pessoas com as habilidades para mantê-los. Na Stack Overflow Developer Survey 2026, 1,1% dos respondentes (150 de 14.099) disseram ter trabalhado bastante com COBOL no último ano.

Delphi e VB6 ainda têm suporte?

As situações são diferentes. O Delphi segue com empresa por trás e versões novas: a Embarcadero lançou o Delphi 13 em setembro de 2025. O VB6 não: a Microsoft encerrou o suporte ao ambiente de desenvolvimento em 2008 e recomenda substituir as aplicações; o runtime segue suportado nas versões de Windows com suporte, só para regressões graves e falhas críticas de segurança, e só em 32 bits.

Contratar ou terceirizar resolve a falta de especialista?

Resolve o curto prazo. Contratar fica mais caro quando a oferta é pequena, e o conhecimento continua concentrado em poucas pessoas. Terceirizar leva a dependência para o fornecedor. As duas opções funcionam melhor junto com documentação das regras, testes de caracterização e um plano para modernizar as partes de maior risco.

Levar o sistema para a nuvem resolve a falta de desenvolvedor?

Não. Trocar a hospedagem, a rede ou o firewall muda custo e operação de infraestrutura, mas o código continua em COBOL, Delphi ou VB6 e continua dependendo das mesmas pessoas. A diferença entre migrar e modernizar está em lift and shift vs modernização.

Agentes de código substituem o especialista em COBOL ou Delphi?

Não. Eles leem o código, propõem a descrição das regras e escrevem testes e a parte nova; quem conhece o sistema confere e decide. O que muda é o uso do tempo do especialista: menos escrita e correção, mais conferência. Na Ithaca, pessoas do time do cliente leem o que vai para produção e cada sessão fica registrada.

Fontes

GAO (U.S. Government Accountability Office), "Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems", GAO-25-107795, 17/07/2025 (relatório de auditoria do governo dos EUA; acessado em 15/10/2026). https://files.gao.gov/reports/GAO-25-107795/index.html (COBOL e assembly com cada vez menos pessoas habilitadas; dificuldade de contratar e custo maior com especialistas ou terceirizados; falta de especialistas como risco à missão).
Social Security Administration, Office of the Inspector General, "The State of Social Security's Information Technology", depoimento ao Congresso, 27/09/2018 (governo dos EUA; acessado em 15/10/2026). https://oig.ssa.gov/congressional-testimony/2018-09-27-newsroom-congressional-testimony-sep27-it-modernization/ (mais de 60 milhões de linhas de COBOL na SSA em 2018; perda de conhecimento com a rotatividade).
Stack Overflow, "Developer Survey 2026", linguagens (pesquisa online, amostra autosselecionada; n = 14.099 respondentes da pergunta; acessado em 15/10/2026). https://survey.stackoverflow.co/2026/technology/data/languages (COBOL 1,1%, 150 pessoas; Delphi 1,9%, 267; Python 58,0%; pergunta sobre trabalho extenso no último ano).
Microsoft, "Visual Basic 6.0 Support Announcement" (Microsoft Lifecycle) e "Support Statement for Visual Basic 6.0" (documentação oficial da Microsoft; acessado em 15/10/2026). https://learn.microsoft.com/en-us/lifecycle/announcements/visual-basic-6-support-announcement · https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/visual-basic-6-support-policy (IDE sem suporte desde 08/04/2008; recomendação de substituir; runtime só para regressões graves e falhas críticas de segurança, em 32 bits).
Embarcadero, "RAD Studio 13 Released", 10/09/2025 (comunicado oficial da Embarcadero; acessado em 15/10/2026). https://www.embarcadero.com/press-releases/rad-studio-13-released (lançamento do Delphi 13).
Open Mainframe Project (Linux Foundation), "Open Mainframe Project helps fill the need for COBOL resources", 09/04/2020 (acessado em 15/10/2026). https://openmainframeproject.org/blog/open-mainframe-project-helps-fill-the-need-for-cobol-resources/ (pedido de voluntários com COBOL em Nova Jersey e outros estados; fórum para profissionais, inclusive aposentados).
Anthropic, "The Code Modernization Playbook" (material de fornecedor, sem data no documento; Cap. 1 e Cap. 4; acessado em 15/10/2026). https://resources.anthropic.com/code-modernization-download (escassez de profissionais em linguagens antigas; documentação perdida com a rotatividade; uso de agentes para extrair conhecimento do código, documentar e testar; visão de fornecedor).