Quando o sistema legado precisa ser substituído — e quando não precisa

"Tá antigo e é feio" não é motivo para trocar#

Quando alguém nos procura para substituir um sistema, as primeiras frases quase sempre são as mesmas: "fiz isso há muito tempo", "queria deixar mais bonito, é muito feio", "tá antigo".

Nenhuma das três é motivo. Idade não é defeito, interface datada se resolve por muito menos do que uma reescrita, e "há muito tempo" descreve um sistema que vem funcionando há muito tempo — o que é um argumento a favor dele, não contra.

O alerta mais conhecido sobre isso é de 2000: em "Things You Should Never Do", Joel Spolsky chama a reescrita do zero de o pior erro estratégico que uma empresa de software pode cometer. O argumento é sobre leitura, não sobre código — é mais difícil ler código do que escrevê-lo, então o sistema antigo parece pior do que é. O que dá impressão de bagunça costuma ser anos de correção acumulada: cada linha estranha resolvendo um caso real que ninguém lembra mais.

Nossa própria prática confirma isso. Nos últimos anos assumimos nove sistemas que já existiam quando chegamos. Substituímos dois.

O caso mais ilustrativo é a Cirurgicred. O sistema é antigo, não tem documentação e não funcionava corretamente — e o cliente chegou querendo evoluí-lo. Nossa conclusão foi que a evolução não fazia sentido: entraram ajustes pequenos para acompanhar o fluxo atual da operação, e nenhuma funcionalidade nova. Dizer isso custa faturamento no curto prazo e é a recomendação certa.

Sinal 1 — ninguém consegue mexer no sistema#

Este é o sinal que aparece disfarçado de comentário casual: "a empresa que fez não existe mais", "o dev não quer mais trabalhar no projeto", "ninguém sabe direito como funciona".

Repare que nenhum deles é sobre tecnologia. São sobre pessoas e conhecimento, e é isso que os torna sérios: um sistema tecnicamente saudável que ninguém sabe alterar está mais perto do fim do que um sistema feio com equipe ativa.

Vimos as três variações:

• No DNA Genética, o sistema tinha mais de dez anos, fora construído por uma software house e não tinha documentação clara. Restava um programador que fazia manutenção esporádica e não queria seguir desenvolvendo.
• No Hybri, quem construiu era um desenvolvedor sócio do projeto. Ele saiu, e a plataforma ficou sem ninguém.
• No GT, o aplicativo tinha sido escrito sem tipagem e sem documentação — o conhecimento não estava no código nem no papel.

O teste é objetivo e leva um minuto: quantas pessoas conseguem, hoje, corrigir um erro em produção e publicar a correção? Se a resposta for uma, você tem um risco de continuidade. Se for zero, o sistema já parou de ser um ativo e virou um passivo — só ainda não deu o prejuízo.

Sinal 2 — você perdeu o acesso ao próprio produto#

Este é o sinal mais concreto de todos, e o menos escrito. Não é sobre qualidade de código: é o momento em que um terceiro decide o destino do seu sistema e você não tem como responder.

Ele aparece em formas bem literais:

• O aplicativo saiu da loja. Foi o que aconteceu com o app antigo da Reticar: ele parou de acompanhar as versões de SDK exigidas e foi removido. O cliente não conseguia mais instalar o próprio aplicativo — não é metáfora de obsolescência, é um app que não existe mais para quem precisa dele.
• O aplicativo nunca chegou à loja. No GT, o app herdado era distribuído por arquivo, direto para o cliente, e a equipe ainda precisava ajudar cada pessoa a instalar.
• Uma dependência vai ser desligada. A plataforma da Hybri rodava scripts em uma versão de Node que seria descontinuada. O sistema funcionava normalmente — o que ia quebrar era a base debaixo dele, em uma data que não era do cliente.

O mesmo vale para a plataforma em que o sistema foi escrito. O Vue 2 chegou ao fim de vida em 31 de dezembro de 2023: segundo a página oficial do projeto, não recebe mais recursos, atualizações nem correções — mas continua disponível nos canais de distribuição. É aí que mora o risco: fim de vida não derruba nada, então nada avisa. O TinyMCE 4, editor comum em sistemas de gestão, está sem suporte desde 31 de dezembro de 2020 — cinco anos sem correção de segurança, ainda rodando em produção por aí.

A pergunta que resume a seção: existe alguma data, definida por outra empresa, em que seu sistema para de funcionar? Se existe, o prazo não é seu.

Sinal 3 — a operação já criou um caminho por fora#

Este é o sinal que a diretoria descobre por último, porque ele não gera chamado: a equipe simplesmente para de usar a parte que não serve e resolve por fora.

No DNA Genética, a coleta de características dos animais em campo era feita com papel e caneta, e digitada depois — o sistema existia, mas não acompanhava quem estava no pasto. Em outro cliente, o módulo de mensagens internas estava parado porque a equipe conversava por WhatsApp, e um relatório que o sistema deveria emitir era montado à mão no Word, todo mês.

Ninguém decide isso numa reunião. Vai acontecendo: alguém cria uma planilha para conferir um número que o sistema mostra errado, outra pessoa passa a mandar o documento por WhatsApp porque o envio de dentro falha, e em um ano a operação real está espalhada por cinco ferramentas que ninguém contratou.

Quando isso acontece, o sistema já foi parcialmente substituído — por planilha, WhatsApp e Word. A pergunta deixa de ser se você deve trocar, e passa a ser se você percebeu que a troca já começou: sem projeto, sem controle e sem ninguém responsável pelo dado que agora vive fora.

Sinal 4 — o sistema virou o limite do negócio#

Lentidão isolada não é sinal: uma tela pesada costuma ser consulta mal feita, e trocar o sistema por causa dela é caro demais. O sinal é quando o desempenho muda o que a empresa pode fazer.

No DNA Genética isso foi medido com cronômetro, no sistema antigo, em uma fazenda real. Um lote de 32 animais levou 30 minutos só para rodar o acasalamento, e mais 19 minutos para imprimir o resultado — com um erro no meio que obrigou a recomeçar. A fazenda inteira, 65 animais em três lotes, consumiu 1 hora e 35 minutos. No sistema que construímos, em teste com o dobro de animais, a mesma operação — rodar e imprimir — responde em até 3 minutos.

O número importa menos que a consequência: com 1h35 por fazenda, era impossível fazer o acasalamento na frente do produtor. O trabalho tinha que ser levado para o escritório e devolvido depois. Não era uma tela lenta; era o sistema decidindo como o serviço podia ser prestado.

A outra forma desse sinal é mais silenciosa: mudar uma coisa passa a custar duas. Em um sistema de gestão que diagnosticamos, dois módulos praticamente iguais foram implementados em paralelo, ocupando dez tabelas onde caberiam quatro — e cada regra nova precisava ser escrita duas vezes, ou os dois lados divergiam. No mesmo sistema, dados dos sócios estavam gravados como chaves fixas de configuração: incluir um sócio novo não era configurar, era mexer em dado. Em duas plataformas jurídicas que mantemos, escritas em JavaScript sem tipagem nem documentação, o efeito chegou por outro caminho: cada evolução pedida demorava tanto que o produto do cliente parou de andar.

Resumo dos quatro sinais, com o que costuma estar por trás de cada frase:

Dá para trocar só uma parte?#

Dá — e essa é a resposta que mais economiza dinheiro, quando cabe. O critério é se a parte é de verdade separável do resto.

O GT é o exemplo. Herdamos de outra equipe um conjunto que vinha de uma experiência ruim: o projeto levou quatro vezes o prazo previsto e não entregou o resultado completo. O aplicativo estava sem tipagem, sem documentação e nunca fora publicado. Mesmo assim, não refizemos tudo. O app é destacável — conversa com a plataforma por uma interface estável —, então refizemos só ele: tipado, documentado, com protótipo aprovado e publicação nas lojas. A plataforma web e a API ficaram, rodando em Go.

Nas duas plataformas jurídicas que mantemos, o ganho veio de um recorte ainda menor: trocamos a ferramenta de assinatura por outra, reduzindo custo, sem reescrever uma linha do sistema.

Existe um nome consagrado para a substituição gradual: o padrão Strangler Fig, descrito por Martin Fowler — construir o novo em volta do antigo e ir transferindo função por função até que o velho possa ser desligado. Ele funciona, e a condição é sempre a mesma: fronteiras claras entre as partes. Sem essa fronteira, o gradual cobra caro — dados que divergem entre os dois sistemas, duas integrações no lugar de uma, e uma arquitetura de transição que costuma durar mais do que se previu. Aí o caminho mais rápido é o direto: mexer o mínimo possível no sistema atual e construir o novo inteiro.

Se for trocar o todo, como a virada acontece#

Substituir um sistema em operação não é conviver com dois sistemas: é construir inteiro e virar de uma vez.

O caminho tem quatro tempos. O sistema novo é construído por completo, com entregas parciais indo para homologação ao longo do desenvolvimento — o cliente valida em pedaços, mas não opera em pedaços. Pronto, ele roda em paralelo com o antigo por um período: a equipe usa os dois, compara e aponta o que faltou. A virada acontece num dia combinado, com os dados migrados numa janela planejada. E o sistema antigo fica só para consulta por alguns meses, como contingência, antes de ser desligado.

O paralelo é a parte mal entendida. Ele não serve para dividir a operação entre os dois sistemas — serve para a equipe ganhar confiança antes de depender do novo. Na Reticar foi assim: durante os testes o app novo rodou ao lado do antigo, com treinamento presencial e uma rodada formal de retorno; só depois os acessos foram repassados e o antigo saiu. A migração levou 3.819 clientes, preservando identificadores e datas de cadastro — o vendedor abriu o aplicativo e reconheceu a própria carteira, em vez de um sistema vazio pedindo para redigitar anos de relacionamento.

Um detalhe de calendário vale mais do que parece: a data da virada é escolhida contra o pico da operação, não contra o cronograma do projeto. Se a operação se concentra de janeiro a maio, a janela certa é entre agosto e outubro — mesmo que isso signifique esperar.

Perguntas frequentes#

Dá para substituir o sistema aos poucos, um módulo por vez?#

Dá quando a parte é de verdade separável — um aplicativo que conversa com a plataforma por uma interface estável pode ser refeito sozinho. Quando não é isolada, dividir a operação entre dois sistemas cobra caro: dados que divergem, duas integrações no lugar de uma, e uma arquitetura temporária que dura mais que o previsto. Aí sai mais rápido construir inteiro e virar de uma vez.

Quanto tempo leva substituir um sistema que a empresa usa todo dia?#

Para um sistema de gestão inteiro, com muitos módulos e anos de dado acumulado, o intervalo realista entre o início do desenvolvimento e a virada é de dez a doze meses — e boa parte desse tempo não é escrever código, é descobrir as regras que ninguém documentou. Para um app ou módulo isolado, é uma fração disso. Em ambos, o sistema antigo continua rodando até o dia da virada.

Preciso do código-fonte do sistema antigo para substituí-lo?#

Não é obrigatório, mas muda o custo e o risco. Sem ele, as regras de negócio precisam ser redescobertas por engenharia reversa — observando o sistema em uso e entrevistando quem opera —, o que é lento e deixa margem para divergência. Com o código, o implícito vira verificável. Se o fornecedor anterior ainda existe, negocie o acesso antes de começar.

O que acontece com os dados e o histórico dos anos anteriores?#

Eles migram, e essa é a parte mais subestimada do projeto. O ponto de atenção é preservar identificadores e datas originais, para que quem abre o sistema novo reconheça a própria base em vez de uma tela vazia. A migração precisa ser ensaiada mais de uma vez antes da virada, e o sistema antigo costuma ficar disponível só para consulta por alguns meses depois.

Meu fornecedor sumiu ou não responde mais. Isso já é motivo para trocar?#

É motivo para resolver, e trocar é a solução mais cara das disponíveis. Fornecedor ausente é problema de contrato, não de código: na maioria dos casos a saída é passar a manutenção para outra equipe, que assume o sistema como está. Isso também funciona como diagnóstico barato — depois de alguns meses convivendo com o código, substituir ou não deixa de ser palpite.

Fontes#

• Joel Spolsky — "Things You Should Never Do, Part I" (2000), sobre o risco de reescrever do zero — https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
• Martin Fowler — "Strangler Fig Application" (o padrão de substituição gradual) — https://martinfowler.com/bliki/StranglerFigApplication.html
• Vue.js — "Vue 2 has reached End of Life" (página oficial de fim de vida do Vue 2) — https://v2.vuejs.org/eol/
• Tiny — "TinyMCE 4 support window" (anúncio oficial do fim de suporte ao TinyMCE 4) — https://www.tiny.cloud/blog/tinymce-4-support-window/

Próximo passo#

Se você reconheceu dois ou mais sinais aqui, o passo seguinte não é pedir uma proposta de reescrita — é diagnosticar. Na maioria dos casos que atendemos, o desfecho certo foi assumir a manutenção e corrigir o que travava a operação. Quando a troca é a resposta, ela costuma ser do todo: foi assim na Reticar Motores, onde substituímos o sistema comercial de campo de uma operação viva. É o tipo de decisão que tratamos em sistema sob medida — e, se a sua equipe trabalha onde o sinal falha, vale ler também o que muda num sistema quando o app precisa funcionar sem sinal.