O que é um sistema legado em TI: significado, exemplos e o que o caracteriza

Nenhum sinal isolado caracteriza. A combinação de três ou mais, sim.

Idade sozinha não define, mas fim de suporte define. Os casos abaixo aparecem com frequência em diagnóstico:

• Desktop em Delphi, Visual Basic 6, Clipper ou FoxPro — funcionam, mas dependem de componentes e bancos que saíram de suporte há anos.
• Base em Access sustentando processo crítico — passa a travar quando o volume ou o número de usuários simultâneos cresce.
• Portal público ou intranet em PHP ou Java antigos — versão de framework sem correção de segurança, muitas vezes exposta na internet.
• ERP com customização pesada — o núcleo é suportado, mas as customizações e integrações em volta não acompanham as atualizações.
• Planilha com macro sustentando um processo — sem controle de versão, sem registro de quem alterou o quê, sem teste.
• COBOL e mainframe — a IBM estima cerca de 250 bilhões de linhas de COBOL em produção; um levantamento independente encomendado pela Micro Focus junto à Vanson Bourne, com profissionais de 49 países, chegou a uma faixa de 775 a 850 bilhões. As duas estimativas divergem em ordem de grandeza e devem ser lidas como isso mesmo: estimativas.

O sistema mais citado como exemplo extremo é o Individual Master File da receita federal norte-americana, descrito em depoimento oficial ao Congresso como um sistema de 60 anos, escrito em “uma linguagem arcaica que exige competências especializadas”. Não é uma curiosidade: é o registro tributário de pessoa física de um país inteiro, em produção.

Modernizar por modernizar é despesa. Os critérios abaixo são os que usamos para dizer que vale — e para dizer que não vale.

Vale quando a base técnica está fora de suporte e há vulnerabilidade conhecida sem correção; quando o custo de manter já compete com o de substituir; quando o sistema impede algo que o negócio decidiu fazer (integrar, escalar, usar o próprio dado); ou quando o conhecimento está concentrado em pessoas que podem sair.

Não vale quando o sistema é estável, isolado, tem pouca mudança prevista e nenhuma exposição externa. Nesse caso o dinheiro rende mais em outro lugar, e a decisão correta é registrar o risco e revisitar em prazo definido.

Há um dado que ajuda a dimensionar a inércia: no orçamento federal norte-americano de TI para o exercício de 2025, cerca de US$ 83 bilhões — 79% do total planejado — estavam destinados a operar e manter o que já existe. O órgão de auditoria registra que essa proporção de aproximadamente 80% se repete ano após ano. É a fotografia do que acontece quando a decisão de modernizar é sempre adiada: o orçamento inteiro passa a ser consumido pela manutenção, e não sobra margem para o resto.

Vale a ressalva metodológica: esses números são do governo federal dos Estados Unidos e não descrevem o parque brasileiro. Não encontramos estatística oficial brasileira que quantifique idade, número ou custo de sistemas legados. O que existe é registro qualitativo — o Tribunal de Contas da União, ao auditar o INCRA, apontou a “ausência de controles adequados nos sistemas legados” do órgão, sem quantificar.

A diferença entre esse desenho e uma reescrita convencional está na etapa três. Comparar as respostas do sistema novo com as do legado, com tráfego real, é o que transforma “achamos que está igual” em evidência. Sem isso, a validação depende de alguém lembrar de todas as regras — e é exatamente essa lembrança que não existe em sistema legado.