Quase toda empresa com alguns anos de operação tem um sistema que ninguém quer tocar. Ele funciona, sustenta processos centrais e carrega regras de negócio que não estão escritas em lugar nenhum — mas cada mudança demora, depende de uma ou duas pessoas e às vezes quebra algo em outro ponto. Esse é o retrato de um sistema legado.
Este texto explica o que caracteriza um sistema legado, por que as empresas continuam dependendo deles, quais riscos eles acumulam e como decidir o que fazer: manter, encapsular, substituir aos poucos ou reescrever.
O que é um sistema legado
Sistema legado é um software que continua essencial para a operação, mas foi construído com tecnologia, arquitetura ou práticas que já não acompanham as necessidades atuais da empresa. Idade não é o critério principal: um sistema de cinco anos pode ser legado se ninguém mais consegue evoluí-lo, e um de vinte pode não ser se foi mantido em dia.
Três características costumam aparecer juntas:
- É crítico. Se parar, a operação para — faturamento, crédito, produção, atendimento.
- É difícil de mudar. Alterações simples exigem semanas, testes manuais e muito cuidado.
- O conhecimento está concentrado. As regras vivem no código e na cabeça de poucas pessoas, não na documentação.
Exemplos de sistemas legados
Os casos mais comuns nas empresas brasileiras:
- ERPs antigos muito customizados, que não podem ser atualizados sem perder as adaptações.
- Sistemas desenvolvidos internamente em linguagens ou ferramentas que saíram de uso — Delphi, Visual Basic 6, Clipper, versões antigas de Java ou .NET.
- Aplicações em mainframe ou em servidores que não podem ser migrados para a infraestrutura atual.
- Planilhas e bancos de dados locais que viraram sistema de fato, com macros que só uma pessoa entende.
- Sistemas de fornecedores que deixaram de dar suporte ao produto.
Por que as empresas mantêm sistemas legados
Não é descuido. O legado continua de pé porque funciona e porque trocá-lo é arriscado. Ele concentra anos de regras de negócio, exceções e ajustes que ninguém documentou; reescrever exige redescobrir tudo isso. Enquanto o sistema atende, a modernização perde a disputa por orçamento para projetos com retorno mais visível.
O problema é que o custo de manter cresce em silêncio — e normalmente só aparece quando algo quebra, quando a pessoa que conhece o sistema sai ou quando um projeto novo esbarra nele.
Os riscos de manter um sistema legado
- Dependência de pessoas. Quando só um ou dois profissionais sabem mexer no sistema, a saída de um deles vira risco operacional.
- Segurança. Linguagens, bibliotecas e sistemas operacionais sem suporte deixam de receber correções de vulnerabilidade.
- Integração. Conectar o legado a APIs, parceiros, aplicativos e canais digitais vira um projeto à parte a cada vez.
- Auditoria e regulação. Sistemas antigos raramente registram quem fez o quê e quando — e é isso que auditorias e reguladores pedem.
- Velocidade do negócio. Produto novo, mudança de regra ou de preço passam a depender do ritmo do sistema, não do mercado.
Débito técnico: o juro que o legado cobra
Débito técnico — ou dívida técnica — é o custo acumulado de soluções que resolveram o problema do momento, mas deixaram o sistema mais difícil de mudar depois: o atalho no código, o teste que não foi escrito, a integração feita às pressas, a atualização adiada.
Como uma dívida financeira, ele cobra juros. Cada mudança nova custa um pouco mais, porque precisa contornar o que ficou mal resolvido. Em um sistema legado, o débito técnico de anos se soma, e chega um ponto em que a maior parte do esforço da equipe vai para manter o sistema de pé, não para evoluí-lo. É esse o sinal mais confiável de que a modernização deixou de ser opcional.
Sinais de que é hora de modernizar
- Mudanças simples levam semanas e frequentemente quebram outra parte do sistema.
- A tecnologia não tem mais suporte do fabricante ou não roda na infraestrutura atual.
- Integrar com um parceiro ou lançar um canal digital depende de contornar o sistema.
- A auditoria pede rastreabilidade que o sistema não consegue fornecer.
- O custo de manutenção cresce ano a ano sem que o sistema ganhe nada novo.
Como modernizar: manter, encapsular, substituir ou reescrever
Não existe uma única resposta. As estratégias mais usadas, da menos para a mais invasiva:
| Estratégia | O que é | Quando faz sentido |
|---|---|---|
| Manter | Estabilizar, documentar e corrigir, sem mudar a arquitetura | O sistema atende e o negócio ao redor dele vai mudar pouco |
| Encapsular | Criar uma camada de APIs na frente do legado | O núcleo funciona, mas precisa conversar com canais e parceiros novos |
| Migrar a plataforma | Levar o mesmo sistema para infraestrutura nova | O problema é o servidor ou o suporte, não o código |
| Substituir aos poucos | Trocar o sistema módulo a módulo, com o antigo rodando em paralelo | O sistema é crítico e não pode parar — o caso mais comum |
| Reescrever | Construir um sistema novo do zero e virar de uma vez | Sistema pequeno, regras bem conhecidas e janela para a virada |
Para sistemas críticos, a substituição gradual costuma ser o caminho mais seguro. Em vez de apostar tudo numa virada única, o novo sistema assume uma função por vez: roda em paralelo, é comparado com o antigo, é validado e só então o módulo legado é desligado. A operação não para, e cada etapa entrega valor sem esperar o fim do projeto. É assim que conduzimos a modernização de sistemas legados na GlassAuto.
A reescrita completa parece mais limpa no papel, mas obriga a reproduzir anos de regras não documentadas antes de entregar qualquer coisa — e congela a evolução do negócio no meio do caminho. Ela faz sentido em sistemas menores ou quando o legado já não tem regra que valha preservar.
Por onde começar
- Diagnóstico. Mapear o que o sistema faz, quais dados ele guarda, com o que se integra e quem depende dele.
- Priorização. Identificar a parte que mais trava a operação ou que mais concentra risco — ela vai primeiro.
- Isolamento. Colocar integrações na frente do legado, para que os sistemas novos parem de depender da estrutura antiga.
- Substituição por etapas. Trocar, rodar em paralelo, conciliar e desligar — uma parte por vez.
- Documentação. Garantir que o conhecimento que estava na cabeça de poucas pessoas passe a estar no código, nos testes e na documentação.
Quando a modernização faz parte de um projeto maior de sistemas sob medida, vale entender também como funciona uma fábrica de software que assume o sistema do diagnóstico à sustentação.
Perguntas frequentes
O que é um sistema legado?
É um software ainda essencial para a operação, mas construído com tecnologia ou arquitetura que já não acompanha as necessidades da empresa — difícil de mudar, de integrar e de manter.
Todo sistema antigo é legado?
Não. O que define o legado é a dificuldade de evoluir o sistema e a dependência de poucas pessoas, não a idade. Um sistema antigo bem mantido pode não ser legado.
Qual a diferença entre débito técnico e sistema legado?
Débito técnico é o custo acumulado de atalhos que deixaram o sistema mais difícil de mudar. Um sistema vira legado, em grande parte, quando esse débito cresce a ponto de o esforço ir quase todo para mantê-lo funcionando.
É possível modernizar sem parar a operação?
Sim, com substituição gradual: o sistema antigo continua atendendo enquanto cada parte nova roda em paralelo, é validada e assume a função.
