O sistema antigo ficou sem quem o mantenha: o que fazer antes que ele vire um risco para a operação

Há um tipo de risco que não aparece no painel de incidentes. O sistema antigo continua faturando, expedindo ou controlando estoque. Os operadores sabem a tela. O banco está no ar. O problema é outro: a pessoa que entendia o código saiu, aposentou-se ou simplesmente não quer mais tocar naquilo. Ninguém na empresa sabe mexer com segurança.

Enquanto não há mudança de regra, o silêncio engana. Na primeira exigência fiscal, no primeiro cliente com exceção, na primeira integração nova, a pergunta volta: quem altera? Quem testa? Quem garante que o faturamento de amanhã não quebra? O legado deixa de ser “um sistema velho que funciona” e passa a ser um ponto único de falha humana.

Reescrever tudo do zero não é automaticamente a melhor decisão. Antes de decretar um sistema novo, existe um trabalho anterior: entender o que se tem, reduzir o risco de mexer no escuro e só então escolher entre estabilizar, encapsular, modernizar por etapas ou — quando realmente couber — substituir.

O pedido de ajuda costuma chegar em linguagem de operação, não de arquitetura. Os sinais abaixo descrevem o mesmo quadro:

Sistemas críticos costumam viver mais do que contratos, equipes e fornecedores. O que nasceu como solução interna de um analista vira, em poucos anos, a espinha da operação. Enquanto essa pessoa está, o conhecimento mora na cabeça dela. Quando sai, a empresa descobre que comprou um ativo sem manual e sem sucessor.

A ausência de documentação não é vaidade técnica. Em muitos legados, as regras mais importantes nunca foram escritas: exceções de cliente, arredondamento, ordem de cálculo, “não mexa nisso no dia X”. O código é o único lugar onde a regra existe. Sem leitura cuidadosa, a empresa não sabe o que está protegendo.

Soma-se a isso o mercado de trabalho. Tecnologias antigas não desaparecem das fábricas e dos escritórios na mesma velocidade com que desaparecem dos currículos. Manter um sistema nessas condições por omissão — “depois a gente vê” — é uma decisão. Só não está escrita.

Há um leque mais amplo do que “aguentar” versus “refazer”. As opções abaixo não são etapas obrigatórias de um único método; são caminhos que o diagnóstico pode combinar.

Não fazer nada transfere o risco para o próximo incidente. Contratar a primeira pessoa que “ainda conhece a linguagem” pode até aliviar o curto prazo, mas reproduz a dependência de um único especialista se não houver documentação e sucessor.

A reescrita total parece limpeza. Na prática, joga fora anos de exceção operacional que o código antigo ainda honra. O artigo modernização de sistemas legados sem reescrita total trata justamente por que esse atalho costuma falhar. Reescrever só deveria entrar no radar depois que se sabe o que o sistema faz de fato.

O caminho intermediário começa por diagnóstico técnico: o que existe, o que é crítico, o que está frágil, o que a operação não pode perder. Em seguida, documentação do legado — não um tratado, e sim o mapa das rotinas, tabelas e regras que sustentam o dia. Com isso, dá para estabilizar (ambiente, backup, monitoramento, congelamento do que é perigoso), criar APIs ou uma fachada em torno do antigo, encapsular o núcleo e só então modernizar por módulos ou migrar por etapas.

Substituição completa permanece no conjunto de opções. Entra quando o sistema já não representa o negócio, quando a plataforma não tem caminho de continuidade, ou quando o custo de conviver supera o de reconstruir com evidência — não com impaciência.

A modernização de sistemas costuma ser o caminho adequado quando o legado ainda entrega valor, a operação depende dele todos os dias, e o risco principal é a falta de domínio técnico — não a inutilidade do software. Se o sistema “ainda é o que faz a empresa funcionar”, o primeiro objetivo é reduzir a chance de uma alteração cega derrubar a operação.

Faz sentido documentar e encapsular quando há um banco crítico, integrações frágeis e necessidade de conectar canais novos (portal, aplicativo, outro ERP) sem reescrever o núcleo. Faz sentido modernizar por etapas quando um módulo dói mais que os outros — emissão, estoque, um cálculo específico — e o restante pode esperar.

Também faz sentido quando a empresa precisa de tempo: tempo para formar sucessor, tempo para a operação absorver mudança, tempo para não apostar o faturamento em uma virada única. Modernizar sem parar a operação não é slogan; é restrição de projeto. Quem ignora essa restrição escolhe o risco que dizia querer evitar.

Há casos em que o legado realmente precisa sair. Um sistema que já não reflete o processo, que roda em infraestrutura sem caminho de continuidade, ou que impede uma obrigação legal nova, pode exigir substituição. Mesmo então, substituição não é sinônimo de apagar o antigo na segunda-feira.

O que não faz sentido é decretar reescrita porque “ninguém conhece Delphi”, “está feio” ou “queremos tecnologia nova”. Desconhecimento do código é argumento para diagnóstico, não para demolir o ativo. Substituir sem mapear regras é o modo mais rápido de descobrir, em produção, o que o sistema antigo fazia calado.

Também não faz sentido “modernizar” copiando telas sem extrair a regra, nem contratar um pacote de mercado e forçar a operação a caber nele só para se livrar do legado. Às vezes o legado existe precisamente porque o pacote nunca cobriu a exceção. Trocar a tecnologia sem resolver isso devolve a empresa à planilha.

O risco da reescrita por pânico é conhecido: prazo que não fecha, orçamento que não cabe, e um período em que o antigo já não recebe correção e o novo ainda não está pronto. A operação fica no meio.

O risco oposto é o herói único. Contratar alguém que “ainda mexe nisso” sem documentar, sem ambiente de teste e sem sucessor apenas adia o mesmo problema — agora com outra pessoa insubstituível.

Alterar produção sem diagnóstico é o terceiro risco: um ajuste fiscal, um campo novo, um job “rápido” em cima do banco crítico. Sem mapa de dependências, a correção pontual vira incidente. Por fim, há o risco de perder a regra implícita. Se o código antigo for descartado antes de ser lido, a empresa perde o único registro fiel de como o negócio realmente calcula.

A PROLS trata o legado sem dono como problema de continuidade, não como desculpa para vender sistema novo. O ponto de partida é diagnóstico: o que o sistema faz, onde está o risco, o que a operação não pode interromper, e quanto conhecimento ainda existe em pessoas, código e banco.

A partir daí, o trabalho pode incluir documentação objetiva do legado, estabilização do que está frágil, criação de APIs para que o antigo converse com o restante da empresa, encapsulamento do núcleo e modernização progressiva módulo a módulo. Migração por etapas entra quando há evidência. Substituição entra quando o diagnóstico mostra que conviver ficou mais caro do que reconstruir — não antes.

Reescrever tudo do zero não é automaticamente a melhor decisão. Se o seu sistema antigo ficou sem quem o mantenha, o convite é descrever o cenário: tecnologia, criticidade, quem ainda conhece, o que não pode parar. O caminho comercial correspondente é a modernização de sistemas.