7 sinais de que seu sistema legado .NET já está custando mais do que deveria

1. Cada deploy parece um evento de risco

Quando publicar virou tensão, o problema não é apenas processo. Em geral existe acoplamento alto, falta de teste confiável e pouca observabilidade. Esse medo trava evolução e deixa manutenção mais cara do que parece.

2. O backlog anda mais devagar a cada mes

O time entrega menos não porque ficou pior, mas porque cada alteração exige mais análise, mais validação manual e mais cuidado com efeito colateral. É um sinal clássico de que a base perdeu capacidade de evolução.

3. Poucas pessoas concentram o conhecimento do sistema

Dependência de pessoa-chave é um dos maiores riscos de um sistema legado .NET. Quando o conhecimento não está bem distribuído, qualquer saída, férias ou prioridade concorrente aumenta custo e reduz previsibilidade.

4. Integrações simples ficaram demoradas demais

Quando integrar ERP, CRM, portal, parceiro ou automação virou mini projeto de alto risco, a arquitetura deixou de ajudar o negócio. Nessa hora, consultoria .NET e modernização de sistema legado .NET costumam ser o ponto mais racional de partida.

5. Correção urgente sempre vence evolução real

Se o time vive reagindo a incidente, demanda crítica e regressão, a manutenção virou modo de sobrevivência. Isso consome energia que deveria estar indo para ganho operacional, automação e novos fluxos.

6. Escalar volume piora desempenho e operação

O aumento de usuários, transações ou integrações faz a aplicação sofrer. O efeito pode aparecer em banco, API, fila ou módulo monolítico sensível. Continuar adiando ajuste estrutural só aumenta o custo futuro.

7. O sistema impede novas iniciativas do negócio

Quando uma nova jornada, novo canal ou nova regra comercial esbarra na incapacidade do sistema de responder, o legado já virou problema de receita e não só de TI.

Como transformar esses sinais em número

Reconhecer os sinais é fácil. O difícil é sustentar orçamento com eles — "o sistema está ruim" não passa em comitê. Quatro medições transformam percepção em argumento, e nenhuma exige ferramenta nova:

• Lead time de alteração — do pedido aprovado até estar em produção. Pegue as últimas 10 demandas e tire a mediana. Acima de duas semanas para mudança pequena indica base travada.
• Taxa de falha em mudança — quantos deploys dos últimos três meses geraram correção emergencial. Acima de 15% é sinal de rede de testes insuficiente.
• Horas em incidente — some as horas do time em correção urgente no último trimestre e multiplique pelo custo-hora. Esse é o número que a diretoria entende.
• Fator caminhão — quantas pessoas precisariam sair para travar um módulo crítico. Se a resposta for "uma", você tem risco operacional, não questão técnica.

Meça antes de propor qualquer projeto. Sem linha de base, não há como provar depois que a modernização funcionou.

O custo invisível: o que não aparece na planilha

O gasto direto com manutenção é o que todo mundo vê. Ele raramente é a maior parte da conta.

O custo de oportunidade costuma superá-lo: a integração com o parceiro novo que levou seis meses em vez de seis semanas, o canal de venda que não abriu, a automação que ficou no backlog. Nada disso aparece como despesa — aparece como receita que não veio, e por isso ninguém atribui ao sistema.

Há também o custo de retenção. Pessoa técnica boa não pede demissão por salário apenas; pede por passar o dia apagando incêndio em código que ninguém entende. Substituir um desenvolvedor sênior custa meses de produtividade, e a saída dele leva junto o conhecimento que não estava documentado — realimentando o sinal 3.

Sinais que parecem problema, mas não são

Nem todo desconforto com o sistema justifica investimento. Três casos em que o incômodo é real mas a ação não se paga:

• "O código é feio" — se o módulo é estável, quase não muda e não gera incidente, ele está fazendo o trabalho dele. Código antigo que funciona é software amortizado, não dívida.
• "A tecnologia é antiga" — versão desatualizada só vira problema quando bloqueia integração, impede contratação ou saiu do suporte de segurança. Fora disso, é preferência.
• "O time quer usar algo novo" — motivação importa, mas troca de stack sem resolver acoplamento e ausência de testes entrega o mesmo problema com sintaxe diferente.

O critério que separa os dois grupos é sempre o mesmo: existe custo mensurável hoje? Se a resposta honesta for não, o projeto é estética cara.

Reconheceu três ou mais? O que fazer agora

Um sinal isolado pode ser fase ruim. Três ou mais simultâneos indicam que a base perdeu capacidade de evolução, e a tendência é piorar — cada mês adia mais e encarece a correção.

O erro comum nessa hora é partir para a reescrita total. Ela parece resolver tudo de uma vez e, na prática, cria seis a dezoito meses sem entrega enquanto o legado continua sustentando a operação. O caminho com melhor histórico é o inverso: modernizar por etapas, sem reescrever tudo, começando pelo que custa caro agora.

Na prática isso significa: medir os quatro indicadores acima, escolher o módulo que aparece ao mesmo tempo na lista de "mais alterado" e "mais gera incidente", cobrir esse módulo com testes de caracterização e só então mexer. Se quiser a mecânica detalhada, ela está em refatoração progressiva em .NET.

Perguntas frequentes

Quantos sinais indicam que é hora de modernizar?

Três ou mais simultâneos, com custo mensurável associado. Um sinal isolado pode ser fase de projeto ou pico de demanda. O que caracteriza legado problemático é a combinação persistente: deploy tenso, backlog lento e conhecimento concentrado costumam aparecer juntos.

Sistema legado é sempre sistema antigo?

Não. Legado é sistema que você tem medo de mudar, independente da idade. Existe código de dois anos que ninguém toca sem suar, e sistema de quinze anos com boa cobertura de testes que evolui tranquilo. A idade não é o critério — a capacidade de alterar com segurança é.

Como calcular o custo de manter o legado?

Some três parcelas: horas do time em manutenção e incidente no trimestre, custo de oportunidade das iniciativas que não avançaram por limitação do sistema, e risco de concentração de conhecimento. A primeira está no seu registro de horas; a segunda você estima com a área de negócio; a terceira é qualitativa mas decisiva.

Vale a pena modernizar ou é melhor comprar um sistema pronto?

Depende de quanto do seu processo é diferencial competitivo. Se a operação roda como a do concorrente, software de prateleira tende a sair mais barato. Se a regra de negócio acumulada no legado é parte do que faz a empresa ganhar dinheiro, trocá-la por um produto genérico significa perder isso — e voltar a construir por fora, com integrações.

Quanto tempo leva para reverter esse quadro?

Os primeiros indicadores costumam responder em semanas quando se ataca o módulo certo — especialmente taxa de falha em deploy, que melhora assim que existe cobertura de teste. Lead time leva mais tempo porque depende de reduzir acoplamento. O que não funciona é esperar resultado sem entrega intermediária: se o plano só mostra ganho no final, ele é reescrita com outro nome.