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

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

Sistema antigo, feio ou lento não é motivo para trocar. Dos nove sistemas legados que a Epicora assumiu, dois foram substituídos e cinco seguem em manutenção. Idade não é defeito: interface datada se resolve por uma fração do custo de uma reescrita, e um sistema que funciona há anos é argumento a favor dele, não contra.

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.

O engano mais caro: o sistema não é insuficiente, está desconfigurado#

Antes de escrever escopo para um sistema novo, audite o atual logado, por dentro. Num caso de agosto de 2026, três dos quatro requisitos que o cliente pedia já existiam no sistema que ele usava — desligados. Requisito que aparece desativado é configuração e sai por uma fração do preço; requisito sem lugar no modelo de dados é software.

Existe um pedido que chega com a decisão já tomada: "o sistema que a gente usa atende bem, eu só queria um nosso, com estas quatro melhorias". É o que parece mais fácil de atender, e é o que mais engana.

Em agosto de 2026 fizemos, nesse caso, o que passamos a fazer sempre: antes de escrever uma linha de escopo, entramos no sistema atual logados, por dentro, com o acesso cedido pelo próprio cliente. Era um SaaS de gestão vertical, em uso havia cinco meses. Dos quatro requisitos pedidos, três já existiam lá — desligados:

• O agendamento pelo cliente final estava ativo, com página pública no ar — e 1 de 120 serviços publicado nela.
• A pré-agenda pedida existia com outro nome, configurável serviço por serviço, e estava em zero nos 120.
• O terceiro era um módulo de mensagens que o sistema oferecia e que nunca havia sido ativado.

O quarto requisito era real — e mais fundo do que o pedido. Não era um filtro que faltava na tela: o dado que esse filtro precisaria não existia no cadastro, e as duas frentes da operação mediam capacidade em unidades diferentes. Esse é o requisito que justifica software.

Nada disso aparece num briefing, porque o cliente descreve o que acha que o sistema não faz — e ninguém conhece o próprio sistema inteiro. O desconto que a auditoria dá no projeto é grande: existia um caminho honesto que entregava três dos quatro pedidos em configuração, sem construir nada.

O segundo efeito é menos óbvio e vale mais: operação sub-configurada é risco de projeto. Se o sistema atual chegou aos cinco meses com 119 dos 120 serviços fora da página pública, o sistema novo — mais capaz, mais bonito, com as quatro melhorias — chega desligado do mesmo jeito. O que faltava ali não era software.

O roteiro cabe numa sessão, e a ordem importa: a tela do ponto de dor e os filtros que ela de fato tem; o cadastro por trás dela, para ver se o dado existe; o menu inteiro, que é a régua real do "atende bem"; a base de clientes ordenada por gasto, que costuma desmentir a persona do briefing; a capacidade física da operação, que é o gargalo antes de qualquer tela; e quantos itens do catálogo realmente faturam. É o mesmo princípio de diagnosticar antes de decidir que aplicamos em código gerado por IA: a pergunta "o que dá para salvar?" é sempre mais barata que a resposta "vamos refazer".

Uma ressalva de conduta, porque ela vale para quem for repetir o exercício: o contrato de uso de um SaaS normalmente veda ceder acesso e replicar o software. O acesso tem que ser dado pelo cliente — de preferência com um usuário próprio para quem audita —, o que se documenta é a operação e os requisitos dele, nunca a implementação do fornecedor, e não se aceita termo nem se grava dado dentro do sistema de terceiro.

Sinal 1 — ninguém consegue mexer no sistema#

O primeiro sinal de que um sistema precisa ser substituído não é técnico: é ninguém conseguir mexer nele. O teste leva um minuto — quantas pessoas conseguem, hoje, corrigir um erro em produção e publicar a correção? Se for uma, existe risco de continuidade. Se for zero, o sistema já deixou de ser ativo e virou passivo.

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#

O segundo sinal é perder o acesso ao próprio produto: o aplicativo saiu da loja, a conta de publicação pertence ao fornecedor que sumiu, ou uma dependência tem data marcada para ser desligada. A pergunta que resume o sinal é direta — existe alguma data, definida por outra empresa, em que o seu sistema para de funcionar?

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.

Nos dois casos de aplicativo existe uma pergunta que precede a técnica e decide o resto: de quem é a conta da loja. Se ela pertence ao fornecedor que sumiu, você não perdeu só o app — perdeu o canal, e recomeçar em uma conta nova custa base instalada, histórico de avaliações e o caminho de atualização de quem já tinha instalado. Tratamos isso em de quem deve ser a conta da App Store.

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#

O terceiro sinal não gera chamado: a equipe para de usar a parte que não serve e resolve por fora, em planilha, WhatsApp e documento montado à mão. Quando isso acontece, o sistema já foi parcialmente substituído — sem projeto, sem controle e sem ninguém responsável pelo dado que passou a viver fora dele.

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#

O quarto sinal é o desempenho mudar o que a empresa consegue fazer — não uma tela lenta isolada, que costuma ser consulta mal feita e não justifica trocar nada. No DNA Genética, 65 animais em três lotes consumiam 1 hora e 35 minutos no sistema antigo; no sistema novo, com o dobro de animais, a mesma operação responde em até 3 minutos.

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.

Existe ainda um terceiro caminho, quando parte do que o legado faz é bem feita e a operação não quer perdê-la: o antigo fica como fonte de dado e o novo se constrói em volta dele. Vale aqui o aviso de qualquer integração — o que a arquitetura pode fazer não é escolha sua, é o que o outro lado oferece, como descrevemos ao integrar com o ERP que a operação já usa.

O legado é a especificação — e é aí que o projeto novo erra#

Quando a decisão de trocar já está tomada, o erro seguinte é sutil: tratar o sistema antigo como o problema, e não como a fonte de requisito mais completa que existe. Ele carrega anos de regra que ninguém escreveu em lugar nenhum, e o teste de que você o entendeu não é "o novo é melhor" — é o novo faz tudo o que o velho fazia.

No sistema de gestão que estamos substituindo agora, esse teste reprovou o nosso próprio desenho. Antes de escrever código, montamos um protótipo navegável do sistema inteiro — hoje em 44 rotas clicáveis —, com uma regra dura: nada entra em desenvolvimento antes do aceite por escrito. Ao reconferir o protótipo contra o sistema em uso, tela por tela, apareceu o que o escopo não havia pegado: a tela central do trabalho tinha duas seções, onde o sistema atual já tem cinco. Não era pedido novo do cliente; era função que o legado entrega há anos e que nós tínhamos deixado de fora.

Do mesmo exercício veio o oposto, que importa igual: substituir não é copiar tela por tela. Um módulo inteiro do sistema antigo virou uma marcação dentro de outra tela — porque a pergunta que ele respondia era uma só, e ter módulo próprio obrigava a subir o mesmo arquivo em dois lugares e a decidir, antes de anexar, a qual deles ele pertencia.

Daí saem duas conclusões práticas, e elas separam uma virada tranquila de uma virada com a operação parada:

• A reconciliação é contra o sistema em uso, não contra o documento. Comparar o escopo novo com o modelo antigo, ou com a lembrança de quem operava, deixa passar comportamento. O que vale é abrir os dois lado a lado.
• O protótipo é o instrumento mais barato de descobrir regra não documentada. Muito mais barato do que descobri-la depois, com o sistema novo em produção e a equipe sem conseguir fechar o mês.

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#

Como sei se o problema é o sistema ou a configuração dele?#

Entrando no sistema atual antes de escrever escopo, logado, com quem opera do lado. A verificação é objetiva: para cada coisa que falta, procure o campo que ela exigiria no cadastro e o item correspondente no menu. Requisito que aparece desligado é configuração, e sai por uma fração do preço de um sistema novo. Requisito que não tem onde existir no modelo de dados é software. Num caso recente, três dos quatro pedidos do cliente estavam no sistema — desligados.

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.