Sistema legado não é sinônimo de sistema inútil

TL;DR

• Sistema legado é todo sistema que continua em produção, sustenta a operação e ninguém quer tocar.
• O medo de substituir não é conservadorismo: é a constatação de que o risco da migração supera o desconforto do presente.
• As regras mais valiosas da empresa costumam estar escondidas em IF antigos, não em manuais.
• Quando a única pessoa que entende o sistema se aposenta, o problema vira seu.
• Manter, modernizar ou substituir são decisões diferentes — e cada uma tem um critério próprio.

~ 10 min de leitura · 1673 palavras

O que caracteriza um sistema legado

Sistema legado é um sistema que continua em produção, sustenta operações críticas da empresa e cuja tecnologia — ou cujo projeto — já não acompanha mais o padrão atual do mercado.

Repare na definição: nada ali diz “antigo demais” ou “mal feito”. Um sistema escrito em 2015 pode ser legado se ninguém entende mais o raciocínio por trás dele. Um sistema de 1995 pode não ser legado se está documentado, testado e alguém da equipe consegue dar manutenção nele sem medo.

Os sinais característicos são outros:

• Ninguém na equipe atual participou do projeto original.
• A documentação está desatualizada, incompleta ou simplesmente não existe.
• Mudanças simples levam semanas porque o impacto de cada alteração é desconhecido.
• O sistema roda em ambiente que o time de infraestrutura prefere não mexer.
• Funciona — e é isso que importa. Fatura, emite, controla estoque, calcula imposto.

Essa última característica é a que define o problema: o sistema legado é, por definição, um sistema que funciona. Se não funcionasse, a discussão seria outra — seria substituição de sistema morto, com prazo e orçamento próprios.

Por que as empresas têm medo de substituí-lo

Porque o sistema legado funciona e a substituição pode parar tudo que depende dele.

O custo do sistema legado é visível e cotidiano: lentidão, retrabalho manual, integração difícil. O custo da substituição é invisível até acontecer: regras esquecidas que somem na migração, relatórios fiscais que deixam de bater, clientes que recebem nota errada. O segundo grupo de custos não aparece na planilha do projeto — aparece em produção, semanas depois do go-live.

Tem também o fator risco assimétrico. Se a migração dá certo, a empresa ganha modernidade. Se dá errado, perde dias de operação, credibilidade com cliente e, em alguns setores, conformidade regulatória. Para um gestor, “continuar com o sistema antigo” é a opção com dano limitado e conhecido. Não é falta de visão — é administração de risco, ainda que conservadora.

O medo aumenta quando o sistema toca área fiscal, financeira ou regulatória. Nesses domínios, “quase igual” é sinônimo de multa. Todo mundo prefere o sistema que erra de forma conhecida ao sistema novo que erra de forma nova.

Regras de negócio escondidas no código

O maior patrimônio de um sistema legado não é o código. É o que o código registra: anos de decisões operacionais que existem em nenhum outro lugar.

Exemplos comuns em empresas brasileiras: o cliente da zona rural tem frete calculado diferente; no último dia do mês, o faturamento fecha às 17h e não à meia-noite; aquele desconto especial existe porque um contrato de 2011 prevê isso; o cadastro com CNPJ terminado em determinado dígito segue um fluxo alternativo por causa de uma exceção da SEFAZ. Nada disso está no manual. Está no IF, nas stored procedures, naquele trecho que parece arbitrária e não é.

Cada uma dessas regras entrou no código porque alguém, em algum momento, precisou dela para resolver um problema real. O sistema legado é, na prática, o repositório mais fiel da memória operacional da empresa — melhor que qualquer documentação, porque está em execução todos os dias.

É por isso que substituir às custas de “reescrevemos do zero com base na documentação” costuma falhar: a documentação não existe, e o que existe está no código que ninguém leu por inteiro.

Dependência de profissionais antigos

Quando a documentação não existe, ela está nas cabeças de poucas pessoas — geralmente quem participou do projeto original ou passou anos operando o sistema.

Essa dependência cria um risco silencioso. Enquanto a pessoa está na empresa, tudo funciona: ela sabe onde está cada regra, o que aquele parâmetro faz, por que aquele módulo não pode ser alterado na quarta-feira. Quando ela sai — aposentadoria, troca de emprego, doença — o conhecimento sai junto. E o descobrimento é imediato: a primeira mudança trivial vira um projeto de duas semanas.

O ponto que costuma passar despercebido: a dependência de pessoas raramente é registrada como risco no sistema legado. Os relatórios de técnico medem linhas de código, complexidade ciclomática, cobertura de teste. Nenhum deles mede “quantas pessoas entendem este módulo”. Se a resposta é uma, o risco do sistema não é técnico — é sucessório.

A mitigação não é glamourosa: documentar de forma incremental, aos poucos, cada vez que alguém explica uma regra. Não é projeto de documentação com prazo de seis meses — é hábito contínuo. E começa antes de a pessoa avisar que vai embora.

Dificuldade de integração com novas tecnologias

Sistemas legados raramente foram desenhados para conversar com outras plataformas. Eles nasceram numa época em que eram o centro de tudo — o resto do mundo se adaptava a eles.

O resultado aparece em toda integração nova: não existe API, o acesso a dados é direto no banco (com schema que ninguém documenta), a comunicação é por arquivo texto em layout fixo ou por tela com automação de digitação. Cada nova conexão exige adaptação customizada, e cada adaptação aumenta o acoplamento — o que torna a próxima integração mais difícil ainda.

Aqui mora uma armadilha comum: tratar integração como motivo automático de substituição. Nem sempre é. Estratégias como expor uma camada de API sobre o sistema legado (o padrão de “strangler fig” descrito por Martin Fowler) permitem modernizar o contato com o mundo externo sem reescrever o núcleo. O sistema antigo continua fazendo o que faz bem; o novo ecossistema conversa com ele por uma fronteira controlada.

A pergunta certa não é “consegue integrar?” e sim “quanto custa integrar de novo, e por quantos anos ainda?”. Se a resposta for um custo crescente com prazo aberto, aí sim a modernização entra na mesa.

Problemas de segurança e manutenção

Essa é a parte em que a crítica ao sistema legado é legítima — e não pode ser ignorada.

Tecnologia antiga acumula vulnerabilidades conhecidas: framework sem atualização de segurança há anos, protocolo descontinuado, dependência que não recebe patch. Sistema em plataforma obsoleta não recebe correção do fornecedor, e cada dia em produção aumenta a superfície de ataque. Para sistemas que tocam dados de clientes ou operação financeira, isso não é problema de estilo — é responsabilidade.

Manutenção também fica caro por escassez: profissionais que dominam COBOL, Delphi, ASP clássico ou Visual Basic 6 existem, mas a oferta encolhe e a hora deles sobe. Cada bug no sistema antigo custa mais caro que o equivalente numa stack atual, não porque o código seja pior, mas porque pouca gente sabe mexer nele.

O erro está em generalizar: sistema legado não é automaticamente inseguro. Um sistema Delphi rodando isolado na rede interna, com acesso controlado e dados críticos replicados, pode ser menos exposto que uma aplicação web moderna mal configurada. O que precisa ser avaliado é a combinação de exposição, atualização e conhecimento disponível — não a idade da tecnologia em si.

Quando manter, modernizar ou substituir

São três decisões diferentes, e o erro comum é tratá-las como uma só.

Manter faz sentido quando o sistema cumpre sua função, os riscos de segurança estão controlados e há pelo menos uma pessoa (documentação, de preferência) que entende o núcleo. O custo de manutenção é conhecido e cabe no orçamento. Nesse cenário, a melhor decisão é a mais chata: deixar funcionando e investir o orçamento em documentação.

Modernizar faz sentido quando o problema é a fronteira — integração, interface, acesso de novos canais — mas o núcleo do sistema continua sólido. Adicionar camadas de API, migrar a interface, containerizar o legado. Modernização preserva o conhecimento acumulado e resolve o sintoma que dói.

Substituir faz sentido quando o sistema parou de ser mantido por falta de gente, quando os riscos de segurança são inegociáveis (conformidade, exposição de dados) ou quando a plataforma em si impede a evolução do negócio. Aí a substituição não é questão de gosto — é questão de sobrevivência operacional.

O critério que separa os três casos: entender primeiro onde está o problema real. Tecnologia velha que funciona e está segura pode ser mantida por anos. Tecnologia “moderna” sem documentação e sem gente que a entenda é, para todos os efeitos, um legado pior.

O maior problema está no código ou na falta de documentação?

Quase sempre, na falta de documentação.

Código legado pode ser lido. É trabalhoso, é lento, às vezes é doloroso — mas um desenvolvedor competente consegue, com tempo, reconstruir o que aquele IF estranho faz e por que ele existe. A informação está lá, executando, todos os dias. Testes automatizados, quando existem, aceleram esse processo: o sistema é a única documentação que não mente, porque está rodando.

Documentação inexistente quebra outra coisa: a velocidade da transição de conhecimento. Sem ela, cada nova pessoa no projeto repete a arqueologia do zero. Pior: parte do conhecimento nem está no código — está nas decisões que *não* viraram código (o que se decidiu não fazer, e por quê) e nas cabeças de quem operou o sistema por anos. Isso não é recuperável por engenharia reversa.

A consequência prática: empresas que mantêm sistemas legados com disciplina de documentação migram, modernizam e substituem com muito menos trauma. As que tratam o código como fonte única de verdade descobrem, no dia da migração, que a fonte não contava a história inteira.

Antes de condenar o sistema antigo, vale a pergunta reversa: você conseguiria recriar, hoje, todas as regras que ele executa? Se a resposta for não, o sistema legado ainda é a memória mais completa que a empresa tem — e destruir a memória antes de registrá-la é a decisão mais cara possível.

Leitura relacionada

• Migrar de Web Forms para .NET 10: dificuldades, riscos e benefícios — quando a modernização de um legado vale o esforço.
• O risco de não migrar do Web Forms para .NET 10 — o caso real de um legado que precisava de decisão, não de crítica.
• Do DOS à Web: mudou tudo, menos o problema que o software resolve — o problema de negócio sobrevive a todas as tecnologias.

—

*Roberto Brandini — Código em Produção*