O que o orçamento de modernização não prevê — e que costuma ser o que faz o projeto falhar

Existe um padrão que aparece com frequência em projetos de modernização: o projeto é entregue dentro do prazo e do orçamento aprovado. O go-live acontece. A equipe comemora.

Seis meses depois, a empresa está gastando mais do que gastava antes.

Não por incompetência do time. Não por má escolha de tecnologia. Mas porque o orçamento cobriu o que era visível — e ignorou o que o sistema antigo sabia fazer e o novo ainda não sabe.

Esse gap tem um custo. E ele quase nunca aparece na planilha de aprovação do projeto.

O que entra no orçamento padrão

Um orçamento típico de modernização cobre o óbvio: horas de engenharia, infraestrutura nova, licenças de ferramentas, custos de migração de dados, treinamento dos usuários, eventual suporte de uma consultoria. Em projetos mais maduros, também entra uma reserva para imprevistos — geralmente 15% a 20% do valor total.

Esse orçamento está correto. O problema é o que ele não prevê.

Os quatro custos que o orçamento não vê

1. O custo de reaprender o que o sistema antigo já sabia

Sistemas legados que operam por dez, quinze anos acumulam um volume de lógica de negócio que não está em nenhum documento: cálculos fiscais específicos para determinados clientes, regras de exceção para segmentos de produto, validações que nasceram de incidentes operacionais e nunca foram formalmente especificadas.

Quando o sistema novo entra em produção sem ter absorvido esse conhecimento, o time começa a descobrir o que está faltando — caso a caso, incidente a incidente. Cada descoberta gera um ciclo de análise, desenvolvimento, teste e deploy emergencial. Multiplicado por dezenas de casos ao longo de meses.

O custo não está no bug em si. Está no tempo de engenharia alocado para apagar incêndios que poderiam ter sido previstos, e no impacto operacional de cada falha enquanto a correção não chega.

2. O custo do período de operação paralela

Em modernizações de sistemas críticos, é comum a empresa precisar operar os dois sistemas simultaneamente por um período — o legado como fallback, o novo como principal. Isso significa manter dois times de suporte, dois ambientes, dois fluxos de monitoramento.

Esse período raramente é curto. O que foi planejado como "dois meses de transição" frequentemente se estende por seis, oito, doze meses — porque os casos de borda que aparecem em produção real não aparecem em ambiente de homologação, e cada um precisa ser tratado antes que a empresa se sinta segura para desligar o sistema antigo.

O custo desse período de operação paralela — em infraestrutura e em esforço humano — quase nunca está no orçamento original.

3. O custo de reconstruir o sistema sombra

Em torno de todo sistema legado existe uma camada de processos manuais que compensam o que o sistema não faz: planilhas de controle, e-mails de confirmação, rotinas de conciliação feitas na mão toda segunda-feira de manhã. Esses processos existem porque foram a solução possível quando o sistema não evoluiu no ritmo do negócio.

O sistema novo chega com a promessa de eliminar tudo isso. Na prática, se esses processos não foram mapeados e incorporados ao escopo, eles reaparecem — em versões diferentes, mantidos por pessoas diferentes, com o mesmo propósito de antes. A ineficiência não sumiu. Só mudou de endereço.

Mapear e eliminar o sistema sombra é parte do trabalho de modernização. Quando esse mapeamento não acontece, o custo operacional se mantém — e a empresa paga o custo do sistema novo sem colher o benefício da eficiência que justificou o investimento.

4. O custo de impacto em áreas que ninguém listou como stakeholder

Sistemas legados frequentemente servem a mais áreas do que o escopo oficial do projeto reconhece. A equipe de compliance que exporta um relatório toda quinta. O time de analytics que usa um campo específico como proxy para uma métrica de negócio. O sistema de um parceiro externo que consome dados via uma integração não documentada.

Quando o sistema novo vai ao ar sem ter mapeado essas dependências, essas áreas param de funcionar — sem aviso, sem plano de contingência, e muitas vezes sem que o time de modernização saiba que causou o problema. O custo de diagnóstico e correção nesse caso é alto, porque a raiz não é óbvia.

Por que esses custos são previsíveis mas raramente previstos

Não é falta de experiência. É falta de processo.

O orçamento de um projeto de modernização é construído a partir do que precisa ser construído — o sistema novo. O que não entra naturalmente nessa conta é o trabalho de entender o que o sistema antigo faz que o novo precisa replicar, o que ele faz que precisa ser eliminado, e o que ele faz que ninguém documentou mas que alguma área depende.

Esse trabalho de extração e mapeamento — que deveria acontecer antes do primeiro sprint de desenvolvimento — raramente tem linha no orçamento porque não é "construção". É investigação. E investigação é difícil de vender em uma aprovação de projeto.

O resultado: a empresa aprova um orçamento para construir o sistema novo e descobre, depois do go-live, que também precisava ter orçado para entender o sistema antigo.

O que um orçamento de modernização responsável inclui

Além do custo de construção, um orçamento bem estruturado para projetos de modernização prevê:

Fase de extração de conhecimento — um período dedicado a mapear o que o sistema legado sabe, identificar dependências reais (não as documentadas), e registrar os processos manuais que o novo sistema precisará absorver. Esse trabalho evita que a fase de produção seja usada para descobrir o que deveria ter sido mapeado antes.

Reserva para operação paralela real — não o período otimista, mas o período provável. Em sistemas críticos, planejar para seis meses de operação paralela é mais honesto do que planejar para dois e descobrir que a transição se estende.

Capacidade de resposta pós-go-live — um time com banda disponível para tratar os casos que aparecem nos primeiros meses em produção, sem comprometer a velocidade do roadmap. Esse custo, quando não previsto, é pago de qualquer forma — com atraso de outras iniciativas ou com equipes sobrecarregadas.

Mapeamento de dependências externas — um levantamento estruturado de quem mais depende do sistema, além dos stakeholders formais do projeto.

A pergunta que vale antes de aprovar o orçamento

Quando um projeto de modernização chega para aprovação, a pergunta mais comum é sobre o retorno do investimento: em quanto tempo o novo sistema paga o custo de construção?

A pergunta que falta é outra: o orçamento prevê o trabalho de entender o que o sistema atual sabe — antes de começar a construir o substituto?

Se a resposta for não, o projeto já nasceu com um risco não precificado. O custo de ignorar o que o sistema legado sabe não desaparece com a modernização. Ele reaparece, distribuído em meses de operação, com um preço total que frequentemente supera o que teria custado mapear antes.

Conclusão

Modernizar um sistema legado é uma decisão estratégica de alto impacto.

Aprovar o orçamento errado para essa decisão é o primeiro passo para um projeto que entrega tecnicamente e falha operacionalmente.

Os custos ocultos da modernização não são imprevisíveis. São apenas invisíveis para quem não sabe onde procurar.

Está avaliando um projeto de modernização e quer entender o que o orçamento pode estar deixando de fora?

A VX tem um processo estruturado de diagnóstico que mapeia o conhecimento do sistema legado e os riscos operacionais antes de qualquer proposta técnica. Agende uma conversa.