Resposta curta: dá para modernizar um sistema legado sem reescrevê-lo usando quatro caminhos, do mais barato ao mais caro: expor o sistema por uma API (dias a semanas), construir uma interface nova por cima do banco e da API (semanas a meses), substituir módulo por módulo pelo padrão estrangulador (meses, sem parada), ou migrar só a infraestrutura para tirar o sistema de um servidor que ninguém mantém mais. A reescrita completa é a quinta opção, e só se justifica quando o código não tem mais quem o entenda ou a tecnologia perdeu suporte de segurança.
Por que a reescrita é a primeira ideia e quase sempre a errada
Quando um sistema antigo começa a incomodar, a reação natural é querer recomeçar limpo. É compreensível: ninguém gosta de mexer em código que não entende.
O problema é que o sistema legado, por mais feio que seja, tem uma qualidade que o substituto não terá por muito tempo: ele está certo. Dentro dele existem quinze anos de regras de exceção, correções de casos raros e ajustes fiscais que ninguém documentou — e que só aparecem quando o sistema novo entra no ar e erra.
O padrão se repete com uma clareza cansativa. A reescrita é orçada em oito meses. No mês dez, o sistema novo faz 80% do que o antigo fazia. Os 20% que faltam são justamente os casos difíceis, que são o motivo de o código antigo ser feio. E enquanto isso, o sistema velho continua rodando, porque não dá para desligar — então a empresa mantém dois sistemas, paga por dois, e não colheu benefício de nenhum.
Isso não significa que reescrever nunca se justifica. Significa que é a última opção da lista, não a primeira.
Caminho 1 — Expor o legado por uma API
Quando: o sistema faz o que precisa, mas está isolado. Ninguém consegue tirar dado dele sem exportar planilha, e nada consegue escrever nele sem alguém digitar.
Esta é de longe a intervenção de melhor retorno, e a mais subestimada. Você não toca na lógica de negócio: constrói uma camada fina por cima — lendo o banco, chamando as rotinas existentes ou usando o web service que o fornecedor já oferece e ninguém ligou — e passa a ter uma API.
De repente, o legado conversa. O e-commerce consulta estoque nele. O BI lê dele. O app de campo escreve nele. O sistema não ficou moderno; ele ficou conectado — e conectado resolve a maior parte da dor que fazia a empresa querer trocar de sistema.
Custo típico: semanas, não meses. É onde recomendamos começar em quase todos os casos, porque também gera a informação que as decisões seguintes exigem.
Cuidado: escrever direto no banco de um sistema de terceiros pula as validações dele e corrompe dado de um jeito que só aparece meses depois. Leitura direta do banco é aceitável; escrita deve passar pelas rotinas do próprio sistema.
Caminho 2 — Interface nova sobre o motor antigo
Quando: a lógica está correta, mas a tela é o gargalo. Operação lenta, treinamento longo, não funciona no celular, a equipe reclama todo dia.
Com a API do caminho 1 no lugar, você constrói uma interface moderna por cima. O cálculo continua acontecendo no sistema antigo — que continua certo — e o usuário passa a interagir por uma tela feita nesta década.
Funciona especialmente bem quando só uma parte da operação precisa disso: o vendedor em campo, o cliente que quer acompanhar o pedido, o operador de chão de fábrica. Você moderniza a experiência de quem sente a dor, sem tocar nos módulos administrativos que ninguém reclama.
Caminho 3 — Padrão estrangulador (substituição por módulo)
Quando: partes do sistema realmente precisam morrer, mas não todas ao mesmo tempo.
O nome é feio e a ideia é simples: em vez de construir o substituto inteiro e trocar num fim de semana, você coloca uma camada na frente do sistema antigo que decide, requisição a requisição, quem responde. No começo o legado responde tudo. Você reescreve um módulo — digamos, faturamento — e passa a rotear só o faturamento para o código novo. O resto continua no legado.
Repete-se módulo a módulo até que, um dia, o legado não recebe mais nenhuma chamada e pode ser desligado sem cerimônia.
A vantagem não é técnica, é de risco: em nenhum momento existe um dia de virada. Se o módulo novo der problema, você reverte o roteamento daquele módulo e volta ao antigo em minutos. Comparado ao big bang, é a diferença entre trocar o pneu com o carro parado e trocar o carro inteiro em movimento.
O custo é maior que os caminhos 1 e 2, e existe um período em que se mantém os dois lados. Vale quando o sistema é grande demais para uma virada segura — que é o caso da maioria dos sistemas que sustentam operação de verdade.
Caminho 4 — Modernizar só a infraestrutura
Quando: o software está bem, o problema é onde ele roda. Servidor físico embaixo de uma mesa, sistema operacional sem atualização de segurança, backup que ninguém testou, e uma única pessoa que sabe reinstalar.
Aqui não se muda uma linha de código: leva-se a aplicação para um ambiente atual, com backup testado, monitoramento e restauração ensaiada. É a modernização menos glamourosa e a que mais evita desastre, porque o risco que ela resolve é o de o sistema simplesmente parar e ninguém conseguir levantá-lo.
Como escolher
Uma pergunta resolve a maior parte dos casos: o que exatamente está doendo?
| A dor é… | O caminho é |
|---|---|
| "Não conversa com nada" | 1 — API |
| "A tela é horrível e lenta" | 2 — Interface nova |
| "Uma parte específica está errada" | 3 — Estrangulador nesse módulo |
| "Tenho medo de ele cair" | 4 — Infraestrutura |
| "Ninguém aqui entende o código" | Aí sim, avalie reescrita |
Note que quatro das cinco respostas não envolvem reescrever nada. Isso não é otimismo — é o que acontece quando se separa o problema real da vontade de recomeçar limpo.
O custo de adiar
Um dado que costuma mover a conversa mais que qualquer argumento técnico: empresas gastam entre 60% e 80% do orçamento de TI apenas mantendo sistemas legados funcionando. Sobra entre um quinto e dois quintos para qualquer coisa nova.
E o custo composto é a parte pior: cada ano de adiamento aumenta o custo futuro da migração em 20% a 25%, porque mais regra nova é empilhada em cima da base antiga, mais gente que entendia o sistema sai da empresa, e mais a tecnologia se afasta do que o mercado sabe manter.
Adiar não é economizar. É financiar a mesma obra a juros.
Por onde começar
Antes de contratar qualquer coisa, três passos que a própria empresa consegue fazer:
- Escreva a dor em uma frase. Não "o sistema é velho" — mas "o vendedor leva quarenta minutos para fechar um pedido" ou "o estoque do site erra toda semana". Vago não tem solução.
- Descubra se existe API ou web service. Muitos sistemas comerciais já expõem e ninguém habilitou. Isso muda o orçamento em uma ordem de grandeza.
- Meça o custo do manual. Quantas horas por mês alguém gasta reconciliando, digitando duas vezes ou corrigindo dado? É o número que justifica ou derruba o projeto.
Próximo passo: Veja como funciona a modernização de sistemas legados, ou faça um Diagnóstico de Operação — duas semanas para mapear qual dos caminhos acima é o seu, com escopo e custo fechados antes de qualquer projeto começar.