Refatorar, reescrever ou substituir? A matriz decisória técnico-comercial para CTOs e CEOs antes de mexer no legado

Refatorar, reescrever ou substituir não é uma discussão puramente técnica. É uma escolha de alocação de caixa, foco do time e velocidade de execução. Quando a empresa já sente atraso no roadmap, incidentes recorrentes ou dificuldade para atender clientes maiores, o legado deixa de ser um assunto de arquitetura e passa a afetar receita, churn e captação. Na prática, a pergunta certa não é “qual é a solução mais elegante?”, mas “qual caminho preserva o negócio com o menor risco total?”. Em empresas que crescem rápido, é comum ver o CTO defender a sustentabilidade da base e o CEO pressionar por velocidade. Essa tensão é natural. O erro está em tratá-la como disputa pessoal, quando na verdade ela exige uma matriz decisória objetiva. A Orbe Soft costuma começar esse tipo de análise com discovery de mercado e operação antes de propor qualquer mudança. Faz sentido, porque uma base antiga pode estar tecnicamente ruim e, ainda assim, continuar adequada ao momento da empresa. Também pode parecer “estável” por fora, mas estar travando o time por dentro. Um bom diagnóstico separa percepção de evidência e evita decisões caras baseadas em impressão. Se você quer aprofundar a lógica por trás da priorização, vale cruzar esta leitura com o guia de backlog técnico orientado por valor, porque a decisão sobre legado quase sempre compete com outras demandas do roadmap. E, se o seu sistema já virou gargalo estrutural, o blueprint de arquitetura modular para reduzir time-to-market ajuda a enxergar o tipo de evolução que costuma destravar escala sem reconstrução desnecessária.

Uma boa matriz decisória cruza duas dimensões. De um lado, a complexidade técnica: arquitetura, acoplamento, cobertura de testes, observabilidade, segurança, integrações e risco de regressão. Do outro, a pressão de negócio: urgência do roadmap, impacto em receita, risco de churn, exigência de compliance, janela de captação e dependência de cliente estratégico. Quando a complexidade técnica é média e o impacto de negócio é baixo, refatorar costuma ser suficiente. Quando a complexidade é alta, mas o sistema ainda entrega valor central e o risco de troca total é grande, o caminho preferencial tende a ser reescrever em partes, com migração incremental. Quando a base está tão acoplada que a empresa já não consegue evoluir sem paradas longas, e o custo de manter o legado supera o custo de migração, a substituição ganha força. O ponto crítico é não analisar apenas custo de desenvolvimento. O que precisa entrar na conta é custo de oportunidade. Um sistema que consome dois meses do time por trimestre em manutenção reduz a capacidade de lançar novas features, de atender clientes maiores e de responder a mudanças de mercado. Isso aparece como atraso, mas também como perda de margem, desgaste do time e maior risco de exceção operacional. Em projetos enterprise, essa conta fica mais clara quando usamos um discovery de mercado antes da linha de código. Primeiro, definimos o que o produto precisa provar para o mercado. Depois, mapeamos o esforço técnico necessário para sustentar essa promessa. Essa ordem evita um erro comum: reescrever uma plataforma inteira para resolver dores que talvez fossem atendidas com modularização, governança de releases e uma camada de integração melhor. Se o seu contexto envolve inovação financiada, o artigo sobre como estruturar pilotos que comprovem entregáveis para FAPESC, FINEP e BNDES também ajuda a traduzir decisão técnica em evidência para comitês e avaliadores.

Muitos times tentam decidir pela obra mais barata no curto prazo. Esse atalho é perigoso, porque refatorar apenas pelo custo inicial pode adiar a resolução de um problema estrutural, enquanto reescrever por impulso pode consumir caixa sem garantir melhora real. O cálculo correto precisa incluir custo direto, custo de atraso e custo de risco. Custo direto é o que sai do orçamento agora: time, nuvem, QA, gestão e eventual apoio externo. Custo de atraso é o valor perdido enquanto a empresa não lança o que poderia lançar, não vende para o cliente que está esperando ou não retém o cliente que já reclama de performance. Custo de risco é o efeito de um incidente, de um retrabalho grande ou de uma regressão que derruba a confiança do mercado. Na prática, vale montar uma planilha simples com quatro colunas: investimento inicial, economia esperada de manutenção, impacto no roadmap e risco residual. Em vários casos, a liderança descobre que a solução “mais barata” é a mais cara depois de 12 meses. Isso acontece porque legado não é só TI atrasada, é margem corroída em parcelas pequenas e constantes. Se você precisa transformar essa discussão em linguagem de diretoria, o artigo sobre O que são OPEX e CAPEX: definição, diferenças e exemplos essenciais para decisões de tecnologia ajuda a organizar a conversa financeira sem jargão. E, quando o assunto envolve contratar gente ou alocar um squad para acelerar a mudança, vale cruzar com a matriz prática de escolha entre alocação de equipe, staff augmentation ou projeto fechado por estágio de produto.

A melhor forma de mudar legado quase nunca é “big bang”. O caminho mais seguro costuma ser migrar por camadas, começando pelos pontos de maior dor e menor dependência. Isso permite validar a nova arquitetura sem expor a operação inteira a um corte abrupto. Em empresas com alta disponibilidade, esse cuidado não é luxo. É requisito para não transformar melhoria técnica em incidente de produção. Há três padrões que costumam funcionar bem. O primeiro é o strangler pattern, no qual a nova solução vai substituindo partes da antiga gradualmente. O segundo é o uso de feature flags e roteamento controlado para ligar e desligar funções sem reconstruir tudo de uma vez. O terceiro é a criação de uma camada de integração para isolar o legado enquanto a lógica nova amadurece. Antes de cada etapa, defina uma métrica de segurança. Pode ser taxa de erro, tempo de resposta, volume de chamados, latência de integração ou sucesso de transações críticas. Se a métrica piorar além do limite acordado, o rollback precisa ser rápido e claro. Mudança sem monitoramento detalhado é aposta, não engenharia. Para quem precisa de uma visão mais madura de operação, o guia prático de observabilidade para produtos digitais com IA traz uma boa base de métricas, tracing e runbooks que também servem para sistemas legados em migração. Em programas mais complexos, uma equipe sênior dedicada, como a Orbe Soft costuma estruturar, ajuda a fazer essa transição com menos ruído porque combina arquitetura, QA e entrega incremental no mesmo fluxo.

O erro mais comum é reescrever por cansaço. Quando o time sofre com a base antiga, a reescrita total parece libertadora. Só que sistemas antigos geralmente carregam exceções, regras de negócio e comportamentos de borda que não estão documentados. Se tudo isso for reconstruído sem descoberta real, a empresa troca um problema conhecido por uma incerteza cara. Outro erro é refatorar sem meta clara. O time mexe, melhora um trecho, mas não altera o indicador que motivou a decisão. Isso gera sensação de progresso sem resultado prático. Em poucos meses, a liderança conclui que o esforço foi “técnico demais” e perde confiança em futuras iniciativas de modernização. Também é comum subestimar a governança. Uma migração sem alinhamento entre CEO, CTO, produto e operação cria conflito interno, porque cada área mede sucesso de forma diferente. O CEO quer velocidade e previsibilidade. O CTO quer estabilidade. Produto quer roadmap. Operação quer menos incidente. A matriz decisória serve justamente para evitar que cada área defenda um pedaço do problema como se fosse o todo. Quando essa tensão fica intensa, faz diferença trabalhar com um parceiro que saiba pensar como sócio, não apenas como fornecedor. É aí que a Orbe Soft costuma ser acionada em projetos complexos, especialmente quando o objetivo é reduzir risco de mudança e não só produzir código. Em vez de empurrar uma resposta única, o processo parte de evidência, artefatos e validação incremental.