O que é um sistema legado?
Um sistema legado é software de que a sua empresa continua a depender mas que já não se consegue alterar em segurança: a tecnologia perdeu o suporte do fabricante, as pessoas que o entendiam saíram, ou cada modificação arrisca partir algo que ninguém sabe prever. A idade, por si só, não torna um sistema legado; o risco de lhe tocar, sim.
A escala do problema é registo público. O Government Accountability Office dos EUA encontrou sistemas federais críticos com até 60 anos ainda em produção, e as agências federais dedicam cerca de 80% da despesa em IT a operar e manter o que já existe, segundo o relatório GAO-25-107795. A Doomity, empresa de desenvolvimento de software com clientes nos EUA, Reino Unido, Espanha e Portugal, moderniza sistemas legados sem reescritas big-bang — este glossário explica o que o termo cobre na realidade.
Atualizado: agosto de 2026
Porque é que um sistema que funciona acaba por virar legado?
Por deriva, não por decisão. Uma versão da framework chega ao fim de vida e a atualização fica para depois. O programador que sabia porque é que o módulo de faturação funciona assim sai. Um remendo rápido passa a sustentar meia operação. Cada escolha foi razoável; a soma é um sistema em que ninguém se atreve a tocar.
O mecanismo por trás dessa deriva tem nome: dívida técnica. A dívida é o custo acumulado das decisões de engenharia adiadas — legado é onde um sistema aterra quando essa dívida capitaliza para lá do ponto de mudança segura. A Doomity trata as duas como um único diagnóstico: não se orça uma modernização sem mapear primeiro a dívida que a causou.
Quais são os sinais de que o seu sistema já é legado?
Seis sinais repetem-se tanto nas avaliações de legados da Doomity que servem de autoteste. Um é um incómodo; três ou mais são um diagnóstico:
- Ninguém quer fazer deploy. As releases marcam-se como uma cirurgia, porque o último deploy descontraído causou uma queda de que alguém ainda se lembra.
- Quem o construiu já cá não está. O fornecedor fechou, a agência seguiu em frente ou o único programador que o entendia saiu — e levou o mapa mental consigo.
- O stack perdeu o suporte de segurança. VB6, Access clássico, AngularJS, Delphi antigo ou frameworks sem patches: não haverá mais correções, chegue o CVE que chegar.
- Alterações pequenas custam semanas. Acrescentar um campo toca em cinco módulos, e a estimativa de qualquer coisa é «depende».
- O conhecimento vive numa cabeça. Uma única pessoa sabe levantar o sistema quando cai — e essa pessoa tem férias, pré-aviso e valor de mercado.
- As integrações andam a remendos. Exportações manuais, macros de folha de cálculo e copy-paste agendado seguram os fluxos de dados.
O diagnóstico de legados gratuito em /pt/ferramentas/diagnostico-legados transforma estes sinais num autoteste de dez perguntas com veredicto pontuado.
Um sistema legado é o mesmo que um sistema velho?
Não — e a diferença decide o orçamento. Código antigo com suporte, entendido e testado é apenas software maduro. A Doomity já viu sistemas com 20 anos em plena forma, e microsserviços com três que já eram legados porque a equipa que os construiu se dissolveu:
| Dimensão | Sistema velho que funciona | Sistema legado |
|---|---|---|
| Idade | Alta — e irrelevante | Qualquer uma — três anos chegam |
| Suporte e patches | O stack continua a receber correções de segurança | Componentes em fim de vida, CVEs conhecidos por corrigir |
| Conhecimento da equipa | Documentado, partilhado, sobrevive a uma saída | Concentrado numa pessoa, ou perdido |
| Custo e risco de mudar | Proporcional à alteração | Desproporcionado — cada alteração arrisca o conjunto |
| O que fazer | Continuar a mantê-lo; isso é o sucesso | Avaliar, estabilizar, modernizar por fatias |
Quais são exemplos reais de sistemas legados?
Os exemplos mais bem documentados são públicos: os gabinetes de auditoria governamentais publicam a idade, a linguagem e o risco dos sistemas que inspecionam, o que os torna verificáveis como nenhuma anedota do setor privado. Quatro destacam-se:
- O Individual Master File do IRS. A fonte de dados autoritativa das contas fiscais individuais dos EUA é uma aplicação com 60 anos escrita numa linguagem arcaica, e o IRS anda há mais de uma década a tentar substituí-la, segundo o relatório GAO-23-104719. Cada reembolso de impostos individual nos EUA continua a depender dela.
- O sistema de coordenação nuclear do Pentágono. O GAO documentou no relatório GAO-16-468 (2016) que o Strategic Automated Command and Control System — que coordena as funções operacionais das forças nucleares dos EUA — ainda funcionava sobre um computador IBM Series/1 dos anos 70 e disquetes de 8 polegadas.
- Um sistema do Tesouro com 51 anos em COBOL. Entre os sistemas críticos do relatório GAO-25-107795 há um sistema do Departamento do Tesouro que, ao fim de 51 anos em produção, continua a correr em COBOL e linguagem assembly — linguagens com cada vez menos gente capaz de as manter.
- 28% dos sistemas do governo central britânico. A própria State of digital government review do governo do Reino Unido (janeiro de 2025) estimou que 28% dos sistemas dos departamentos do governo central eram legados em 2024 — contra 26% no ano anterior.
O padrão que a Doomity encontra nas avaliações do setor privado é o mesmo a uma escala menor — ERPs sem suporte, bases de dados Access, ferramentas VB6 a segurar a operação diária — com uma diferença: nenhum auditor publica um relatório, por isso o risco fica invisível até rebentar.
Que riscos reais carrega um sistema legado?
Três, por ordem crescente de visibilidade. Segurança: componentes em fim de vida acumulam vulnerabilidades conhecidas sem patch à vista. Continuidade: o sistema depende de hardware, licenças ou de uma pessoa que podem desaparecer em qualquer trimestre. E o custo de oportunidade — o mais silencioso: o estudo da McKinsey e Oxford sobre 5.400 projetos de TI concluiu que os grandes projetos ultrapassam o orçamento em 45% e entregam 56% menos valor do que o prometido, e o relatório DORA 2025 liga a fraca capacidade de entrega precisamente ao medo de mudar que um legado institucionaliza. Um sistema que não consegue alterar em segurança é uma estratégia que não consegue executar.
É preciso reescrever um sistema legado para o resolver?
Não — e o reflexo da reescrita total é a forma como um sistema legado se transforma em dois sistemas e um projeto de migração. A alternativa que a Doomity defende é a modernização incremental: estabilizar o que é frágil, envolver o que funciona em interfaces limpas e substituir componentes por fatias que entregam valor enquanto o sistema antigo continua a operar. O quadro para decidir entre os dois caminhos está em reescrever vs refatorar.
A Doomity executa a modernização de legados como trabalho de âmbito fechado que começa por uma avaliação, não por um orçamento. Os seus engenheiros vêm de equipas que construíram para a Holcim, a Canon España e a Indra — organizações onde o sistema legado ERA o negócio — e o seu processo de entrega integra IA: até 40% mais rápido, com cada conclusão verificada por um engenheiro sénior.
FAQ
Sistema legado significa software de que uma organização continua a depender mas que já não consegue alterar em segurança: o fabricante retirou o suporte, os programadores originais saíram ou cada modificação arrisca partir algo imprevisível. O termo descreve risco, não idade: um sistema com três anos pode ser legado e um com vinte pode não o ser.
O Individual Master File do IRS é o exemplo clássico: uma aplicação com 60 anos que continua a ser a fonte autoritativa das contas fiscais individuais dos EUA, segundo auditorias do GAO. O GAO também documentou um sistema do Tesouro com 51 anos em COBOL e, em 2016, um sistema de coordenação nuclear do Pentágono com disquetes de 8 polegadas. A maioria das empresas tem equivalentes menores: ERPs sem suporte, bases de dados Access, ferramentas VB6.
Não há limiar oficial: o teste prático é conseguir alterá-lo em segurança. Se o stack recebe patches, a equipa entende o código e um deploy é rotina, não é legado, tenha a idade que tiver. Se as alterações metem medo, o conhecimento está numa só cabeça ou o suporte terminou, é legado mesmo que tenha sido lançado há três anos.
Funcionar hoje não é a métrica — a métrica é o que acontece quando a mudança chegar: um patch de segurança que não consegue aplicar, uma norma, a integração que um cliente grande exige, ou a saída da pessoa-chave. Modernizar é mais barato enquanto o sistema está estável e o conhecimento ainda está na empresa. Encarece exatamente quando se torna urgente.
Normalmente mais do que os donos receiam. As regras de negócio codificadas num legado são o ativo mais valioso e mais difícil de recuperar que uma empresa tem: sobreviveram a anos de operação real. A modernização conserva essas regras e substitui a casca frágil à volta — frameworks sem suporte, dependências mortas, integrações por documentar. Deitar tudo fora é pagar para redescobrir as próprias regras.
Por uma avaliação, não por uma proposta. O diagnóstico de legados gratuito da Doomity em /pt/ferramentas/diagnostico-legados dá um primeiro sinal pontuado em três minutos. O passo seguinte, se se justificar, é uma avaliação técnica de âmbito fechado que mapeia risco, dependências e concentração de conhecimento — e sai com um plano, execute-o a Doomity ou não.
Se três ou mais dos seis sinais lhe soam ao seu sistema, o passo útil é uma avaliação que mapeie o que é frágil, o que é valioso e por que ordem resolver — antes que chegue a mudança que não se pode adiar.