Um sistema legado não é um sistema quebrado. É um sistema que funciona, sustenta a operação todos os dias e cobra um pedágio crescente em cada mudança que a empresa precisa fazer. Ele não aparece na conta como prejuízo: aparece como prazo que aumentou, integração que não dá, relatório que sai à mão.
Este texto é para quem decide, não para quem programa. Ele mostra como reconhecer que o sistema virou legado, de onde vem o custo que ninguém soma, as quatro saídas possíveis com o que cada uma custa de verdade, e o critério para saber qual delas se aplica ao seu caso.
O que faz um sistema virar legado
Legado não é sinônimo de antigo. Sistema de doze anos bem cuidado, com testes e documentação, é um ativo. Sistema de três anos escrito às pressas, sem ninguém que entenda as regras que ele executa, já é legado. A idade é coincidência; o que define é a dificuldade de mudar.
Na prática, quatro condições costumam aparecer juntas.
- Ninguém sabe explicar as regras. O conhecimento do negócio está dentro do código, e o código é a única documentação.
- Mudar dá medo. Alterar uma tela quebra outra, e por isso a equipe evita mexer.
- O sistema não conversa com nada. Sem integração possível, todo dado sai e entra por planilha e digitação.
- A dependência é de uma pessoa. Existe um fornecedor único ou um funcionário sem o qual nada anda.
Repare que nenhuma delas é técnica no sentido estrito. São todas condições de risco de negócio, e é por isso que a decisão sobre um legado não deveria ser delegada inteiramente à área técnica.
O custo que não aparece na planilha
O sistema legado costuma ser barato na linha do orçamento e caro em todo o resto. A conta que importa tem cinco componentes, e quatro deles nunca são somados.
| Componente | Onde ele aparece |
|---|---|
| Manutenção | A única linha que a empresa enxerga: contrato, licença, horas do fornecedor |
| Retrabalho manual | Horas da equipe digitando de um sistema para o outro, todo mês |
| Prazo de mudança | A oportunidade que passou porque o sistema levaria seis meses para acompanhar |
| Risco concentrado | O que acontece se o fornecedor único sumir ou a pessoa que entende sair |
| Teto de crescimento | O volume que a empresa não consegue atender sem contratar mais gente |
O componente mais subestimado é o retrabalho. Ele é diluído em muitas pessoas e poucos minutos, o que o torna invisível, e cresce junto com o faturamento. Vale medir uma vez: quantas horas por mês a equipe gasta transportando dado de um lugar para outro. A conta desse desperdício tem um recorte próprio em o custo dos processos manuais.
Os sinais de que passou da hora
Existem sinais que separam o sistema que ainda vale manter do que já está cobrando mais do que entrega.
- Toda mudança pequena vira projeto. Alterar um campo entra em fila de semanas.
- A empresa mudou e o sistema não. O processo real já não é o que está lá dentro, e a equipe usa contornos.
- Não dá para integrar. A conversa com qualquer ferramenta nova termina em exportação manual.
- O fornecedor é único e insubstituível. Trocar significa recomeçar, e ele sabe disso.
- A tecnologia saiu de suporte. Versão sem atualização de segurança é risco que não pode ser adiado.
- Ninguém quer trabalhar nele. Contratar para manter aquele sistema virou problema por si só.
Um sinal isolado não decide nada. Três ou mais ao mesmo tempo indicam que o sistema deixou de ser ferramenta e virou restrição do negócio.
As quatro saídas, e o que cada uma custa
A conversa costuma ser colocada como “manter ou refazer”, e essa é uma falsa escolha. Existem quatro caminhos, e o mais caro é justamente o que parece mais óbvio.
| Saída | Quando faz sentido | O risco |
|---|---|---|
| Manter e conter | O sistema é estável e a empresa não vai mudar de processo tão cedo | Adiar a decisão até que ela seja tomada por uma falha |
| Integrar por fora | O miolo funciona e o problema é isolamento | Camada de integração que vira um segundo sistema para manter |
| Substituir por pronto | O processo é comum ao mercado e não é diferencial da empresa | Adaptar a operação ao produto, e descobrir tarde o que ele não faz |
| Reescrever por partes | A regra é do negócio e o sistema é vantagem competitiva | Virar projeto sem fim se não for fatiado por área de uso |
A quinta opção, reescrever tudo de uma vez e trocar num único dia, é a que mais aparece em conversa e a que mais fracassa. Ela exige congelar a operação enquanto se constrói e acertar todas as regras na primeira tentativa, incluindo as que ninguém lembra que existem.
O critério para escolher
Duas perguntas resolvem a maior parte dos casos, e nenhuma delas é técnica.
A primeira: este processo é diferencial da empresa ou é commodity? Folha de pagamento, nota fiscal e contabilidade são commodity, e produto pronto quase sempre ganha. O jeito específico como a sua empresa atende, precifica ou opera é diferencial, e é justamente o que nenhum produto de prateleira entrega. O recorte dessa decisão está em quando a ferramenta interna tem potencial de produto.
A segunda: o que muda nos próximos dois anos? Se a empresa vai dobrar de volume, entrar em outro mercado ou mudar o modelo de cobrança, o sistema precisa acompanhar. Se a operação está estável e o plano é continuar assim, conter e integrar é decisão legítima, não covardia.
Vale desconfiar de um argumento comum: “a tecnologia é antiga”. Sozinho, isso não decide nada. O que decide é o custo de mudar, o risco concentrado e o teto de crescimento. Um sistema em tecnologia antiga com regras claras e alguém que o mantém é menos problema que um sistema moderno que ninguém entende. O peso da escolha de stack, quando se reescreve, está em por que escolhemos Ruby on Rails.
Por onde começar sem parar a operação
O caminho que funciona é sempre por fatias, com a operação rodando. Primeiro se mapeiam as regras que ninguém documentou, entrevistando quem usa o sistema e não quem o escreveu. Depois se escolhe a fatia de maior dor e menor risco, quase sempre uma área de uso inteira e não uma funcionalidade solta. Essa fatia é reescrita, colocada em produção ao lado do sistema antigo e só então a próxima começa.
Duas regras evitam o projeto sem fim. A primeira é que cada fatia precisa entregar valor sozinha, mesmo que o resto do sistema antigo continue de pé por mais um ano. A segunda é que os dados são o problema mais difícil, não as telas: migração mal planejada é o que costuma atrasar esse tipo de trabalho.
Se a conclusão for reescrever, o que vem antes é o escopo, e não o orçamento: o método está em como definir o escopo de um produto digital, com as faixas de custo em quanto custa desenvolver um produto digital. Se a conclusão for contratar quem faça, os modelos e o que esperar de cada um estão em desenvolvimento de software e em o que é uma software house.
Perguntas frequentes
O que é um sistema legado?
É um sistema que continua sustentando a operação, mas que se tornou difícil e arriscado de mudar. A idade não define: um sistema de doze anos bem documentado é um ativo, e um de três anos que ninguém entende já é legado. O que caracteriza é a combinação de regras não documentadas, medo de alterar, isolamento de outras ferramentas e dependência de um fornecedor ou de uma pessoa só.
Como saber se meu sistema virou legado?
Procure por seis sinais: toda mudança pequena vira projeto de semanas, o processo real da empresa já não é o que está no sistema, não existe integração possível com ferramentas novas, o fornecedor é único e insubstituível, a tecnologia saiu de suporte de segurança e ninguém quer trabalhar naquele código. Um sinal isolado não decide nada. Três ou mais ao mesmo tempo indicam que o sistema virou restrição do negócio.
Qual o custo real de manter um sistema legado?
A manutenção é a única linha que a empresa costuma enxergar. Faltam quatro: o retrabalho manual da equipe transportando dados, o prazo de mudança que faz a empresa perder oportunidades, o risco concentrado no fornecedor ou na pessoa que entende o sistema, e o teto de crescimento que obriga a contratar mais gente para atender mais volume. Somados, esses quatro costumam superar a manutenção.
Vale mais a pena reescrever ou substituir por um sistema pronto?
Depende de o processo ser diferencial ou commodity. Folha de pagamento, nota fiscal e contabilidade são commodity, e produto pronto quase sempre ganha. O jeito específico como a sua empresa atende, precifica ou opera é diferencial competitivo, e nenhum produto de prateleira entrega isso sem obrigar a operação a se adaptar a ele.
Quais são as saídas para um sistema legado?
Quatro. Manter e conter, quando o sistema é estável e o processo não vai mudar. Integrar por fora, quando o miolo funciona e o problema é isolamento. Substituir por produto pronto, quando o processo é comum ao mercado. E reescrever por partes, quando a regra é do negócio e representa vantagem competitiva. A quinta opção, reescrever tudo e trocar num único dia, é a que mais fracassa.
Por que reescrever tudo de uma vez costuma dar errado?
Porque exige duas coisas improváveis ao mesmo tempo: congelar a evolução da operação durante a construção e acertar todas as regras na primeira tentativa, incluindo as que ninguém lembra que existem. Enquanto o novo é construído, o negócio continua mudando, e o projeto persegue um alvo em movimento. A saída é fatiar por área de uso, com cada fatia indo para produção ao lado do sistema antigo.
Por onde começar a modernização de um sistema legado?
Pelo mapeamento das regras que ninguém documentou, entrevistando quem usa o sistema, não quem o escreveu. Depois se escolhe a fatia de maior dor e menor risco, quase sempre uma área de uso inteira. Essa fatia é reescrita, entra em produção ao lado do sistema antigo, e só então a próxima começa. Cada fatia precisa entregar valor sozinha, mesmo que o resto continue de pé.
Tecnologia antiga é motivo suficiente para trocar um sistema?
Não sozinha. O que decide é o custo de mudar, o risco concentrado e o teto de crescimento. Um sistema em tecnologia antiga, com regras claras e alguém que o mantenha, é menos problema que um sistema moderno que ninguém entende. A exceção é versão sem atualização de segurança, que é risco que não admite adiamento.
Dá para modernizar sem parar a operação?
Dá, e é a única forma que funciona na prática. O sistema novo entra por fatias, convivendo com o antigo, e cada área de uso migra quando sua parte está pronta e testada. O ponto mais delicado não são as telas, é a migração de dados: é ela que costuma atrasar esse tipo de trabalho quando não é planejada desde o início.
Quanto tempo leva modernizar um sistema legado?
Varia com o tamanho da regra de negócio, não com o tamanho da tela. Um mapeamento de regras leva de semanas a poucos meses, e cada fatia reescrita costuma levar de dois a quatro meses até entrar em produção. O prazo total só é confiável depois do mapeamento, e qualquer estimativa dada antes dele é chute com aparência de plano.
