Reescrever ou refatorar um sistema legado? O critério que usamos

Toda equipe que herda um sistema antigo chega ao mesmo impasse: o código dá medo, cada entrega demora mais que a anterior, e alguém propõe começar do zero. A proposta é sedutora porque a reescrita existe só na imaginação — e software imaginário não tem bug, não tem prazo e não tem regra de negócio esquecida em um if de 2019.

Este texto é o critério que aplicamos antes de recomendar qualquer coisa a um cliente.

Por que a reescrita total quase sempre decepciona

O sistema em produção carrega anos de conhecimento que não está documentado em lugar nenhum. Aquela condição estranha no cálculo de frete existe porque um cliente grande negociou uma exceção em 2021. O retry esquisito na integração bancária existe porque o banco derruba a conexão às terças de madrugada.

Nada disso está escrito. Está no código, disfarçado de gambiarra.

Quando você reescreve do zero, três coisas acontecem ao mesmo tempo:

1. O sistema antigo continua mudando. O negócio não congela porque a TI decidiu reescrever. Você agora mantém duas bases.
2. As regras não documentadas somem. Elas voltam como incidente, uma a uma, depois do lançamento — e sempre com um cliente irritado junto.
3. O prazo estoura. Não porque a equipe é ruim, mas porque a estimativa foi feita contra o sistema que você imagina, não contra o que existe.

A reescrita não é errada por princípio. É errada como reflexo.

Os quatro sinais que realmente indicam reescrita

Recomendamos reescrever quando pelo menos dois destes são verdadeiros:

A plataforma base saiu de suporte e não tem caminho de atualização. Não é "está velha" — é que uma vulnerabilidade crítica não terá correção, e não existe upgrade incremental possível. Aqui a decisão é de risco, não de gosto.

O custo de rodar supera o custo de substituir. Licença, hardware específico, ou o único fornecedor que ainda mantém aquilo cobrando o que quer. Isso é uma conta, e ela fecha ou não fecha.

Não existe mais ninguém que saiba manter, e o mercado não oferece. Um sistema em Delphi 5 com o autor aposentado é um risco de continuidade. Reescrever é caro; ficar refém é pior.

O modelo de domínio está errado, não só o código. Este é o mais sutil e o mais decisivo. Se o sistema foi construído assumindo "um cliente tem um endereço" e o negócio hoje é multinacional com múltiplas filiais, nenhuma refatoração conserta — a premissa está na estrutura das tabelas, no formato das APIs e na cabeça de quem usa.

Repare que "o código é feio", "usa uma biblioteca que eu não gosto" e "a equipe nova não quer mexer" não estão na lista. São problemas reais, mas se resolvem com refatoração e disciplina, não com reescrita.

O caminho do meio: estrangulamento

Na prática, a maioria dos casos que atendemos termina no padrão strangler fig — o nome vem da figueira que cresce em volta de uma árvore hospedeira até substituí-la por inteiro.

Funciona assim:

1. Coloque uma fronteira na frente do sistema antigo. Um proxy reverso, um gateway de API, qualquer ponto único por onde o tráfego passe.
2. Escolha um contexto pequeno e de borda. Emissão de relatório, notificação, um cadastro auxiliar. Nunca comece pelo núcleo transacional.
3. Implemente esse contexto no sistema novo e mande o tráfego dele pela fronteira.
4. Repita, um contexto por vez, medindo depois de cada passo.
5. Desligue o antigo quando não sobrar tráfego — o que pode levar anos, e tudo bem.

A vantagem é brutal: você entrega valor em semanas, não em trimestres, e cada passo é reversível. Se o contexto novo dá problema, você redireciona o tráfego de volta enquanto conserta. Numa reescrita big bang, o único ponto de reversão é "cancelar o projeto inteiro".

O custo é real: durante a transição existem dois sistemas, e alguém precisa manter a fronteira coerente. Vale a pena mesmo assim, porque o risco fica distribuído em pedaços que cabem na cabeça de uma pessoa.

Antes de decidir: meça

Nenhuma dessas decisões deve ser tomada por sensação. Antes de recomendar qualquer coisa, levantamos números concretos:

• Tempo entre commit e produção. Se leva três semanas, o problema pode ser o pipeline, não a arquitetura.
• Percentual de incidentes por módulo. Costuma revelar que 80% da dor vem de 15% do código — e esse recorte é o que deve ser atacado primeiro.
• Cobertura de teste nos caminhos críticos. Sem isso, qualquer mudança estrutural é aposta.
• Frequência de mudança por arquivo. Arquivos que mudam toda semana e são gigantes concentram acoplamento. git log te dá esse mapa de graça.
• Tempo para um desenvolvedor novo rodar o sistema. Se passa de um dia, existe uma dívida de ambiente que atrapalha qualquer plano.

Esses cinco números costumam mudar a conversa. Já aconteceu de um cliente chegar decidido a reescrever e sair com um plano de três meses de refatoração focada, porque a dor real estava em dois módulos e num pipeline de deploy quebrado.

O erro de enquadramento mais comum

"Reescrever ou refatorar" é uma pergunta ruim porque trata o sistema como um bloco único. Sistemas não são homogêneos: o módulo de faturamento pode estar impecável enquanto o de relatórios é um pântano.

A pergunta melhor é: qual pedaço, e por quê?

Responder isso exige olhar o código com método, e é exatamente o que fazemos em um diagnóstico de arquitetura — duas a três semanas, sem compromisso de contratar a execução depois. O resultado é um relatório com riscos ordenados por custo, e em boa parte das vezes ele recomenda algo mais barato do que o cliente esperava ouvir.

Se você está nessa decisão agora, conte o contexto para a gente. Uma conversa de uma hora costuma economizar meses.