Sistema legado é um software antigo, geralmente desenvolvido em tecnologias obsoletas, que ainda está em produção porque sustenta processos críticos do negócio. Costuma rodar em mainframe COBOL, ou num monolito Java que cresceu por 15 anos sem refatoração. Este guia cobre o que faz um software virar legado, os riscos reais e seis estratégias práticas pra modernizar sem cair no big-bang rewrite.

O que é um sistema legado?

Um sistema legado é qualquer software em produção que usa tecnologia, arquitetura ou práticas defasadas pelo padrão atual, mas que continua entregando valor. Não é só sobre idade: existe sistema de 5 anos que já é legado (AngularJS 1.x) e sistema de 25 anos que ainda recebe deploy semanal com cobertura de testes decente.

Michael Feathers, autor de Working Effectively with Legacy Code, dá uma definição mais provocativa:

“To me, legacy code is simply code without tests.”

Michael Feathers

A definição do Feathers desloca o foco da tecnologia pra capacidade de mudança. Se você não consegue alterar uma função sem rezar pra produção não cair, é legado. A Wikipedia resume como “sistema de computação obsoleto que continua em uso porque ainda atende às necessidades dos usuários”.

Por que esses sistemas continuam existindo? Substituí-los custa caro, eles funcionam bem o suficiente, e ninguém mais entende todas as regras de negócio embutidas no código. Bancos brasileiros ainda processam compensação em COBOL. Operadoras de telecom rodam billing em Oracle Forms. O sistema feio é o que paga a conta.

Sinais de que sua empresa depende de um sistema legado

Antes de propor modernização, vale identificar os sintomas. Se você marca três ou mais itens da lista abaixo, sua empresa tem um problema de legado:

• Linguagem ou framework descontinuado: COBOL, Visual Basic 6, AngularJS, Flash, Delphi 7, PHP 5.x sem suporte da comunidade.
• Dependências sem patches de segurança: bibliotecas com CVEs abertos há anos, banco em versão fora de suporte (Oracle 10g, SQL Server 2008, MySQL 5.5).
• Documentação inexistente ou desatualizada: quem entende o sistema é o “Seu Joaquim”, e o Joaquim se aposentou em 2019.
• Time original saiu: ninguém na empresa hoje participou da arquitetura inicial, e o conhecimento mora em e-mails arquivados.
• Build frágil ou manual: só compila na máquina do tech lead, deploy envolve copiar DLL pra um diretório específico, ambiente de homologação não bate com produção.
• Integração via flat files: sistemas trocam dados por CSV em FTP, batch noturno que roda às 2h, planilhas Excel exportadas e importadas manualmente.
• Cobertura de testes próxima de zero: toda mudança vira “vou testar manualmente, depois a gente vê em produção”.
• Hardware específico ou virtualização exótica: depende de uma máquina física rodando Windows Server 2003 que ninguém pode desligar.

Esses sinais são acumulativos. Um isolado é gerenciável. Quatro juntos freiam o roadmap inteiro.

Os 5 maiores riscos de manter um sistema legado em produção

1. Brechas de segurança sem patches

Sistemas legados rodam em runtimes fora de suporte: Java 6, .NET Framework 3.5, Python 2.7, PHP 5.6. Quando uma CVE crítica aparece no SO ou no runtime, não vem patch oficial. A empresa fica exposta ou paga suporte estendido caro.

Pior cenário: bibliotecas internas dependem de versões específicas de OpenSSL, Log4j, Spring. O Log4Shell em 2021 mostrou quantas empresas tinham Log4j 1.x sem nem saber. Atualizar quebra o build, então fica como está.

2. Dificuldade de contratar devs

Tente abrir vaga pra dev COBOL sênior em Recife. Existe, mas com salário de R$ 25-40k pra um perfil cada vez mais raro. O mesmo vale pra ABAP, PowerBuilder, ColdFusion, RPG do AS/400. Mesmo em tecnologias comuns, dev recém-formado prefere startup com Kotlin a manter monolito Spring 3 de 800 mil linhas. A empresa fica refém do pequeno grupo que sabe rodar o sistema.

3. Custo crescente de manutenção

Manutenção de legado segue curva exponencial. Bug fix simples leva uma semana porque a regra está espalhada em 12 stored procedures. O TCO sobe ano a ano enquanto a velocidade de entrega cai. Em algum momento, o custo de manter passa o custo de substituir.

4. Lock-in de fornecedor ou hardware

Muitos legados estão amarrados a um fornecedor que sumiu, foi comprado, ou cobra fortuna pra renovar contrato. Mainframes IBM Z, Oracle Forms, SAP customizado ao extremo, ERPs proprietários verticais. O lock-in também aparece no hardware: vi um cliente com ERP num IBM AS/400 de 2008, equipamento no fim de vida, IBM sem peças, sistema sem rodar em x86. Migrar virou projeto de 18 meses sob pressão.

5. Atrito em integrações modernas (APIs, cloud, mobile)

Sistema legado raramente tem API REST nativa. Integração geralmente é via SOAP com WSDL gigante, ou pior, leitura direta no banco (alguém expôs uma view e ninguém pode mudar tabela sem quebrar três sistemas). Quando o produto precisa de app mobile ou exposição de dados pra parceiros, o legado vira gargalo: cada novo canal exige camada de adaptação cara, e a latência sofre porque a chamada passa por três middlewares antes de chegar no core.

6 estratégias de modernização (e quando usar cada uma)

O Gartner consolidou seis abordagens (os “6 R’s”) pra modernizar sistemas legados. Cada uma tem custo, risco e tempo de retorno diferentes. Empresa madura usa combinações.

Rehost (lift-and-shift)

Pegar a aplicação como está e mover pra outro ambiente, normalmente cloud. Sem tocar no código. VM física vira EC2 ou Compute Engine, e pronto.

Quando faz sentido: data center vencendo contrato, hardware no fim de vida, necessidade de sair rápido de uma situação cara. Funciona bem quando o sistema é estável e o time não pode refatorar.

Risco principal: você só transferiu o problema. Custo de cloud pode ser maior que on-premise se a aplicação não foi pensada pra elasticidade, e a dívida técnica continua intacta.

Replatform

Pequenas mudanças pra aproveitar capacidades da nova plataforma, sem reescrever. Trocar Tomcat 7 por 9, migrar Oracle pra PostgreSQL, containerizar em Docker, usar serviços gerenciados em vez de instância dedicada.

Quando faz sentido: meio-termo pra times que querem ganho operacional sem o risco de reescrita total. Reduz custo de infra e melhora escalabilidade horizontal.

Risco principal: incompatibilidades sutis entre versões. Aquele trigger específico do Oracle que não existe no Postgres vira projeto paralelo.

Refactor

Reescrever partes do código mantendo o comportamento externo. Objetivo: melhorar manutenibilidade, performance ou cobertura de testes. Aqui entra o trabalho clássico do Feathers: caracterizar comportamento, escrever testes pinning, refatorar em pequenos passos.

Quando faz sentido: código fonte ainda é compreensível, time tem tempo pra investir em qualidade, e o sistema vai continuar evoluindo.

Risco principal: regressões em comportamentos não documentados. Toda função tem aquele “if cliente_codigo == 4711” que ninguém sabe por quê, mas remove e o financeiro fica sem fechar.

Rearchitect (strangler fig pattern)

Mudar a arquitetura sem parar o sistema antigo. O Strangler Fig Pattern do Martin Fowler propõe colocar um proxy (geralmente API gateway) na frente do legado e migrar funcionalidade por funcionalidade pra serviços novos. Cada rota nova passa pra implementação moderna, as antigas seguem batendo no legado. Quando todas migraram, o legado morre por sufocamento (daí o nome).

Quando faz sentido: sistemas grandes, críticos, que não podem parar. Permite entregar valor incremental e voltar atrás quando dá errado. Favorito pra migração de monolito pra microsserviços.

Risco principal: ficar preso no estado intermediário pra sempre. Já vi empresas com legado e novo rodando em paralelo há 7 anos, custando dobrado.

Rebuild

Reescrever do zero mantendo o escopo funcional. Mesma funcionalidade, novo código, nova stack. Sai o ASP.NET Web Forms de 2008, entra um Next.js com NestJS.

Quando faz sentido: código atual é irrecuperável, regras de negócio são bem documentadas, e o sistema é pequeno o suficiente pra reescrever em 6-12 meses.

Risco principal: “second-system effect”. Joel Spolsky escreveu em 2000 que reescrever do zero é o pior erro estratégico de uma empresa de software. Subestima o conhecimento implícito no código velho: time gasta dois anos reescrevendo e a v2 não tem 30% das regras que o legado tinha.

Replace

Aposentar o sistema e adotar solução de mercado. Trocar ERP caseiro por SAP ou Totvs. Migrar CRM custom pra Salesforce ou HubSpot.

Quando faz sentido: domínio é commodity (financeiro, RH, CRM básico), customizações do legado são acidentais (não geram diferencial), e o custo de manter dev próprio não compensa.

Risco principal: perda de processos diferenciais. Se o legado tinha lógica que dava vantagem competitiva, você acabou de doar pro mercado.

Como integrar um sistema legado com APIs modernas

Modernização raramente é binária. Na maioria das vezes você precisa fazer o legado conversar com sistemas novos enquanto a migração acontece. Padrões consolidados:

API Gateway na frente do legado. Expõe endpoints REST modernos via Kong, AWS API Gateway ou Nginx, e por trás chama o sistema antigo (SOAP, RPC ou screen scraping). Bancos fazem isso há anos: app mobile chama API JSON, que chama middleware, que envia mensagem MQ, que aciona transação CICS no mainframe.

BFF (Backend for Frontend). Backend específico por canal (web, mobile, parceiro), orquestrando chamadas e adaptando formatos. O BFF mobile agrega 5 chamadas do legado e devolve um JSON otimizado, evitando round-trips.

CDC (Change Data Capture). Quando você não pode mexer no legado pra publicar eventos, o CDC lê o transaction log do banco e transforma cada INSERT/UPDATE/DELETE em evento. Debezium, Oracle GoldenGate ou AWS DMS conectam no Postgres, Oracle, SQL Server e publicam num Kafka.

Event-driven com Kafka ou RabbitMQ. Em vez de cada consumidor chamar API separada, o legado (ou o CDC dele) publica eventos e os consumidores se inscrevem. Reduz acoplamento e permite substituir o legado transparentemente.

Exemplo prático. Sistema de seguros com core em COBOL. Pra expor cotação no app mobile, a equipe construiu: adaptador Java conversando com o mainframe via MQ Series, microsserviço Spring Boot orquestrando cotação e risco, API gateway com OAuth2, e BFF servindo o app. O COBOL continua processando, mas o usuário só vê uma API moderna.

Erros comuns na modernização (e como evitar)

Big-bang rewrite. Reescrever o sistema inteiro em paralelo, congelar o legado, migrar tudo num go-live único. Quase sempre dá errado. Escopo cresce, prazos estouram, o legado continua recebendo demandas que o novo não tem, e o projeto vira política. Solução: faça strangler fig, libere valor incremental, mantenha os dois sistemas rodando até o último cliente migrar.

Subestimar regras de negócio implícitas. A função feia de 800 linhas com 47 ifs aninhados não é feia por incompetência. Cada if foi adicionado pra resolver um caso real que apareceu em produção. Se você reescreve “limpando”, vai recriar todos os bugs originais que aqueles ifs corrigiam. Solução: caracterize o comportamento atual com testes antes de mudar qualquer coisa.

Parar de evoluir o legado durante a migração. O negócio não para porque a TI está modernizando. Se você congela o legado, perde competitividade. Se evolui só o legado, o novo nasce defasado. Solução: dual-track, com mudanças críticas indo pros dois sistemas e roadmap de produto considerando o estado da migração.

Ignorar o time que mantém o legado. Os devs que conhecem o sistema antigo costumam ser tratados como obstáculo. Erro grave: eles têm o conhecimento de domínio mais valioso da empresa. Traga eles pro time de modernização, faça mentoria reversa (eles ensinam regras de negócio, o time novo ensina stack moderna), e evite o discurso de que o legado é vergonha. Sem essas pessoas, o projeto fracassa.

Perguntas frequentes sobre sistemas legados

O que é um sistema legado?

Sistema legado é um software antigo, baseado em tecnologia defasada, que ainda roda em produção porque executa processos críticos do negócio. Pode ser um mainframe COBOL processando folha, um monolito Java de 15 anos sustentando o ERP, ou uma aplicação mais nova sem testes automatizados.

O que é um legacy system?

Legacy system é o termo em inglês equivalente a sistema legado. Designa qualquer sistema computacional obsoleto pelo padrão atual da indústria que continua em uso porque ainda atende necessidades operacionais. Costuma ser custoso de manter, mas crítico demais pra ser desligado sem planejamento.

O que é um sistema legado em programação?

Em programação, sistema legado é qualquer base de código difícil de evoluir com segurança. Michael Feathers definiu como “código sem testes”. Inclui aplicações em linguagens descontinuadas, codebases sem documentação, dependências fora de suporte e arquiteturas que não comportam as demandas atuais.

O que é um processo legado?

Processo legado é um fluxo de trabalho ou rotina operacional que persiste apesar de ferramentas mais eficientes existirem. Pode ser técnico (build manual, deploy via FTP, integração por CSV) ou de negócio (aprovação por e-mail, conciliação em planilha). Modernizar processos costuma ser pré-requisito pra modernizar sistemas.

Qual a melhor estratégia para modernizar um sistema legado?

Não existe estratégia universal. Pra sistemas grandes e críticos que não podem parar, o Strangler Fig Pattern (rearchitect incremental) é o mais seguro. Pra sistemas pequenos com escopo bem documentado, rebuild funciona. Pra urgência de saída de data center, rehost na cloud entrega resultado rápido.

Próximos passos

Modernizar legado é um problema técnico, mas a maior parte do desafio é organizacional. Stakeholders precisam aceitar que o ROI vem em meses, e que a velocidade do roadmap pode cair antes de subir.

• Mapeie a dependência. Quais sistemas dependem do legado? Quais APIs ou flat files saem dele? Sem inventário, qualquer estratégia é chute.
• Escreva testes de caracterização. Antes de tocar em qualquer linha, capture o comportamento atual com Approval Tests, Snapshot Tests ou testes de contrato.
• Escolha um bounded context pra começar. Em vez de migrar tudo, pegue uma fatia coesa (módulo de cadastro de clientes), modernize com strangler fig, aprenda, expanda.
• Invista no time que mantém o legado. Eles têm o conhecimento de domínio mais valioso da empresa. Trate como heróis e a modernização anda. Trate como obstáculo e o projeto trava.

Mesmo Netflix, Spotify e Stripe têm código que ninguém quer mexer. A diferença entre sofrer e prosperar não é a ausência de legado, e sim a estratégia consciente pra conviver com ele.

Leituras relacionadas

• Strangler Fig: Como modernizar sistemas monolíticos sem riscos
• Shadow API: O risco invisível no seu sistema
• Arquitetura Zero Trust: A segurança de APIs em 2026
• Guia da LGPD 2026: Retenção de dados para devs