Como Modernizar um Sistema Antigo Sem Precisar Começar do Zero

Quase toda empresa com mais de dez anos tem um. Aquele sistema que ninguém quer tocar, que roda numa versão antiga de alguma coisa, que só um fornecedor sabe mexer — e do qual a operação inteira depende.

A pressão para "refazer tudo do zero" é grande. E é, quase sempre, a decisão mais arriscada disponível.

Por que a reescrita completa costuma dar errado

O sistema antigo é feio, mas ele contém anos de regras de negócio que ninguém documentou. Aquele if estranho no cálculo do frete existe porque um cliente grande negociou uma condição especial em 2019. Ninguém lembra. O código lembra.

Quando você reescreve tudo:

• O projeto leva de 2 a 3 vezes o previsto, porque as regras vão sendo descobertas no caminho.
• Durante meses, você mantém dois sistemas e paga por dois.
• No dia da virada, aparecem casos que ninguém previu — e a operação para.
• O sistema novo nasce sem as centenas de correções que o antigo acumulou.

Isso não significa que reescrever nunca vale. Significa que precisa ser a última opção, não a primeira.

Primeiro, descubra qual é o problema real

"O sistema é velho" não é um problema — é uma reclamação. Problemas de verdade soam assim:

• Risco de segurança: roda numa versão sem suporte, com vulnerabilidade conhecida.
• Não integra: os dados existem, mas não saem de lá.
• Não aguenta o volume: trava no fechamento do mês.
• Custa caro para mudar: qualquer alteração leva semanas e custa uma fortuna.
• Dependência de uma pessoa: só um fornecedor sabe mexer, e ele sabe disso.
• Interface impede o trabalho: a equipe leva o dobro do tempo por causa da tela.

Cada um desses tem uma solução diferente — e nenhuma delas exige, necessariamente, reescrever tudo.

Estratégia 1 — Expor uma API sobre o que existe

Para o problema: não integra.

Você não toca no sistema antigo. Constrói uma camada de API que lê e escreve no banco de dados dele, com validação e regras de segurança próprias. A partir daí, sistemas novos conversam com essa API.

O legado continua rodando, mas deixa de ser uma ilha. É, disparada, a intervenção com melhor relação custo-benefício.

Faixa: R$ 8.000 – R$ 30.000

Estratégia 2 — Nova interface sobre o mesmo motor

Para o problema: a tela atrapalha o trabalho.

Se as regras funcionam mas a interface é de outra era, construa telas novas que consomem a API da estratégia anterior. A equipe passa a trabalhar numa interface moderna enquanto o motor antigo segue processando.

Dá para fazer por partes: comece pela tela mais usada do dia a dia.

Faixa: R$ 10.000 – R$ 40.000

Estratégia 3 — Estrangulamento (a mais recomendada)

Para o problema: custa caro mudar, e o risco de reescrever tudo é alto.

O nome é feio, mas a ideia é elegante: você coloca uma camada na frente do sistema antigo que decide, a cada requisição, se ela vai para o legado ou para o módulo novo.

Aí você move um módulo por vez. Começa pelo menos arriscado. Se der problema, volta o roteamento para o legado em minutos. Com o tempo, o antigo vai sendo esvaziado até poder ser desligado.

Vantagens: sem virada de chave, sem parar a operação, valor entregue desde o primeiro módulo e possibilidade de parar no meio se o retorno já for suficiente.

Faixa: varia por módulo, entre R$ 8.000 e R$ 25.000 cada

Estratégia 4 — Migrar só a infraestrutura

Para o problema: risco de segurança e instabilidade.

Às vezes o código está aceitável e o problema é onde ele roda. Atualizar a versão da linguagem, mover para um servidor gerenciado, colocar backup automático, monitoramento e certificado válido resolve o risco sem tocar nas regras.

Faixa: R$ 5.000 – R$ 20.000

Estratégia 5 — Reescrever de fato

Só vale quando:

• A tecnologia não tem mais suporte nenhum e não há caminho de atualização.
• O sistema é pequeno o bastante para ser refeito em poucos meses.
• As regras estão documentadas ou são simples.
• O negócio mudou tanto que o sistema atual resolve o problema errado.

Se você marcou menos de três, escolha outra estratégia.

O passo que ninguém pode pular

Antes de qualquer coisa: descubra as regras que estão escondidas no código.

Levante os relatórios que a operação usa de verdade, entreviste quem trabalha no sistema há mais tempo, olhe os casos estranhos e as exceções. Essa arqueologia leva de uma a três semanas e é o que separa uma modernização tranquila de um desastre.

Boa parte dessa descoberta se parece com a primeira etapa de qualquer projeto — vale ver como funciona um projeto sob medida.

Cuide dos dados desde o começo

Base antiga tem cliente duplicado, campo em branco, valor inconsistente e registro que ninguém sabe o que significa. Isso não aparece na demonstração — aparece na migração.

Faça o levantamento da qualidade dos dados na primeira semana, não na véspera da virada.

O caminho de menor risco

Se tivéssemos que resumir em quatro passos:

1. Descubra as regras escondidas.
2. Exponha uma API sobre o legado.
3. Substitua um módulo por vez, começando pelo menos crítico.
4. Desligue o antigo quando ele estiver vazio — não antes.

Você mantém a operação de pé o tempo todo e pode parar em qualquer ponto.

Tem um sistema antigo travando o negócio?

Descreva a situação — qual tecnologia, o que trava, o que precisa mudar. Devolvemos uma recomendação de estratégia, e ela pode muito bem ser "não reescreva, integre".