Quanto custa manter software legado na empresa?

Um sistema legado raramente aparece no orçamento como um único problema. Ele surge como horas extras da equipe, incidentes recorrentes, integrações que falham, demora para lançar produtos e decisões adiadas. Por isso, responder quanto custa manter software legado exige olhar além do contrato de suporte e da folha de pagamento de quem ainda conhece aquela tecnologia.

O custo real não é apenas técnico. É operacional e estratégico. Uma aplicação antiga pode continuar processando pedidos, faturando clientes ou sustentando uma operação interna. Mas, quando cada alteração simples vira uma negociação de prazo, risco e orçamento, o software deixa de apoiar o crescimento e passa a definir seus limites.

Quanto custa manter software legado na prática

O primeiro erro é tratar manutenção como uma despesa fixa e previsível. Parte dela é previsível: hospedagem, licenças, banco de dados, suporte de fornecedores e equipe dedicada. A outra parte aparece quando algo quebra, quando uma dependência deixa de ser atualizada ou quando uma área de negócio pede uma mudança que a arquitetura não comporta sem efeitos colaterais.

Em termos práticos, o custo anual de um legado costuma reunir cinco frentes: infraestrutura e licenças; manutenção corretiva; manutenção evolutiva; segurança e conformidade; e custo de oportunidade. As quatro primeiras são registradas no orçamento. A última, em geral, não.

Uma empresa pode gastar pouco para manter um sistema aparentemente estável e, ao mesmo tempo, perder receita porque não consegue lançar uma funcionalidade no momento certo. Pode também manter uma equipe cara não pela quantidade de entregas, mas porque apenas duas pessoas entendem regras críticas escondidas em código, planilhas e procedimentos manuais.

A pergunta correta não é apenas “quanto gastamos com esse sistema?”. É “quanto custa continuar operando dessa forma pelos próximos 12, 24 e 36 meses?”.

Custos diretos que devem entrar na conta

Comece pelo que é mensurável. Some salários ou contratos dos profissionais que mantêm a aplicação, custo de infraestrutura, ferramentas, licenças, fornecedores especializados, suporte de banco de dados e serviços de monitoramento. Inclua também as horas consumidas em atendimento a incidentes e correções emergenciais.

É comum subestimar esse bloco porque parte das pessoas alocadas ao legado também atua em outras demandas. Nesse caso, a empresa deve estimar a capacidade efetivamente consumida. Se 40% do tempo de um time é gasto apagando incêndios, investigando falhas ou dando suporte a uma tecnologia antiga, esse percentual é custo de sustentação, ainda que não exista um centro de custo específico para ele.

Também vale separar manutenção corretiva de evolutiva. Corrigir defeitos mantém a operação de pé. Evoluir o produto gera novas capacidades. Quando as duas atividades disputam a mesma equipe, a empresa pode acreditar que está investindo em inovação enquanto, na prática, está apenas preservando o funcionamento atual.

Custos ocultos que afetam margem e crescimento

Os custos ocultos são mais difíceis de atribuir, mas frequentemente definem a decisão. O principal deles é a lentidão para mudar. Uma alteração que deveria levar dias e leva semanas reduz a capacidade de testar ofertas, automatizar processos ou atender exigências de clientes.

Há ainda o retrabalho operacional. Sistemas legados costumam conviver com exportações manuais, conferências em planilhas, duplicidade de cadastro e reconciliações feitas por pessoas. Essas tarefas podem não estar classificadas como custo de tecnologia, mas existem porque a tecnologia não entrega o fluxo que a operação precisa.

Outro ponto é o risco concentrado em conhecimento individual. Quando o funcionamento de um processo crítico depende de um profissional específico, a empresa carrega um passivo operacional. Férias, desligamentos ou mudanças de prioridade podem transformar uma manutenção comum em uma parada relevante.

Segurança também precisa entrar na análise. Bibliotecas sem suporte, sistemas operacionais defasados, controles de acesso improvisados e ausência de rastreabilidade aumentam exposição. Modernizar não significa trocar toda a plataforma por uma tecnologia recente. Significa reduzir riscos de forma proporcional à criticidade do processo e às obrigações da empresa.

Como calcular o custo de manter um sistema legado

Não há uma fórmula universal, porque o contexto importa. Um ERP antigo que concentra faturamento exige uma análise diferente de um portal interno usado por poucas pessoas. Ainda assim, uma estrutura simples ajuda a transformar percepção em decisão.

Calcule o custo anual direto de sustentação e adicione o custo de capacidade bloqueada. Depois, estime as perdas operacionais associadas a falhas, atividades manuais e atraso em iniciativas prioritárias. Por fim, classifique os riscos de continuidade, segurança e dependência de pessoas de acordo com impacto e probabilidade.

O resultado não precisa fingir precisão absoluta. O objetivo é comparar cenários com critérios consistentes. Por exemplo: manter como está, estabilizar pontos críticos, modernizar por etapas ou substituir uma parte do sistema. Cada cenário deve trazer investimento, prazo, risco de transição, redução de custo recorrente e ganho operacional esperado.

Um exemplo de leitura financeira

Imagine uma plataforma interna que custa R$ 45 mil por mês entre equipe, infraestrutura e fornecedores. No papel, são R$ 540 mil por ano. Mas a operação também dedica quatro pessoas a conferências manuais, porque integrações falham e dados chegam incompletos. Além disso, a equipe de tecnologia deixa de executar automações comerciais porque metade da capacidade mensal é absorvida por chamados e correções.

O custo anual não é apenas R$ 540 mil. É a soma da sustentação, da mão de obra operacional criada pelas limitações do sistema e do valor das iniciativas que não avançam. Nem todo valor será convertido em reais com facilidade, mas ignorá-lo torna a comparação entre manter e modernizar artificialmente favorável ao status quo.

Manter, modernizar ou substituir: a decisão depende do gargalo

Substituir tudo pode ser caro, lento e arriscado. Manter tudo como está pode parecer econômico até o próximo incidente ou até a próxima exigência de negócio. Entre os dois extremos, há caminhos mais controlados.

A sustentação faz sentido quando o sistema é estável, tem baixo custo, atende ao processo atual e não bloqueia prioridades relevantes. Nesse caso, o foco deve ser documentar conhecimento, reforçar monitoramento, corrigir vulnerabilidades e evitar que a dívida técnica cresça sem controle.

A modernização gradual faz sentido quando o software continua crítico, mas limita integrações, escala ou velocidade de entrega. É possível isolar módulos, criar interfaces de integração, extrair regras de negócio e renovar partes específicas sem interromper toda a operação. Essa abordagem exige arquitetura clara. Migrar telas sem resolver dependências e regras escondidas apenas desloca o problema.

A substituição se justifica quando o custo de adaptação é maior do que o valor preservado, quando a tecnologia perdeu suporte efetivo ou quando o sistema já não representa o processo que a empresa quer operar. Mesmo nesse caso, a troca não deve começar pelo código. Deve começar pelo mapeamento de processos, dados, exceções e integrações que o sistema acumulou ao longo dos anos.

O diagnóstico evita uma modernização cara e mal direcionada

Empresas costumam pedir uma reescrita quando estão cansadas de incidentes. A insatisfação é legítima, mas reescrever sem diagnóstico pode replicar regras confusas, gargalos de processo e dependências que nunca foram documentadas.

Antes de decidir, é preciso identificar quais partes do legado sustentam diferenciais reais, quais existem apenas por herança e quais processos poderiam ser simplificados. Também é necessário entender o fluxo de dados, a criticidade de cada integração, os pontos de falha e a capacidade disponível para conduzir a transição.

Esse trabalho estabelece uma sequência. Talvez a prioridade seja uma camada de integração para eliminar trabalho manual. Talvez seja retirar uma regra crítica de um ambiente sem suporte. Talvez seja criar uma nova operação em paralelo e migrar grupos de usuários com controle. O caminho certo depende do impacto, não da idade do código isoladamente.

Na Devio, esse tipo de decisão começa pela arquitetura do problema. O objetivo não é vender uma troca de tecnologia, mas definir onde a engenharia reduz custo, risco e dependência com mais velocidade.

O custo que importa é o da imobilidade

Software legado não é, por definição, software ruim. Muitas empresas ainda operam sistemas antigos porque eles resolvem processos valiosos e carregam conhecimento acumulado. O problema começa quando manter o sistema consome a capacidade necessária para evoluir a empresa.

A melhor decisão não é a mais agressiva nem a mais conservadora. É aquela baseada em um diagnóstico honesto dos custos diretos, dos gargalos invisíveis e do que a operação precisa entregar nos próximos ciclos. Quando essa conta fica clara, modernização deixa de ser uma aposta tecnológica e passa a ser uma decisão de negócio.