Sistema legado: o que é, sinais de risco e quando modernizar
Publicado em · atualizado em
Sistema legado (em inglês, legacy system) é o software que ainda sustenta uma parte importante da operação, mas que o time já não consegue alterar com segurança e a um custo razoável, por falta de testes, de documentação atualizada, de quem conheça o código ou de suporte à tecnologia. A idade do sistema pesa menos que o custo de mudá-lo.
Em 1º de agosto de 2012, a corretora americana Knight Capital começou o dia com uma versão nova do seu sistema de roteamento de ordens, instalada servidor por servidor nos dias anteriores. Um dos oito servidores, porém, ficou sem o código novo. Nele seguia o Power Peg, uma função sem uso desde 2003 que ainda podia ser acionada. Uma flag reaproveitada pela versão nova ativou esse código antigo, e em cerca de 45 minutos o sistema mandou milhões de ordens ao mercado. O prejuízo passou de US$ 460 milhões, segundo a ordem da SEC que apurou o caso.
O sistema da Knight tinha acabado de ser atualizado. O problema estava num trecho antigo, que ninguém voltou a testar depois de uma mudança feita em 2005, e numa instalação sem um segundo técnico conferindo. Quando o código segue em produção, mas o time já não sabe o que ele faz, o sistema virou legado, e isso acontece muito antes de a tecnologia sair de linha.
O que é um sistema legado
O termo virou sinônimo de sistema antigo, mas a idade explica pouco: um programa de 30 anos que quase nunca muda pode dar menos trabalho que um monólito de seis anos em que cada alteração quebra outra coisa. Três referências ajudam a precisar o conceito.
A primeira é de Michael Feathers, no prefácio de Working Effectively with Legacy Code (2004): código legado é simplesmente código sem testes. Com testes, dá para mudar o comportamento do código de forma rápida e verificável; sem eles, ninguém sabe se o código está melhorando ou piorando.
A segunda vem de Meir Lehman, que estudou a evolução de grandes sistemas a partir dos anos 1970. Duas das leis de Lehman dizem que um software usado numa aplicação do mundo real precisa ser adaptado continuamente, senão fica cada vez menos satisfatório, e que a complexidade dele cresce a menos que alguém trabalhe para mantê-la ou reduzi-la. O sistema envelhece porque o negócio em volta dele muda.
A terceira é a dívida técnica. Ward Cunningham criou a metáfora em 1992: entregar código de primeira versão é como contrair uma dívida, e cada minuto gasto em código que não está bem certo conta como juro dessa dívida. Pesquisadores do Software Engineering Institute (SEI), da Carnegie Mellon, definem a dívida técnica como escolhas de design ou de implementação convenientes no curto prazo, mas que criam um contexto técnico capaz de deixar uma mudança futura mais cara ou impossível.
Exemplos de sistemas legados
Em 2016, o GAO, órgão de auditoria do Congresso dos Estados Unidos, relatou que o Tesouro americano mantinha o cadastro de contribuintes pessoa física num sistema de cerca de 56 anos, escrito em assembly e rodando num mainframe IBM, e que o sistema que coordena as forças nucleares do país ainda usava disquetes de 8 polegadas. Em 2025, dos 11 sistemas federais que o GAO apontou como os que mais precisam de modernização, oito usavam linguagens ultrapassadas e sete operavam com vulnerabilidades conhecidas.
Nas empresas, os exemplos são menos exóticos: ERPs muito customizados, aplicações em COBOL, Delphi ou Visual Basic 6, monólitos Java presos a frameworks antigos, plataformas de faturamento que cresceram à base de remendos. O que eles têm em comum é a regra de negócio que só existe no código.
Sinais de risco: checklist
Nenhum item condena um sistema sozinho. Três ou quatro juntos costumam indicar que o custo de mudar já é maior do que parece.
- Não há testes automatizados nas partes que mais mudam. Sem eles, ninguém sabe ao certo o que uma alteração quebra.
- A regra de negócio só existe no código. A documentação descreve o sistema de anos atrás.
- Uma ou duas pessoas concentram o conhecimento. Se elas saem, a operação fica exposta.
- A tecnologia perdeu suporte ou tem vulnerabilidades que só se resolvem mudando a arquitetura.
- Existe código morto que ninguém se arrisca a apagar. O caso da Knight mostra o que acontece quando ele volta a ser chamado.
- O deploy depende de passos manuais e de quem se lembra deles.
- Mudanças simples pedem desenvolvedor. Trocar um texto de tela vira tarefa de sprint.
- O tempo de entrega cresce com o mesmo time.
- O custo de infraestrutura e de licenças sobe sem relação com o uso.
Por que o legado trava a empresa
O guia de modernização de código que a Anthropic publica, The Code Modernization Playbook, descreve três tendências que, na visão da empresa, fazem projetos de transformação digital renderem menos do que prometem. É material de quem vende modelos de IA para esse trabalho, então vale ler como diagnóstico de um fornecedor, não como pesquisa. As três costumam aparecer em sistemas legados:
- O time passa mais tempo consertando do que construindo. Correção de erro, depuração e ajustes em código difícil tomam boa parte da semana, e a parte nova fica para depois. A seção seguinte traz a estimativa mais citada desse peso, e o método por trás dela.
- Fica difícil achar quem conheça a tecnologia. Segundo o guia, quem se forma hoje aprende linguagens e arquiteturas atuais, e vagas que pedem as antigas ficam cada vez mais difíceis de preencher. Para quem mantém COBOL, Delphi ou VB6, é um risco a acompanhar. O que fazer quando esse risco já chegou está em falta de desenvolvedor COBOL, Delphi e VB6.
- A dívida técnica vira risco de segurança e de conformidade. Tecnologia sem suporte deixa de receber correções, e as exigências regulatórias continuam mudando enquanto o sistema fica parado. No Brasil, a LGPD é o exemplo mais próximo. Um exemplo é o PHP2Shell, de outubro de 2026, que deixou sem versão oficial corrigida quem roda PHP 8.1 ou anterior.
Para o guia, a causa por trás das três é a perda de conhecimento. A documentação se desatualiza, quem desenhou o sistema sai da empresa, e a regra de negócio fica presa num código que pouca gente entende. Daí nasce o medo de mexer no que "funciona", quando muitas vezes ninguém conferiu se funciona mesmo. Feathers chega ao mesmo ponto por outro caminho: sem testes, ninguém sabe se uma mudança melhora ou piora o código.
Custo de manter vs. custo de modernizar
O custo de manter um legado raramente aparece numa linha só do orçamento. O governo americano é uma exceção, porque publica esses números. Segundo o GAO, o governo federal gasta mais de US$ 100 bilhões por ano com TI e segurança cibernética, e as agências costumam informar que cerca de 80% disso vai para operar e manter o que já existe. Em 2016, o órgão calculou que o aumento desse tipo de gasto tinha levado a uma queda de US$ 7,3 bilhões, entre os anos fiscais de 2010 e 2017, no dinheiro para desenvolvimento, modernização e melhoria.
No setor privado, uma referência muito citada é o relatório The Developer Coefficient (setembro de 2018), uma pesquisa que a Stripe fez em parceria com a Harris Poll e que ouviu mais de mil desenvolvedores e mais de mil executivos. Os desenvolvedores estimaram que, na empresa deles, um desenvolvedor gasta em média 17,3 horas de uma semana de 41,1 com manutenção (código ruim, erros, depuração, refatoração e ajustes). É estimativa declarada, não medição, mas dá a ordem de grandeza.
O peso aparece também do lado dos executivos. A consultoria Protiviti, que também vende serviços de modernização, ouviu 1.050 executivos de tecnologia, a maioria em empresas com receita de US$ 1 bilhão ou mais, na Global Technology Executive Survey de 2023. Quase 70% das organizações disseram que a dívida técnica tem alto impacto na capacidade de inovar. Em média, as empresas destinavam 30% do orçamento de TI e 20% dos recursos a lidar com essa dívida. Os setores com índice mais alto foram biotecnologia e dispositivos médicos (82%), telecomunicações (81%) e serviços financeiros (78%). São respostas declaradas, de empresas grandes, e não medição.
Para o seu sistema, os números quase sempre já existem na empresa. De um lado, horas por mudança nas áreas mais alteradas, tempo até a produção, incidentes, infraestrutura e licenças. Do outro, caracterizar o comportamento atual, construir a parte nova ao lado da antiga e manter os dois convivendo por um tempo. O custo de manter é recorrente e cresce com a complexidade; o de modernizar tem começo e fim.
Para montar a conta na sua empresa (principal, juros e uma fórmula de exemplo), veja custo da dívida técnica: onde aparece e como medir.
Quando modernizar: critérios
Nem todo sistema antigo precisa ser modernizado. O guia de migração para a nuvem da AWS inclui retain (manter onde está) e retire (desativar) entre as estratégias possíveis. Quatro perguntas ajudam a decidir:
- O sistema precisa mudar? Se quase não recebe alterações, mantê-lo pode ser a escolha certa.
- O risco já tem data? Fim de suporte, vulnerabilidade que não se resolve sem modernizar e dependência de uma pessoa só são gatilhos objetivos.
- O custo de cada mudança está subindo? Se sobe a cada trimestre, a dívida está se acumulando.
- Existe uma primeira parte que dá para conferir de ponta a ponta? Se não existir, encontrá-la é o primeiro trabalho.
O GAO lista o mínimo que um plano de modernização precisa ter: marcos, a descrição do trabalho e o destino do sistema antigo. Em 2025, oito dos 11 sistemas mais críticos não tinham plano completo, e o órgão associa essa lacuna a mais risco de estouro de custo, atraso e fracasso do projeto.
Para situar a organização em quatro níveis (do reativo ao contínuo) e marcar um checklist, veja maturidade em modernização de legado.
Caminhos: rehost, refactor, rewrite e strangler fig
| Caminho | O que é | Quando faz sentido | Limite |
|---|---|---|---|
| Rehost (lift and shift) | Mudar de infraestrutura sem mexer no código | Data center com prazo para fechar | A dívida do código vai junto |
| Replatform | Mudar com ajustes pontuais, como um banco gerenciado | Cortar custo operacional sem reescrever | A regra continua sem testes |
| Refactor | Mudar a estrutura interna, preservando o comportamento | O sistema precisa continuar evoluindo | Sem âncora no comportamento atual, vira reescrita disfarçada |
| Rewrite | Reconstruir do zero | Raramente para o sistema inteiro | Descarta o que anos de bugs corrigidos ensinaram |
| Strangler fig | Construir o novo ao lado e transferir funções aos poucos, até desligar o antigo | Sistemas críticos que não podem parar | Pede arquitetura de transição durante a convivência |
O rehost muda a infraestrutura sem mexer no código. Quando ele ainda faz sentido, e por que sozinho não moderniza, está em lift and shift vs modernização.
Em 2000, Joel Spolsky escreveu que reescrever o código do zero, como fez o Netscape, é o pior erro estratégico que uma empresa de software pode cometer: o código antigo carrega anos de bugs corrigidos, e jogá-lo fora é jogar fora esse conhecimento. Martin Fowler batizou a alternativa com o nome da figueira-estranguladora (no Brasil, também chamada de mata-pau), que cresce em volta da árvore hospedeira até tomar o lugar dela. Ele conta que, na maior parte das vezes, viu fracassar o plano de construir um sistema novo que faça exatamente o mesmo que o antigo, porque é difícil descobrir os detalhes do comportamento existente. Nos dois casos, a parte difícil é entender o que o sistema antigo faz de fato, e é nesse trabalho que entram os agentes de código.
O que muda com agentes de código e supervisão humana
Agentes de código tornam mais barato ler e alterar muito código de uma vez. Um relato detalhado vem do Google: num artigo de 2025 sobre migrações internas feitas com ferramentas baseadas em modelos de linguagem, os engenheiros contam que, na troca de identificadores de 32 para 64 bits no Google Ads, uma base de mais de 500 milhões de linhas, 80% das modificações que chegaram ao repositório foram escritas inteiramente pela IA, e o tempo total caiu cerca de 50% pela estimativa do próprio time, revisão incluída.
O mesmo artigo mostra onde o trabalho travou. Na troca dos identificadores, um engenheiro precisou, na maioria dos casos, desfazer parte das mudanças do modelo, erradas ou desnecessárias. Em outra migração, de JUnit3 para JUnit4 (5.359 arquivos em três meses), o gargalo foi a velocidade da revisão, e o time limitou de propósito o volume semanal de mudanças para não sobrecarregar os revisores. Revisão e implantação, diz o artigo, ainda exigem um operador humano. Os autores avisam que é um relato de experiência, não um estudo comparativo.
Quando escrever fica barato, o limite passa a ser conferir o que foi escrito. Numa modernização com agentes de código, a supervisão precisa entrar desde o começo:
- Caracterizar antes de trocar. Testes de caracterização, no sentido de Feathers, fixam o que o sistema faz hoje. Agentes de código os escrevem rápido; o time garante que cubram as regras de que o negócio depende. Mais em refatoração com IA sem perder exatidão.
- Humanos leem o que vai para produção. O time define o limite de autonomia dos agentes e o que exige aprovação antes de executar. É o nível 4 da escala de autonomia proposta por Dan Shapiro, e não uma dark factory, em que o código vai para produção sem que ninguém o leia.
- Cada sessão fica registrada. Pedido, passos, modelo, custo, resultado e autoria. Sem esse registro, ninguém reconstrói depois por que uma parte foi trocada, nem quem aprovou. O detalhe está em observabilidade de agentes de código.
Esse é o desenho da plataforma de desenvolvimento agentic da Ithaca para legado. Antes de qualquer linha nova, os agentes de código leem o código e a documentação existentes, que formam a Knowledge base. O sistema novo nasce ao lado do antigo, e cada parte é conferida contra o comportamento em produção antes de entrar. O método completo está em modernização de sistemas legados.
A Dr. Consulta modernizou seu sistema de assinaturas, com oito anos em produção, usando a plataforma de desenvolvimento agentic da Ithaca. O custo de infraestrutura caiu 75% em relação ao período anterior à modernização, e uma feature que levava duas semanas passou a sair em até três dias (exemplo representativo, não medição do backlog inteiro). O time da Dr. Consulta supervisionou os agentes de código o tempo todo. Os números, e o que o caso não prova, estão no case Dr. Consulta.
Perguntas frequentes
O que é um sistema legado?
É o software que ainda sustenta uma parte importante da operação, mas que o time não consegue mais mudar com segurança e a um custo razoável. Costuma faltar teste, documentação atualizada, gente que conheça o código ou suporte do fabricante. A idade, sozinha, não define um sistema legado.
Quais são exemplos de sistemas legados?
ERPs muito customizados, aplicações em COBOL, Delphi ou Visual Basic 6 e monólitos Java presos a frameworks antigos. No setor público, o GAO cita o cadastro de contribuintes do Tesouro americano, escrito em assembly.
Por que um sistema legado atrapalha a inovação?
Porque consome o tempo e o orçamento que iriam para coisas novas. Na pesquisa de 2023 da consultoria Protiviti com 1.050 executivos de tecnologia, quase 70% das organizações disseram que a dívida técnica tem alto impacto na capacidade de inovar, e as empresas destinavam em média 30% do orçamento de TI a ela. Somam-se a isso a falta de quem conheça a tecnologia e o medo de mexer num código sem testes.
Como fazer a migração de sistemas legados sem parar a operação?
Em sistemas críticos, um padrão comum é o strangler fig: o novo é construído ao lado do antigo, e as funções passam por partes, cada uma conferida antes de entrar. Uma falha continua possível, e algumas trocas podem pedir janela de manutenção, mas o estrago fica limitado ao tamanho da parte.
Vale a pena reescrever um sistema legado do zero?
Para o sistema inteiro, raramente: a reescrita descarta anos de bugs corrigidos e trava a evolução até o novo ficar pronto. Reescrever partes pequenas, conferidas contra o comportamento atual, é outra decisão.
Dá para modernizar um sistema legado com IA?
Dá. Agentes de código leem e alteram código em volume, e o limite passa a ser a revisão humana. Por isso, modernizar com eles pede testes de caracterização, um time que lê o que vai para produção e cada sessão registrada.
Agendar demonstração
Se o seu sistema marcou vários itens do checklist, o próximo passo é ver a plataforma funcionando sobre a primeira parte que dá para conferir de ponta a ponta. A implantação começa por ela, lado a lado com o seu time: agentes de código escrevem, o time supervisiona e aprova o que vai para produção, e cada sessão fica registrada.
