Sistema legado: manter, modernizar ou substituir? O guia do fundador não-técnico

Sistema legado não é questão de idade, é de risco. Como diagnosticar o seu em quatro perguntas e escolher entre manter, encapsular, modernizar aos poucos ou substituir.

No ano passado, conversamos com o COO de uma distribuidora no interior de São Paulo, 40 funcionários, operação lucrativa. Todo o faturamento da empresa passava por um sistema que um desenvolvedor freelancer construiu em 2018. O desenvolvedor saiu em 2021. Desde então, ninguém alterou uma linha. Quando o Pix mudou uma regra de conciliação, a equipe passou a corrigir os lançamentos à mão, todos os dias, porque mexer no código era considerado arriscado demais. O sistema funcionava. E mandava na empresa. Era um sistema legado em todos os sentidos que importam.

Sistema legado não é só o mainframe de banco rodando COBOL desde 1985, mas o software de sete anos atrás que ninguém mais sabe alterar com segurança. Se você fundou ou opera uma empresa de 5 a 50 pessoas, a sua versão do problema se parece muito mais com a distribuidora do que com o banco.

Este guia define o que é um sistema legado de verdade, mostra como ele aparece em empresa pequena, quanto custa conviver com um, e organiza a decisão que importa: manter, encapsular, modernizar aos poucos ou substituir.

O que é um sistema legado

Um sistema legado é um software que continua em operação porque o negócio depende dele, mas cuja tecnologia, arquitetura ou falta de documentação tornam qualquer alteração arriscada e cara. A definição importante está na segunda metade da frase. Idade não é o critério. Risco é.

Um sistema de 15 anos, bem documentado, com testes e com duas pessoas que o conhecem a fundo, não é legado no sentido que importa. Um app de 3 anos feito às pressas em uma plataforma no-code, sem documentação, cujo único autor já saiu da empresa, é profundamente legado. O termo descreve uma relação entre o sistema e a sua capacidade de mudá-lo, não uma data de nascimento.

O teste prático é uma pergunta: se o negócio precisar que esse sistema mude até o fim do trimestre, alguém consegue fazer isso com confiança? Se a resposta envolve um suspiro, você tem um sistema legado.

Vale separar o conceito de um vizinho próximo: dívida técnica é o conjunto de atalhos acumulados dentro de um sistema que alguém ainda mantém. Sistema legado é o estágio seguinte, quando a capacidade de manter se perdeu. Toda empresa carrega dívida técnica; nem toda empresa carrega um legado. Escrevemos um guia separado sobre como diagnosticar dívida técnica antes que ela chegue nesse estágio.

Como um sistema vira legado em empresa pequena

Nas empresas que atendemos, de 5 a 50 pessoas, o legado quase nunca nasce de uma decisão ruim. Nasce de três padrões, todos racionais na época.

O freelancer que saiu. O padrão da distribuidora. Um desenvolvedor competente constrói o sistema, a empresa cresce em cima dele, o desenvolvedor segue a vida. O código pode até ser bom. Irrelevante: ninguém mais consegue ler as decisões que estão só na cabeça dele. A empresa não perdeu um prestador, perdeu o acesso ao próprio sistema. Esse caso é tão comum que dedicamos um guia inteiro ao bus factor, o risco de um único dev segurar o codebase.

O no-code que ossificou. Bubble, Glide, planilha com macros, Zapier empilhado. Ferramentas excelentes para validar; péssimas para serem esquecidas em produção por quatro anos. O custo da plataforma sobe com o uso, os workarounds se acumulam, e um dia a “automação provisória” é o sistema de operações da empresa, e ninguém lembra por que a regra da célula G14 existe.

O ERP customizado de 2018. A empresa contratou uma consultoria para adaptar um ERP de prateleira. A consultoria entregou e saiu de cena. As customizações nunca foram documentadas, a versão do ERP congelou (atualizar quebraria as customizações), e agora o fornecedor cobra caro para mexer no que a própria empresa pagou para construir.

Nos três padrões a sequência é a mesma: o sistema foi a decisão certa quando foi feito, o negócio mudou, e a capacidade de mudar o sistema junto não acompanhou. Legado é o nome dessa defasagem.

Quanto custa conviver com um legado

O argumento para não mexer é sempre o mesmo: “está funcionando”. É verdade, e é por isso que o custo do legado engana. Ele não aparece como uma fatura. Aparece espalhado em quatro linhas que ninguém soma.

O imposto de integração. Cada ferramenta nova precisa conversar com o sistema antigo, e não conversa. Então a conversa vira gente: alguém exporta CSV, alguém digita de novo, alguém confere. Na distribuidora, eram três horas por dia de conciliação manual. Doze mil reais por mês de salário fazendo o trabalho que uma integração faria, sem aparecer em nenhum relatório como custo do sistema.

O imposto de contratação. Desenvolvedores bons evitam stacks mortas e código sem documentação. Quando você finalmente decide contratar alguém para cuidar do sistema, descobre que o mercado cobra prêmio para herdar um problema, quando aceita herdar.

O risco concentrado. A pergunta que fazemos a todo operador nessa situação: o que acontece com a operação se o sistema parar numa sexta-feira e ficar fora por 48 horas? Se a resposta é “para tudo”, o sistema é um ponto único de falha sem plano de recuperação. Esse risco não custa nada por mês. Custa tudo, uma vez.

O custo de oportunidade. A funcionalidade que não dá para lançar, o canal de venda que não dá para integrar, o relatório que o investidor pediu e que leva uma semana para montar à mão. É o custo mais difícil de medir e quase sempre o maior.

O padrão não é exclusividade de empresa pequena. O GAO, o tribunal de contas americano, audita há anos os sistemas legados do governo federal dos EUA e encontrou sistemas críticos com mais de 50 anos, consumindo a maior parte do orçamento de TI só para continuar de pé. A escala é outra; a mecânica, o dinheiro indo para manter em vez de evoluir, é idêntica.

Se você quer aprofundar a parte recorrente dessa conta, o nosso guia de custo de manutenção de software destrincha o que se paga depois do lançamento.

O diagnóstico: quatro perguntas antes de decidir caminho

Você não precisa de uma auditoria de seis meses para saber o tamanho do problema. Precisa de respostas honestas para quatro perguntas. Chame o time de operações, não só o de tecnologia, e responda por escrito.

1. O sistema atende o processo, ou o processo se contorce para atender o sistema? Conte os workarounds: planilhas paralelas, redigitação, “isso a gente resolve por WhatsApp”. Cada workaround é o processo cedendo. Até dois, conviva. Acima disso, o sistema está ditando como a empresa trabalha.

2. Quantas pessoas conseguem alterar o sistema com segurança? Duas ou mais: você tem manutenção. Uma: você tem um risco com prazo indefinido. Zero: você não tem um sistema, tem uma caixa lacrada da qual a operação depende.

3. O que acontece se ele parar por 48 horas? Se existe contorno manual razoável, o risco é administrável. Se a empresa para de faturar, a resposta define urgência independentemente das outras três.

4. Quanto custa por ano mantê-lo vivo, somando os impostos invisíveis? Licenças e servidor, mais as horas de trabalho manual que ele gera, mais o que você paga de prêmio por suporte. A maioria dos operadores nunca somou. A soma costuma decidir a conversa.

Duas respostas ruins ou mais: continue lendo. As quatro tranquilas: seu sistema é velho, não é legado. Guarde este guia para daqui a dois anos.

Os quatro caminhos: manter, encapsular, modernizar aos poucos, substituir

Todo fornecedor que você consultar vai recomendar o caminho que ele vende. A consultoria de integração recomenda integrar, a software house de reescrita recomenda reescrever, o vendedor de ERP recomenda o ERP dele. Nenhum dos quatro caminhos é certo em geral. Cada um é certo para um diagnóstico.

Manter, deliberadamente. Se o sistema é estável, o risco está concentrado em pessoas e não em tecnologia, e o negócio não pede mudanças frequentes, a resposta certa pode ser não mexer na arquitetura e atacar só o risco: documentar o que existe, garantir backup e ambiente de recuperação testados, e ter mais de uma pessoa (interna ou parceira) capaz de operar o código. É o caminho mais barato e o mais subestimado, porque não tem fornecedor torcendo por ele.

Encapsular e integrar. O sistema continua sendo o motor, mas para de ser a parede. Constrói-se uma camada por cima, geralmente APIs ou serviços pequenos ao redor, que deixa as ferramentas novas conversarem com ele sem que ninguém precise mexer nas entranhas. Resolve o imposto de integração sem o risco de uma troca de motor. O limite: encapsulamento não rejuvenesce o núcleo. Se o núcleo precisa mudar com frequência, isso só compra tempo, o que, em muitos casos, é exatamente o que se quer comprar.

Modernizar aos poucos. Substituir o sistema por partes, começando pelas áreas de maior atrito, com o sistema antigo e o novo convivendo durante a transição. É o padrão que Martin Fowler batizou de strangler fig, a figueira que cresce ao redor da árvore até substituí-la. A virtude é o risco diluído: cada etapa entrega valor e pode ser interrompida sem desastre. O preço é gestão: conviver com dois sistemas exige disciplina de escopo, e projetos sem dono claro degeneram em três sistemas.

Substituir de uma vez. A reescrita completa. Existem casos em que é o caminho certo: a plataforma vai ser descontinuada, o custo de manter ultrapassou o de refazer, ou o diagnóstico da pergunta 3 deu “para tudo” sem contorno. Mas é o caminho mais arriscado dos quatro, e costuma chegar à mesa cedo demais, empacotado como inevitável. Antes de assinar qualquer proposta de reescrita, leia o nosso guia sobre por que a reescrita de software é quase sempre a pergunta errada, ele existe exatamente para esse momento.

A regra de bolso que usamos com clientes: comece pelo caminho mais barato que resolve o risco apontado no diagnóstico, não pelo mais completo. Dá para subir de degrau depois; descer é caro.

O erro mais caro: tratar a decisão como técnica

A armadilha final não está nos caminhos, está em quem decide. Operadores não-técnicos tendem a delegar essa decisão inteira “para quem entende”, e quem entende quase sempre tem um viés: o dev interno prefere reescrever (ninguém sonha em manter código alheio), o fornecedor prefere o projeto maior, a consultoria prefere a ferramenta da casa.

A decisão sobre um sistema legado é uma decisão de negócio com insumos técnicos, na mesma família de build vs buy e de contratar dentro ou fora. O diagnóstico das quatro perguntas é deliberadamente não-técnico porque quem tem que respondê-las é quem sente o custo: você. O papel do parceiro técnico é dar opções com preços e riscos honestos dentro de cada caminho, e não escolher o destino.

É o tipo de conversa que separa um parceiro de um fornecedor: parceiro mostra o trade-off, fornecedor mostra a proposta.

Perguntas frequentes

O que é um sistema legado?
É um software que continua em operação porque o negócio depende dele, mas cuja tecnologia, arquitetura ou falta de documentação tornam alterações arriscadas e caras. O critério não é a idade do sistema, é a capacidade (perdida) de mudá-lo com segurança.

O que é um programa legado?
O mesmo conceito no nível de uma aplicação específica: um programa que segue em uso, mas que ninguém consegue atualizar com segurança, seja por falta de documentação, por depender de tecnologia descontinuada ou porque quem o construiu não está mais disponível.

O que é modelo legado?
O termo aparece em dois sentidos: um modelo de dados antigo que sistemas novos precisam respeitar para conversar com o legado, e, mais recentemente, versões antigas de modelos de IA mantidas em produção. Em ambos, a lógica é a mesma do sistema legado: algo antigo que permanece porque trocar custa mais do que conviver, até deixar de custar.

Sistema legado é sempre ruim? Quando vale substituir?
Não. Um sistema antigo, estável e que atende o processo é um ativo, não um problema. Vale agir quando o diagnóstico mostra risco concentrado (uma ou zero pessoas capazes de mantê-lo), workarounds se multiplicando ou custo anual invisível maior do que o de modernizar. E substituir de uma vez é o último caminho a considerar, depois de manter, encapsular e modernizar aos poucos.