Quanto custa não mexer no seu sistema legado?

Stalebu Connections
há 7 dias
9 min de leitura

A maioria das empresas não calcula o custo de inação.

Mas dívida técnica acumula juros, e a conta sempre chega no pior momento.

Este artigo coloca números reais nessa equação e mostra quando modernizar deixa de ser custo e vira obrigação estratégica.

Stalebu Gestão de TI · Estratégia · Por: Stanley R Souza

Numa conversa de diagnóstico recente, encontramos uma empresa de médio porte que gastava R$ 45 mil por mês em manutenção corretiva, sem ter clareza disso. O sistema de gestão tinha sido construído há nove anos. Só um desenvolvedor entendia o código central. Toda nova funcionalidade levava três semanas porque qualquer mudança exigia trabalhar em volta de uma arquitetura que ninguém mais queria tocar.

O CEO achava que o problema era falta de gente. O problema era o sistema. Caso real, dados preservador. Diagnó stico Stalebu, 2025.

Essa situação é mais comum do que parece. E o que ela revela é sempre o mesmo: a decisão de não modernizar tem um custo real, crescente, que quase nunca aparece numa linha de orçamento.

Ele se esconde no tempo perdido dos desenvolvedores, nas horas de manutenção de emergência, nos clientes que não voltam depois de uma instabilidade, nas oportunidades que não foram aproveitadas porque o sistema não suportava. E mais: no crescimento que sua empresa não realizou porque a tecnologia não acompanhava o ritmo do negócio.

Este artigo existe para dar nome e número a esse custo.

Para que da próxima vez que a pergunta "vale a pena modernizar?" aparecer na mesa, a resposta não seja uma intuição, seja uma decisão informada.

O primeiro passo para responder essa pergunta é saber o que você tem hoje. A maioria das empresas não sabe, e esse é exatamente o ponto de partida do Diagnóstico de Legado da Stalebu.

Dívida técnica não é metáfora. É matemática.

O conceito de "dívida técnica" foi cunhado pelo engenheiro Ward Cunningham nos anos 1990 para descrever o custo futuro de escolhas de desenvolvimento feitas por conveniência presente. Assim como uma dívida financeira, ela tem principal e juros.

O principal é o trabalho que ficou por fazer: o código escrito rápido demais, a arquitetura nunca refatorada, a documentação que nunca existiu, os testes que foram pulados. O juro é o custo crescente de trabalhar sobre esse código, cada nova funcionalidade fica mais cara, cada bug demora mais para ser corrigido, cada desenvolvedor novo leva meses para entender o sistema.

A dívida técnica não para de crescer enquanto você não toma uma decisão ativa sobre ela. E os juros compostos da tecnologia são brutais.

Benchmarks de mercado amplamente reportados pela indústria sugerem que o custo de manutenção de sistemas mais antigos pode representar entre 15% e 40% do orçamento total de TI de uma organização, com a parcela crescendo à medida que o sistema envelhece sem modernização estrutural.

Para sistemas com mais de 10 anos sem evolução arquitetural significativa, esse número tende a ultrapassar a metade do orçamento disponível.

Traduzindo: a cada R$ 100 que sua empresa investe em TI, parte expressiva pode estar indo para sustentar algo que deveria ter sido evoluído, em vez de construir algo novo.

Os cinco custos que não aparecem no orçamento

O problema com o custo da inação é que ele se distribui por vários centros de custo, e nenhum deles se chama "custo do legado". Ele se esconde em outros lugares:

🐌 Velocidade de desenvolvimento em queda Cada nova funcionalidade fica mais cara porque o desenvolvedor precisa respeitar uma arquitetura antiga. O que levava 2 dias passa a levar 2 semanas. Esse delta raramente aparece numa planilha, mas impacta diretamente a competitividade.	🔥 Custo de incidentes e emergências Sistemas com dívida técnica acumulada falham de formas imprevisíveis. Correções de emergência custam significativamente mais do que manutenções planejadas, sem contar perda de clientes e impacto de imagem durante a instabilidade.
🧠 Dependência de pessoas específicas Quando o único desenvolvedor que entende o sistema vai embora, ele leva consigo conhecimento que não está documentado em lugar nenhum. O custo de retenção desse profissional, e de reposição quando ele sair, é frequentemente subestimado.	🔒 Vulnerabilidades de segurança crescentes Frameworks e bibliotecas antigas deixam de receber patches de segurança. A cada mês sem atualização, a superfície de ataque cresce. O custo de um vazamento de dados, incluindo implicações da LGPD, pode ser catastrófico e muito superior ao custo de modernização.
😤 Moral e rotatividade da equipe Desenvolvedores bons não querem trabalhar indefinidamente em sistemas antigos sem perspectiva de evolução. Rotatividade tem custo direto: recrutamento, onboarding e perda de produtividade durante a transição, além do custo de conhecimento perdido.	📉 Crescimento bloqueado pela tecnologia O concorrente lança uma integração em três semanas. Você levaria seis meses, porque o sistema legado não suporta a conexão necessária. Esse custo de oportunidade raramente é quantificado, mas é real e crescente.

Um caso concreto: a modernização paga mais do que custa

A melhor forma de entender o custo da inação é observar o que acontece quando uma empresa decide agir, de forma incremental, sem parar a operação.

Caso Real

🇧🇷 Brasil · Low-Code · Modernização incremental

Proptech Rooftop

A Rooftop precisava analisar um volume crescente de imóveis, mas o processo era majoritariamente manual, lento e dependente de poucas pessoas.

Em vez de substituir o sistema central, a empresa optou por uma abordagem incremental: preservar o núcleo existente e automatizar camadas operacionais via Low-Code, integrando fontes de dados imobiliários que antes eram acessadas manualmente.

O resultado foi uma mudança de escala sem mudança de equipe, e sem o risco de uma substituição completa. O sistema legado continuou funcionando. A automação foi construída sobre ele, não no lugar dele.

4.000

imóveis analisados por ano com equipe reduzida

3.800h

de trabalho manual eliminado

R$ 1,2M

em custo operacional reduzido

O ponto central desse caso não é o número final, é o método. A Rooftop não precisou de um grande projeto de substituição, não precisou parar a operação, não precisou reescrever tudo do zero.

Precisou entender o que existia, identificar onde a automação traria retorno imediato e construir sobre o que já funcionava.

Esse é o princípio da modernização incremental, e é exatamente o oposto do que a maioria das consultorias recomenda.

O custo invisível das oportunidades perdidas

Muito do debate sobre legado foca em custos de manutenção e risco de incidente. Esses são argumentos válidos, mas para muitos executivos, o argumento mais poderoso é diferente: quanto de receita você deixou de gerar?

Empresas compram crescimento mais facilmente do que compram prevenção.

E sistemas legados bloqueiam crescimento de formas muito concretas:

🚀 Funcionalidades lançadas mais devagar Cada semana de atraso num lançamento tem um custo de mercado. Se o seu concorrente entrega em três semanas o que você entrega em três meses, a diferença não é só de tempo, é de clientes conquistados por ele antes de você. ↑ Impacto direto em receita e market share	🔗 Integrações que não acontecem Sistemas de CRM, ERP, marketplaces e plataformas de pagamento têm APIs. Sistemas legados frequentemente não conseguem se conectar, e impede automações na redução do ciclo de venda e aumento da retenção ↑ Automações comerciais bloqueadas
📊 Dados que existem mas não são usados Sistemas legados frequentemente acumulam dados valiosos que nunca foram estruturados para análise. Essa inteligência, sobre comportamento de clientes, padrões operacionais, gargalos de processo, existe, mas está presa em formatos inacessíveis. ↑ Decisões tomadas sem dados relevantes	🎯 Fintech Delhi Crescer para novos mercados, lançar novos produtos ou atender uma demanda repentina exige que a tecnologia escale. Sistemas legados frequentemente não escalam sem intervenção manual cara, o que transforma crescimento em problema, não em oportunidade. ↑ Teto de crescimento imposto pelo sistema

O argumento mais forte para modernizar não é o custo de manutenção que você vai eliminar. É o crescimento que você vai conseguir realizar.

A conta que ninguém fez na última reunião de budget

Vamos fazer um exercício de TCO (Custo Total de Propriedade) para uma empresa hipotética de médio porte: sistema com 8 anos, 5 desenvolvedores, orçamento mensal de TI em torno de R$ 80 mil.

Os valores abaixo são estimativas baseadas em padrões observados em diagnósticos, não em fórmulas universais, já que cada caso é diferente.

Item de custo	Inação (24 meses)	Modernização incremental
Manutenção e suporte corrente	~R$ 384k (custo crescente)	~R$ 192k (custo estabilizado)
Incidentes e emergências	~R$ 100–150k (estimado)	~R$ 40–60k (redução esperada)
Perda de velocidade de entrega	~R$ 180–220k (2× mais lento)	~R$ 80k
Rotatividade de equipe técnica	~R$ 80–100k por saída	Redução esperada
Custo do projeto de modernização	R$ 0	~R$ 150–200k
Estimativa total (24 meses)	R$ 750–870k	R$ 460–530k

Estes são cenários estimativos para fins de raciocínio. Os números reais dependem do diagnóstico específico do seu sistema, tamanho da base de código, nível de dívida técnica existente, setor de atuação e histórico de incidentes.

A diferença estimada de R$ 220–340 mil em 24 meses não considera os custos de oportunidade, funcionalidades não lançadas, clientes não conquistados, nem os custos de conformidade regulatória. Em setores como saúde e financeiro, um único incidente de segurança pode custar o equivalente a vários anos de modernização.

+60%

dos projetos de substituição completa excedem o orçamento original, segundo pesquisas da indústria

Gartner, referências de mercado

5–15×

mais caro corrigir um problema em produção do que identificá-lo antes, padrão amplamente observado na indústria

Padrão de mercado em engenharia de software

2–3×

mais tempo de onboarding para novos desenvolvedores em sistemas sem documentação adequada, observação em diagnósticos Stalebu

Diagnósticos Stalebu, 2024/2025

Os sinais que indicam que a conta já está vencendo

Não existe um momento único em que a dívida técnica "estoura". Ela se manifesta em sinais que, isoladamente, parecem pequenos, mas que, somados, indicam que o sistema está consumindo mais do que deveria.

🔴 Sinal crítico: Quando a equipe de TI gasta mais tempo em manutenção corretiva (apagar incêndios) do que em manutenção evolutiva (construir coisas novas), o sistema deixou de ser um ativo e virou um passivo operacional. Esse é o momento em que a modernização deixa de ser uma escolha e vira uma obrigação.

Outros sinais frequentes que encontramos nos diagnósticos: tempo de onboarding de novos desenvolvedores acima de 2–3 meses para entender o sistema; incapacidade de estimar com precisão o esforço de novas funcionalidades; resistência da equipe técnica a qualquer mudança no código central; dependência de versões de linguagem ou bibliotecas fora do suporte oficial; ausência de testes automatizados cobrindo o core do sistema.

Quando agir, e como priorizar

Nem todo sistema legado precisa de ação imediata. A prioridade depende de três fatores: criticidade para o negócio, custo atual de manutenção e janela de risco. A matriz abaixo é um ponto de partida, não um diagnóstico definitivo.

Referência para priorização de modernização
Manutenção acima de 35% do orçamento de TI e incidentes frequentes	O custo da inação provavelmente já supera o custo do projeto. Iniciar diagnóstico imediatamente.	Agir agora
Manutenção entre 20–35% e velocidade de entrega comprometida	Planejar modernização nos próximos 6–12 meses. Começar pelo mapeamento técnico.	Planejar
Manutenção abaixo de 20% e sistema estável com evolução possível	Monitorar indicadores. Investir em documentação e cobertura de testes preventivamente.	Monitorar
Sem documentação + desenvolvedor - chave sem sucessor identificado	Risco crítico independente do custo atual. Iniciar mapeamento técnico imediatamente.	Risco crítico

As perguntas que seu próximo budget precisa responder

Da próxima vez que a discussão de orçamento chegar e alguém sugerir "vamos deixar o legado para o próximo ano", essas perguntas mudam a conversa:

Perguntas para levar para a reunião de budget

1 Qual percentual do nosso orçamento de TI vai para manutenção vs. desenvolvimento de novas capacidades?

Se o número de manutenção for acima de 30%, você está pagando por modernização sem receber nada em troca.

2 Quanto tempo leva para um novo desenvolvedor conseguir trabalhar de forma autônoma no sistema?

Se for acima de 2 meses, você tem um problema de documentação e complexidade acidental que está custando dinheiro todo mês.

3 Qual foi o custo total dos últimos dois incidentes de produção?

Some o tempo de engenharia, o impacto em clientes e o custo de imagem. Compare com o custo de um projeto de modernização incremental.

4 Quantas funcionalidades ou integrações ficamos de fora nos últimos 12 meses porque o sistema não suportava?

Esse é o custo de oportunidade, e frequentemente é maior do que todos os outros custos somados.

Se você não tem essas respostas, esse é o primeiro problema a resolver. Porque a maioria das empresas que chegam ao Diagnóstico Stalebu não sabe qual é sua dívida técnica atual , e essa falta de clareza é, em si, um risco de gestão.

Sistemas legados não precisam ser jogados fora. Precisam ser entendidos, evoluídos e integrados com inteligência.

A modernização incremental, evoluir o sistema que existe, camada por camada, sem parar a operação, é consistentemente mais barata, mais segura e mais rápida do que substituição total.

O caso da Rooftop ilustra exatamente isso: preservou o núcleo, automatizou as bordas, entregou resultado em meses.

A IA, nesse processo, não é o substituto do sistema legado. É o acelerador da sua evolução: mapeando estruturas existentes, gerando código de refatoração, documentando o que nunca foi documentado, identificando riscos antes que virem incidentes.

Descubra qual é a sua dívida técnica real.

O Diagnóstico começa com uma conversa de 45 minutos. A partir dela, definimos o escopo do mapeamento real, e você decide se quer continuar.

Agendar Diagnóstico de Legado gratuito →

Sem compromisso. Sem enrolação. Com clareza sobre o que você tem hoje.

Referências e fontes: Ward Cunningham, "The WyCash Portfolio Management System" (1992) · Gartner IT Budget Benchmarks (2024) · Análise de padrões em diagnósticos Stalebu (2024–2025) · Referências setoriais de custo de incidente e manutenção de software. Os percentuais apresentados neste artigo são referências de mercado e estimativas baseadas em padrões observados — não dados universais. Cada sistema tem seu próprio perfil de custo.