Sistemas legados raramente falham de uma vez. Eles começam cobrando juros em lugares pequenos: uma entrega que precisa de três aprovações manuais, um deploy que depende de uma pessoa específica, uma integração que ninguém quer tocar, um relatório que demora o suficiente para virar planilha paralela.
O problema não é a idade do código. Código antigo, com fronteiras claras e operação previsível, pode continuar gerando valor por anos. O problema aparece quando o sistema deixa de aceitar mudança sem espalhar risco pelo negócio.
O sinal não é técnico apenas#
Uma reescrita só faz sentido quando existe um custo operacional visível. Alguns sinais costumam justificar uma investigação séria:
- cada nova funcionalidade exige alterar módulos sem relação direta com a demanda;
- incidentes voltam no mesmo ponto porque a causa raiz fica escondida;
- o time evita mexer em partes críticas por falta de testes, logs ou donos claros;
- regras comerciais importantes vivem em código, planilhas e decisões manuais ao mesmo tempo;
- o sistema impede medir margem, prazo, cobrança ou qualidade da entrega.
Se o impacto ainda é só incômodo de engenharia, estabilizar pode ser melhor. Se o impacto já trava receita, atendimento ou decisão executiva, a conversa muda.
Três caminhos antes da reescrita total#
O primeiro caminho é estabilizar. Ele serve quando o produto ainda funciona, mas falta visibilidade: logs úteis, testes nos fluxos críticos, backups testados, monitoramento e um mapa das dependências reais. Estabilizar compra clareza.
O segundo caminho é fatiar. Em vez de trocar tudo, uma fronteira de negócio vira um serviço, módulo ou fluxo novo. A escolha boa não é a fronteira mais elegante; é a que reduz risco sem forçar migração completa.
O terceiro caminho é reescrever. Ele só deve entrar quando a arquitetura atual impede evolução relevante ou quando o custo de preservar compatibilidade é maior que o custo de migrar com controle.
O critério de decisão#
Uma reescrita responsável precisa responder quatro perguntas antes da primeira sprint:
- qual capacidade de negócio fica melhor depois da mudança;
- qual parte continua funcionando durante a migração;
- quais dados precisam ser preservados, reconciliados ou descartados;
- como o sistema novo será validado contra a operação real.
Sem essas respostas, a reescrita vira aposta. Com elas, vira uma sequência de cortes verificáveis.
Um bom primeiro passo#
Antes de decidir "reescrever ou não", faça um inventário curto: os cinco fluxos que mais geram receita, os três pontos de maior incidente, os dados que não podem ser perdidos e as integrações que parariam a operação se falhassem.
Esse mapa costuma mostrar se o problema pede estabilização, extração gradual ou reescrita.
Fale com a CognixSE para avaliar esse diagnóstico com foco em risco, arquitetura e impacto de negócio.