Legados problemáticos que geram prejuízo em vendas ou operação: modernize sem parar

O sistema de pedidos caiu na sexta à tarde, no pico de movimento do fim de semana. O fornecedor do sistema tem suporte apenas em horário comercial. O único desenvolvedor que conhecia o código foi embora há dois anos. O time passou a sexta noite e o sábado inteiro tentando subir o sistema manualmente, enquanto vendas ficavam na fila e clientes ligavam perguntando o que estava acontecendo. Na segunda, quando tudo voltou, a conta chegou: pedidos perdidos, horas extras da equipe, desconto concedido para reter clientes frustrados, e a pergunta inevitável — há quanto tempo esse sistema estava dando sinais de que ia falhar?

Esse tipo de cena não é raro. É, na verdade, o desfecho previsível de anos de decisão postergada. Sistemas legados não somem. Envelhecem. Acumulam remendos sobre remendos. Ficam cada vez mais frágeis, mais difíceis de manter, mais caros de corrigir — e mais perigosos de substituir, porque com o tempo ninguém mais sabe exatamente o que eles fazem e como.

O paradoxo do sistema legado é que quanto mais crítico ele é para o negócio, mais difícil parece substituí-lo. E quanto mais difícil parece substituí-lo, mais tempo a empresa adia a decisão. Enquanto isso, o risco cresce, o custo de manutenção cresce, e a janela de modernização segura fica cada vez mais estreita.

Por que os legados acumulam até virar crise

O mecanismo de acumulação começa com decisões racionais. Quando um sistema foi implantado, ele resolvia o problema do momento. Com o tempo, o negócio cresceu, o mercado mudou, novas exigências surgiram — mas o sistema ficou onde estava, sendo adaptado com soluções pontuais que não foram pensadas para durar. Cada adaptação aumenta a complexidade. Cada complexidade aumenta o custo de manutenção. Cada custo de manutenção reforça o argumento de que “agora não é hora” de substituir.

O segundo fator é a concentração de conhecimento. Sistemas legados frequentemente dependem de uma ou duas pessoas que conhecem o código, sabem os atalhos, entendem as exceções não documentadas. Quando essas pessoas saem — e saem, inevitavelmente — o conhecimento vai junto. O que fica é um sistema que ninguém entende completamente, onde qualquer mudança vira uma operação de risco elevado. Nesse ponto, até o time de TI tem medo de mexer, porque não sabe o que pode quebrar.

Há também o fator político. Modernizar um sistema legado é uma decisão que exige investimento visível e aceitar risco de instabilidade no processo. Em ambientes onde o sucesso é medido por resultado imediato e onde o CTO ou o diretor de TI é cobrado pela continuidade operacional acima de tudo, a decisão de modernizar fica sempre adiada para “quando tiver mais estabilidade.” Essa estabilidade raramente chega — porque o próprio sistema legado é uma das principais fontes de instabilidade.

O que o legado custa que não aparece no orçamento

O custo mais óbvio é o de manutenção crescente. Sistemas legados consomem tempo desproporcional do time técnico para manter funcionando. Bugs que em um sistema moderno levam horas para corrigir levam dias em um legado mal documentado. Esse custo existe, é real, mas raramente é isolado em uma linha do orçamento — fica diluído no custo geral da área de TI.

O custo menos visível, e frequentemente maior, é o de oportunidade perdida. Um sistema legado que não se integra com novas plataformas de venda, que não suporta as regras de negócio necessárias para um novo produto, ou que não tem API disponível para conectar com parceiros — esse sistema está ativamente impedindo crescimento. Cada nova iniciativa que precisa “dar a volta” no legado carrega um custo de engenharia extra, demora mais para ser entregue e chega ao mercado mais tarde. Em mercados competitivos, esse atraso tem preço.

Há ainda o risco de descontinuidade. Sistemas que rodam em tecnologias sem suporte ativo do fornecedor são vulnerabilidades abertas. Quando o fabricante do banco de dados ou do servidor de aplicação encerra o suporte a uma versão, a empresa fica sem patches de segurança. Qualquer vulnerabilidade descoberta a partir desse ponto é um risco permanente, sem correção disponível.

Como modernizar sem parar a operação

A armadilha mais comum na modernização de legados é a abordagem do “big bang” — planejar uma substituição completa, de uma vez, com data definida para virada. Em teoria parece eficiente. Na prática, projetos de substituição completa de sistemas críticos são os que mais falham, mais atrasam e mais custam. A complexidade subestimada no planejamento, a dependência de que o legado seja completamente documentado antes da migração, e o risco de que o novo sistema tenha que suportar todos os casos de uso do antigo desde o primeiro dia — tudo isso cria um projeto que cresce indefinidamente em escopo e risco.

A abordagem que funciona é a substituição progressiva. O primeiro passo é classificar o sistema legado por criticidade e por custo de manutenção atual. Não todos os legados são igualmente urgentes. O que tem maior impacto financeiro direto — seja pelo custo de manutenção, pelo risco de falha ou pela oportunidade que está bloqueando — é o que deve ser endereçado primeiro.

O segundo passo é definir a estratégia de modernização para cada sistema prioritário. Há basicamente três caminhos: substituir por solução de mercado existente, reescrever, ou modernizar incrementalmente (strangler pattern — envolvendo o sistema legado com uma camada nova que gradualmente assume suas funções). Qual dos três faz sentido depende de fatores como grau de customização, disponibilidade de solução de mercado adequada, e custo de reescrita versus custo de integração.

O terceiro elemento crítico é a definição de rollback para cada etapa. Modernização progressiva só é segura se cada etapa tiver um plano claro de reversão em caso de problema. Isso exige que os dois sistemas — legado e novo — coexistam e sejam capazes de operar em paralelo por um período, o que tem custo de engenharia, mas é incomparavelmente mais seguro do que uma virada única.

A estabilização e o monitoramento intensivo após cada etapa de migração completam o ciclo. Sistemas novos têm comportamentos inesperados em produção que não apareceram nos testes. Ter visibilidade em tempo real do que está acontecendo e capacidade de reagir rápido é o que separa uma modernização bem executada de uma que virou crise.

A decisão que não pode continuar sendo adiada

Eu entendo o argumento de “agora não é hora.” Entendo o risco percebido de mexer em algo que, por mais problemático que seja, pelo menos está funcionando. Mas esse argumento tem prazo de validade — e em muitos casos já venceu.

Sistema legado problemático não se resolve sozinho com o tempo. Quanto mais tempo passa, mais caro fica para modernizar, mais concentrado fica o conhecimento, mais dependente a empresa fica de um ou dois profissionais que dominam um código que ninguém mais consegue ler. A decisão de modernizar não fica mais fácil esperando. Fica mais cara. E quando a crise chega — e chega — a empresa não escolhe mais quando e como modernizar. Moderniza às pressas, no pior momento, com o maior custo possível.