Sistema legado: manter, integrar, modernizar ou reescrever?

O que é sistema legado?

Sistema legado é o software que ainda roda uma parte do seu negócio, mas ficou caro ou arriscado de mudar. A idade importa pouco. Em 2025, 36% das empresas brasileiras com dez ou mais pessoas ocupadas pagaram por capacidade de processamento em nuvem. O Cetic.br lê o número como sinal da grande prevalência de estruturas on premises no país. Rodar em servidor próprio é comum e não define legado. O problema começa quando ninguém mexe no sistema sem medo.

O termo costuma aparecer no plural, sistemas legados, porque empresas mais antigas raramente têm só um. Pode ser um ERP que o fornecedor parou de atualizar, uma planilha com macros que virou processo ou um app em Delphi que só um desenvolvedor entende.

Este é o guia central do nosso tema de sistemas legados e integração. Cada saída tem um texto de apoio.

Como saber se o seu sistema legado já é um problema?

Um sistema legado vira problema quando deixá-lo como está custa mais do que mexer nele. Cinco sinais aparecem antes da pane.

1. Qualquer mudança leva semanas e ninguém quer mexer. Pedir um campo novo vira projeto.
2. A hospedagem custa mais do que o software vale. Servidor antigo e suporte especializado pesam no caixa.
3. Só uma pessoa entende o sistema. Se ela sair, o negócio fica refém de código sem documentação.
4. O sistema não conversa com o resto. Os dados são redigitados entre telas e planilhas, com os erros que isso traz.
5. Ninguém sabe responder ao questionário de segurança de um cliente. Não há log de acesso nem backup testado para mostrar.

Os sinais 1, 2, 3 e 5 são os que listamos na página de modernização de aplicações da isonew. Se você marcou dois ou mais, meça antes de decidir.

Às vezes a lei marca o prazo. Desde janeiro de 2026, quem já emite documento fiscal deve destacar o IBS e a CBS na nota, segundo o Comitê Gestor do IBS. O destaque é só informativo. Para o Simples Nacional, começa em 2027. Em agosto, a Receita Federal e o CGIBS anunciaram que aprovariam a suspensão do preenchimento obrigatório desses campos em documentos como NF-e e NFC-e. Este texto não confirma se o ato já foi publicado. Se o seu emissor de nota é um sistema que ninguém atualiza, pergunte ao contador qual regra vale hoje.

O problema também aparece em governos. Em julho de 2025, o GAO, órgão de auditoria do Congresso dos Estados Unidos, relatou o padrão. As agências federais costumam declarar cerca de 80% do gasto de TI em operação e manutenção do que já existe. Dos 11 sistemas legados que mais precisam de modernização, 8 usam linguagens ultrapassadas e só 3 tinham plano completo. O dado é americano e de governo, mas a lógica serve para qualquer empresa: o que vai para manter o que existe não sobra para mudar.

Manter, integrar, modernizar ou reescrever: quais são as saídas?

Existem cinco saídas: as quatro do título e uma que muita gente esquece, trocar por um produto pronto. O Google Cloud usa outra lista, os "R's da modernização" (re-hospedagem, mudança de plataforma, refatoração, reconstrução e substituição), e avisa que não existe abordagem única: a estratégia certa depende do aplicativo, das metas de negócio, do orçamento e da tolerância a riscos.

A tabela vai da saída que mexe menos para a que mexe mais. Comece pela primeira linha e só desça quando o motivo estiver escrito.

Quando manter o sistema legado é a decisão certa?

Manter é certo quando o sistema faz o trabalho, muda pouco e o custo de rodar cabe no caixa. Reescrever é caro demais para um problema que um backup testado e uma página de documentação resolveriam.

Antes de manter, confirme três coisas:

• Alguém além do desenvolvedor sabe operar e restaurar o sistema. Pergunte com nome e data: quem restaura o banco hoje, e quando foi o último teste?
• O fornecedor, se existir, ainda dá suporte e correção de segurança. Sem correção, manter deixa de ser opção.
• A lista de mudanças dos próximos 12 meses é curta. Se o negócio vai mudar muito, manter só adia o custo.

O segundo ponto tem um lado legal. Se o sistema guarda dados pessoais, o art. 46 da LGPD manda adotar medidas de segurança, técnicas e administrativas, aptas a proteger esses dados de acessos não autorizados. Sistema sem correção de segurança e sem backup testado tem pouco a mostrar.

Manter inclui documentar, criar backup, isolar o acesso e marcar uma data para olhar de novo. É o menor investimento contra uma pane, e muitas vezes basta.

Quando integrar resolve sem mexer no núcleo?

Integrar resolve quando o sistema legado está bom no que faz e o problema é que os dados ficam presos nele. O sintoma típico é a redigitação entre sistemas, que gera erro e atraso.

Sistema antigo sem API é comum, e dá para trabalhar. Exportação agendada, acesso ao banco de dados ou uma API simples na frente do sistema costumam resolver sem trocar nada. É o caminho do nosso serviço de integração de dados e sistemas.

O guia de integração de sistemas mostra como fazê-los conversar sem refazer tudo. O de integração com ERP trata dos pontos de falha quando o legado é o ERP.

Um aviso: integrar não paga a dívida técnica. Se a dor é que ninguém consegue mudar o código, a integração esconde o problema por um tempo.

Por que modernizar por etapas costuma vencer a reescrita?

Modernizar por etapas costuma vencer porque o negócio segue rodando e cada passo pode ser desfeito. Reescrever tudo promete um sistema limpo e entrega, no meio do caminho, dois sistemas incompletos.

Martin Fowler, da Thoughtworks, descreveu esse risco ao explicar o padrão Strangler Fig. Na versão de agosto de 2024 do texto, ele escreveu:

Mas já vimos esse plano de aparência simples fracassar de forma retumbante na maioria das vezes. Substituir um sistema de TI sério leva muito tempo, e os usuários não podem esperar por novos recursos. Substituições parecem fáceis de especificar, mas muitas vezes é difícil descobrir os detalhes do comportamento existente. O que é pior, boa parte desse comportamento é algo que não é realmente desejado, então construí-lo é desperdício.

Martin Fowler, "Strangler Fig", martinfowler.com, 22 de agosto de 2024 (tradução nossa do inglês)

Fowler recomenda o caminho gradual, que começa com pequenas adições construídas separadas do código antigo. Ele admite que a arquitetura de transição será descartada no fim, e diz que o risco menor e o valor mais cedo compensam esse custo.

A documentação de arquitetura da Microsoft descreve a mecânica. Uma camada de fachada (proxy) fica na frente do sistema legado e roteia cada requisição para o sistema antigo ou para o novo. Quando o antigo não recebe mais nada, você o desliga.

Nosso trabalho segue quatro passos, descritos na página de modernização de aplicações:

1. Avaliar. Quanto custa hospedar, quanto custa mudar e onde estão os pontos de risco reais.
2. Sequenciar. Ordenar as fatias para que cada uma possa ser desfeita.
3. Rodar em paralelo. O caminho novo no ar ao lado do antigo, até as saídas baterem.
4. Aposentar. Desligar a fatia antiga, documentar e passar para a próxima.

No exemplo de entregável dessa página, os relatórios vão primeiro, porque são somente leitura e não têm risco de escrita. Depois vem a autenticação, com duas semanas de sobreposição, e o faturamento por último. A fatia antiga só é desligada depois de 14 dias rodando sem erro, e o rollback é voltar o DNS em menos de 10 minutos.

Um ateliê de alfaiataria da região do Triangle, nos Estados Unidos, migra hoje o fluxo de trabalho do Talus para um sistema próprio, em etapas. A plataforma antiga segue no ar. Os resultados ainda não foram medidos, então não publicamos número. O caso está em Hilo.

Quando reescrever um sistema legado é a opção certa?

Reescrever é a opção certa em poucos casos, todos com motivo verificável. A Microsoft lista quatro situações em que o padrão gradual não serve, e a lista é um bom teste:

• Você não tem acesso ao código-fonte. Sem ele, não dá para desligar a função migrada nem redirecionar as chamadas internas.
• O sistema é pequeno e trocá-lo inteiro é simples.
• Você precisa desligar a solução original rápido.
• Não dá para interceptar as requisições ao sistema antigo.

Há um quinto caso, descrito pelo Google Cloud: a base de código não aceita refatoração. Aí entra a reconstrução, que reescreve o aplicativo do zero, preservando o escopo original, com linguagens e frameworks modernos.

Se cair em um desses casos, reescreva, com duas regras. Primeira: documente o que o sistema atual faz antes de apagar qualquer coisa, a partir do código e dos dados. Segunda: não copie tudo. A Thoughtworks chama de antipadrão a paridade de funcionalidades na migração de legados, porque sistemas antigos acumulam recursos que ninguém usa. Construa o que as pessoas precisam hoje.

Quando trocar o sistema legado por um produto pronto?

Trocar por um produto pronto funciona quando o seu processo é parecido com o de outras empresas do ramo. O Google Cloud trata essa saída como escolha comum quando existe um produto comercial pronto para uso que atende às necessidades da empresa.

Teste antes de construir: liste as dez tarefas que o sistema faz todo dia e marque quantas um produto de mercado cobre sem adaptação. Se for quase todas, comprar resolve mais rápido. Se o diferencial mora nas regras só do seu sistema, o produto obriga você a mudar o processo, e isso também tem preço.

Quanto custa modernizar um sistema legado?

O custo de modernizar depende de quatro variáveis, e nenhuma delas é o tamanho do código. Não publicamos valor de projeto, então este texto não traz número.

• Quantos sistemas precisam ser tocados. Cinco sistemas com donos diferentes e sem documentação viram um projeto de integração.
• Se as regras de negócio estão escritas em algum lugar. Se a lógica de preço e de aprovação mora só na cabeça das pessoas, parte do projeto é extraí-la.
• Quão limpos estão os dados. Cliente duplicado e identificador inconsistente dão trabalho.
• Quantas pessoas precisam mudar a forma de trabalhar. Software para quatro pessoas é um projeto diferente de software para oitenta.

Cobramos por fase, com preço fechado, e a primeira fase de construção tem faixa de planejamento de 4 a 10 semanas, como explica a nossa página de preços. Antes de pedir orçamento, calcule o outro lado: o que o sistema atual custa por ano (hospedagem, licença, suporte) mais as horas perdidas com redigitação e espera. Esse número é a régua de qualquer proposta.

Para ver como se monta esse orçamento, leia quanto custa um software sob medida. Se a dúvida é quem constrói, veja fábrica de software.

Onde a IA e a automação entram em um sistema legado?

A IA entra depois da decisão sobre o sistema. Uma automação ou um agente de IA precisa ler e escrever dados no seu sistema. Se ele não oferece isso, o primeiro trabalho é abrir uma porta: exportação, acesso ao banco ou uma camada leve na frente.

O uso de IA nas empresas brasileiras cresceu, mas ainda é minoria: a TIC Empresas 2025 mostra que 17% das empresas com dez ou mais pessoas ocupadas usaram aplicações de IA, contra 13% em 2024. Com dados presos num sistema que não exporta nada, a IA trava nessa porta.

Recomendamos esta ordem: integrar o que dói, depois automatizar a tarefa repetitiva que o sistema já expõe. O guia de automação de processos mostra como escolher o processo e medir o retorno.

Como decidir em uma semana?

Você chega a uma decisão em uma semana com seis perguntas respondidas por escrito, uma rodada para cada sistema legado:

1. O que ele faz de essencial para o caixa ou para a entrega?
2. Quanto custa rodar por ano, com hospedagem e licença?
3. Quem sabe operar, restaurar e mudar? Há mais de uma pessoa?
4. Quais mudanças o negócio vai exigir nos próximos 12 meses?
5. Os dados saem dele hoje? Por qual caminho?
6. Se ele parar por um dia, o que acontece, e quanto custa?

Com as respostas, a decisão se encaixa na tabela. Pouca mudança e risco baixo: manter. Dados presos: integrar. Parte trava a mudança: modernizar por etapas. Um produto cobre o uso real: substituir. Sem acesso ao código ou com arquitetura que não aguenta o negócio: reescrever.

Se prefere que alguém de fora faça essa conta, existe o Diagnóstico de Oportunidades de IA. É um trabalho pago, de escopo fechado, que mapeia os processos e olha os sistemas que guardam os dados. Ele entrega um plano ordenado com custo, retorno, esforço e risco, mais uma lista do que não construir. O plano é seu, com ou sem a isonew na construção. Se você seguir para a construção, o valor é abatido da primeira fase. Se um produto que você pode comprar resolver melhor, a gente diz.

O que pular em um projeto de sistema legado?

Estas decisões parecem boas e custam caro. Pularíamos:

• Reescrever porque o código está feio. Código feio que funciona e custa pouco não é motivo. Descubra o que ele faz antes de jogar fora.
• Tratar mudança de hospedagem como modernização. O Google Cloud descreve a re-hospedagem como o caminho mais rápido para levar o sistema à nuvem, mas com o menor ganho. Serve para sair de um servidor velho, não para modernizar.
• Começar sem documentar o que o sistema faz. Sem isso, você não sabe quando a fatia nova está igual à antiga.
• Escolher uma data de virada única. Pedidos em andamento ficam para trás. Prefira etapas com rollback.
• Contratar sem saber quem assume depois. Exija notas de arquitetura, manuais de operação e acessos para outra equipe assumir.