Milhares de empresas brasileiras rodam a operação inteira em cima de um sistema que ninguém quer mais tocar. É um ERP em Delphi de 2008, uma aplicação em VB6 que só roda em uma máquina específica, um emaranhado de planilhas ou um PHP antigo cujo único desenvolvedor que o entendia já saiu da empresa. A modernização de sistemas legados deixou de ser um projeto de TI e virou uma decisão de negócio: o custo de manter o sistema antigo funcionando quase sempre é maior do que o número que aparece na fatura.
Este guia mostra como reconhecer um sistema legado, quanto ele realmente custa, quais são as estratégias de modernização disponíveis e como planejar a migração sem parar a operação. O objetivo é dar aos decisores critérios objetivos para saber quando modernizar, quando reescrever e quando manter.
Neste artigo
- O que caracteriza um sistema legado
- O custo real de manter um sistema legado
- Estratégias de modernização de sistemas legados
- Como planejar a modernização sem parar a operação
- Quando reescrever do zero vale a pena (e quando não)
- Perguntas frequentes
O que caracteriza um sistema legado
Sistema legado não é sinônimo de sistema velho. Um software pode ter dez anos e continuar saudável se recebeu manutenção, testes e atualizações de dependências. O que define um legado é a combinação de fatores técnicos que tornam a evolução cara, lenta e arriscada.
Na prática, os sinais objetivos de que você está diante de um sistema legado são:
- Stack sem suporte: linguagem, framework ou banco de dados em fim de vida (Delphi 7, VB6, PHP 5, .NET Framework antigo, versões de banco fora do suporte do fabricante).
- Ausência de testes automatizados: qualquer alteração exige teste manual e um pouco de sorte, porque ninguém sabe o que mais vai quebrar.
- Dependência de uma única pessoa: existe apenas um profissional (às vezes já fora da empresa) que entende como o sistema funciona por dentro.
- Incompatibilidade com mobile e cloud: o sistema só roda em desktop, exige instalação local ou não expõe APIs para integrar com outras ferramentas.
- Documentação inexistente ou desatualizada: a regra de negócio vive no código e na cabeça das pessoas, não em documentos.
Quanto mais desses sinais estão presentes, maior o risco de continuar adiando a decisão. Um sistema que reúne vários deles não está apenas envelhecido: ele está se tornando um ponto único de falha para a operação.
O custo real de manter um sistema legado
O gasto visível com um sistema legado (licença, servidor, um desenvolvedor de plantão) é a menor parte da conta. Segundo o Gartner, entre 60% e 80% do orçamento de TI da maioria das empresas é consumido apenas para manter os sistemas existentes funcionando, sobrando pouco para inovação. Esse desequilíbrio é o primeiro custo invisível: cada real preso na manutenção é um real que não vira vantagem competitiva.
O segundo custo é a dívida técnica que se acumula. O Consortium for Information and Software Quality (CISQ) estimou o custo da baixa qualidade de software nos Estados Unidos em US$ 2,41 trilhões em 2022, dos quais cerca de US$ 1,52 trilhão correspondem a dívida técnica acumulada. O relatório Developer Coefficient, da Stripe, apontou que desenvolvedores gastam cerca de 42% do tempo lidando com dívida técnica e manutenção, horas que nunca viram produto novo.
Há ainda três riscos que raramente entram na planilha:
- Segurança: stacks sem suporte param de receber correções. Vulnerabilidades conhecidas (CVEs) permanecem abertas porque não há patch oficial, expondo a empresa a vazamentos e ransomware.
- Perda de talentos: desenvolvedores qualificados evitam manter tecnologia obsoleta. Contratar e reter quem sabe Delphi ou VB6 fica mais caro e mais difícil a cada ano.
- Paralisia de negócio: quando o sistema não integra com pagamentos, mobile, BI ou IA, cada nova oportunidade de mercado esbarra na mesma limitação técnica.
Levantamento publicado pelo CIO Dive mostra que empresas gastaram, em média, quase US$ 3 milhões no último ano lidando com atualizações e dívida técnica de tecnologia legada. Somados, esses fatores explicam por que a conta de nao fazer nada costuma ser a mais alta de todas.
Estratégias de modernização de sistemas legados
Não existe uma única forma de modernizar. O Gartner formalizou um conjunto de estratégias (originalmente cinco, hoje frequentemente descritas como os 7 Rs) que dão um vocabulário comum para decidir o que fazer com cada aplicação. Na prática, cinco abordagens cobrem a maioria dos casos de empresas de pequeno e médio porte:
| Estratégia | O que é | Esforço / Risco | Quando usar |
|---|---|---|---|
| Encapsular (API) | Manter o sistema como está e expor suas funções via API, sem mexer no código interno. | Baixo / Baixo | Quando o legado funciona bem, mas precisa se integrar a novos canais (mobile, parceiros, IA). |
| Rehost (lift and shift) | Mover o sistema para infraestrutura moderna (cloud) sem alterar o código. | Baixo / Baixo | Quando o objetivo imediato é sair de servidor físico e ganhar escalabilidade e backup. |
| Replatform | Ajustes pontuais para aproveitar recursos da nova plataforma (banco gerenciado, containers), sem reescrever a lógica. | Médio / Baixo | Quando pequenas mudanças destravam ganhos grandes de custo ou performance. |
| Refactor | Reestruturar o código por dentro: quebrar o monólito em módulos, reduzir acoplamento, adicionar testes, sem mudar o comportamento externo. | Médio-alto / Médio | Quando o sistema tem futuro de longo prazo, mas a base ficou difícil de evoluir. |
| Rebuild (reescrita) | Reconstruir a solução com arquitetura, linguagem e padrões atuais, preservando a regra de negócio. | Alto / Alto | Quando a tecnologia está descontinuada e o custo de manter supera o de reconstruir. |
A escolha raramente é binária. É comum combinar estratégias: encapsular o legado com uma API para destravar um app mobile agora e, em paralelo, refatorar os módulos mais críticos ao longo do tempo. Para entender como uma reconstrução sob medida se diferencia de soluções de prateleira, vale conhecer o guia de desenvolvimento de software sob medida.
Como planejar a modernização sem parar a operação
O maior medo de quem depende de um sistema legado é legítimo: parar a operação para trocar a base. A boa notícia é que as práticas modernas foram desenhadas justamente para evitar esse cenário. A migração não precisa (e não deve) acontecer em um único evento.
Migração incremental com o padrão Strangler Fig
O padrão Strangler Fig, descrito por Martin Fowler, é a referência para modernizar sem big bang. A ideia é criar uma camada (fachada) na frente do sistema antigo que intercepta as requisições e decide, função por função, se atende pelo legado ou pelo novo módulo já migrado. Aos poucos, o novo sistema envolve o antigo até que o legado possa ser desligado com segurança. A documentação de arquitetura da Microsoft detalha como implementar essa fachada na prática.
Rodar em paralelo e migrar dados com cuidado
Durante a transição, legado e novo sistema convivem. Isso permite validar cada módulo migrado contra o comportamento real do antigo antes de virar a chave. A migração de dados merece atenção especial: mapear o esquema, limpar inconsistências históricas e rodar cargas de teste evita que anos de dados críticos se percam ou corrompam na virada.
Empresas que não têm um time interno para conduzir esse processo costumam recorrer a parceiros especializados. O guia de outsourcing de TI ajuda a avaliar quando faz sentido terceirizar a modernização. Vale lembrar que modernizar também é o que destrava recursos novos: uma base moderna com APIs é o pré-requisito para integrar IA a um sistema existente sem gambiarra.
Empresas que precisam de um diagnóstico técnico antes de decidir podem falar com um time técnico especializado para mapear o legado e desenhar a estratégia mais segura.
Quando reescrever do zero vale a pena (e quando não)
A reescrita completa (rebuild) é a estratégia mais cara e mais arriscada, e por isso deve ser a exceção, não a regra. Pesquisa da McKinsey sobre projetos de modernização mostra que 45% deles estouram o orçamento inicial e 7% ultrapassam o prazo em mais de 200%. O maior vilão é o big bang rewrite: tentar substituir tudo de uma vez, o que costuma falhar pela complexidade oculta da regra de negócio e pela impossibilidade de congelar a evolução do sistema por anos.
Reescrever do zero tende a valer a pena quando:
- A tecnologia está descontinuada e sem caminho de atualização viável.
- A arquitetura está tão comprometida que cada mudança gera novos bugs.
- O custo acumulado de manter o legado já supera o de reconstruir com critérios atuais.
- O modelo de negócio mudou e o sistema antigo não suporta o que a empresa precisa oferecer.
É melhor NÃO reescrever do zero quando:
- O sistema ainda sustenta processos críticos e concentra anos de regra de negócio validada.
- Existem muitas integrações em produção que precisariam ser refeitas simultaneamente.
- Não há documentação suficiente para reconstruir o comportamento com segurança.
Nesses casos, a combinação de encapsulamento e refatoração incremental entrega mais valor com muito menos risco. Se o modelo de negócio cresceu além da ferramenta antiga, vale avaliar se um sistema de gestão sob medida resolve melhor. Ferramentas atuais de desenvolvimento assistido por IA também aceleram a reconstrução e mudam o cálculo de custo; veja o que realmente funciona em criar aplicativo com IA. Na FWC Tecnologia, já modernizamos e construímos plataformas de missão crítica para indústria e serviços, como o Solvace, plataforma de gestão para operações industriais, e o Wehandle, sistema de gestão de serviços, unindo regra de negócio consolidada a uma arquitetura moderna, mobile e integrável. Com mais de 30 apps entregues e mais de seis anos de estrada, a experiência mostra que a decisão certa quase nunca é tudo ou nada.
Perguntas Frequentes
O que é um sistema legado?
Sistema legado é um software cuja tecnologia, arquitetura ou dependências tornam a evolução cara, lenta e arriscada. Não é apenas questão de idade: o que caracteriza um legado é a stack sem suporte, a ausência de testes, a dependência de uma única pessoa e a incompatibilidade com mobile e cloud.
Quando devo modernizar um sistema antigo?
O momento chega quando o custo de manter o sistema supera o de evoluí-lo. Sinais claros são manutenção cada vez mais cara, falhas frequentes, dificuldade de contratar quem sustente a tecnologia e a impossibilidade de integrar novos canais como mobile, pagamentos ou IA. Adiar só aumenta a dívida técnica.
Quanto custa modernizar um sistema legado?
O custo varia conforme a estratégia: encapsular via API e rehospedar são mais baratos, enquanto refatorar e reescrever exigem mais investimento. O que costuma sair caro é o oposto: não fazer nada. Estima-se que empresas gastem de 60% a 80% do orçamento de TI apenas mantendo sistemas antigos em funcionamento.
É melhor modernizar ou reescrever o sistema do zero?
Na maioria dos casos, modernizar de forma incremental entrega mais valor com menos risco do que reescrever tudo de uma vez. A reescrita completa só vale a pena quando a tecnologia está descontinuada ou a arquitetura está comprometida demais. Pesquisas mostram que 45% dos projetos de reescrita estouram o orçamento.
É possível modernizar sem parar a operação da empresa?
Sim. O padrão Strangler Fig permite migrar função por função enquanto o sistema antigo continua rodando. Uma camada intermediária direciona cada requisição para o legado ou para o novo módulo já migrado, até que o antigo possa ser desligado com segurança. A operação nunca precisa parar.
Próximo Passo
Solicite um orçamento ou faça uma estimativa de preço para o seu projeto.