O maior problema de um sistema legado não é a linguagem
Leitura: ~9 minutos
TL;DR
O maior problema de um sistema legado não é a linguagem — COBOL, Clipper, Delphi ou Visual Basic funcionam. É aquilo que ninguém mais sabe explicar: regras de negócio escondidas em eventos de tela, procedures e cálculos sem documentação. Reescrever em Angular sem mapear esse conhecimento antes não moderniza nada — só recicla o legado com sintaxe nova. Diagnóstico antes da modernização, sempre.
🎧 Ouvir resumo (56 seg) — voz gerada por IA, narração dos pontos principais do post.
Você já imaginou pegar um sistema que funciona há 20 ou 30 anos, entregar seu código a uma inteligência artificial e pedir que ela o transforme em uma aplicação moderna? Parece simples. Mas a IA pode entender o código sem compreender o negócio que ele mantém funcionando.
E essa diferença — entender vs. compreender — é exatamente onde as modernizações quebram.
A evolução que virou camada sobre camada
Quem trabalha com sistemas legados não encontrou um único sistema. Encontrou estratos.
O primeiro é COBOL, processando folha de pagamento e contabilidade em mainframe, com regras de cálculo que ninguém toca desde 1985. Sobre ele, Clipper e dBase na década de 1990: o terminal de vendas, o estoque, o registro na tela verde. Sobre esse, Delphi e Visual Basic no fim dos anos 90 — cada versão nova ganhando tela nova, sem que a antiga saísse do ar. Depois Java e .NET entraram, também em camada, integrando o que existia com o que chegava.
O resultado é um sítio arqueológico em execução. Cada camada ainda processa partes do negócio. Nenhuma delas pode ser desligada sem que alguém prove, primeiro, o que ela processa.
Eu vivo isso na prática. O Posseidom, o ERP que a minha empresa desenvolve, nasceu em Delphi e começou a ser reescrito em .NET na década passada. Não é exceção: é o ciclo padrão da indústria. O que muda de empresa para empresa é o método.
O código que ninguém mais sabe explicar
O código de um sistema de 30 anos continua compilando. O que quebrou é outra coisa: a cadeia de transmissão do conhecimento.
Quem escreveu a regra se aposentou. Quem revisou saiu antes de documentar. O membro da equipe que sabia por que aquele cálculo de desconto tem uma exceção para a região X mudou de área. Hoje existe uma linha de código que funciona, ninguém se atreve a mexer nela, e ninguém sabe explicar por que ela existe.
Isso é dívida técnica invisível — o tipo que não aparece em análise de código, porque o compilador não reclama de lógica executando perfeitamente bem. Aparece quando alguém precisa alterá-la.
Regras de negócio escondidas nos detalhes
Onde essa lógica vive? Raramente onde se espera.
- Eventos de tela. No evento `OnExit` daquele campo de vencimento, alguém escreveu uma validação que reprime desconto para cliente com saldo vencido acima de X. Não existe na specification. Existe no Delphi.
- Procedures de banco. A procedure que calcula o custo médio tem uma linha com ROUND em posição que ninguém sabe se é intencional. Mudar o arredondamento muda o lucro reportado. Quem assina embaixo?
- Cálculos acumulados. Fórmulas de imposto, comissão, prazo médio. Cada uma com 10 anos de exceções acumuladas que a equipe atual desconhece: “isso é para caso do cliente A, não mexa”.
O compilador entende tudo isso. O LLM também entende. Nenhum dos dois entende o negócio que aquilo sustenta — porque o negócio existe na cabeça de pessoas, em memórias de reuniões de 2012, em e-mail apagado.
Aqui está a resposta para a pergunta da abertura: IA acelera migração de software porque analisa código em velocidade que ninguém alcança. Mas migração de software com IA que copia a lógica sem questionar a intenção apenas transporta o desconhecido para a linguagem nova — preservando o bug, preservando a exceção esquecida, e adicionando um novo problema: a camada de tradução também não é documentada.
Modernizar não é reescrever
Este é o erro mais caro. Trocar Delphi por Angular é fácil de vender: interface nova, stack nova, recrutamento sem problema. O problema: se a arquitetura não muda, você criou um legado novo.
A reescrita espelha entidades, telas e estruturas idênticas. Se o sistema antigo tem 80 tabelas sem normalizar e regra escondida em evento de tela — o Angular agora tem 80 tabelas sem normalizar e regra escondida em hook de componente. A dor migrou para uma stack que a empresa sabe menos manter.
A diferença entre modernização real e reescrita superficial:
| Reescrita superficial | Modernização real |
|---|---|
| Troca sintaxe, mantém estrutura | Redesenha arquitetura |
| Copia regras escondidas | Expõe e documenta as regras |
| Preserva acoplamento (entidade acoplada) | Define fronteiras (API, módulos) |
| Começa pela tela | Começa pelo diagnóstico |
A decisão exige olhar para quatro dimensões que não são técnicas: escopo (o que entra na primeira onda), custo (direto e o custo de oportunidade da equipe parada), prazo (meses reais, não a estimativa), e — a que quase todo mundo ignora — continuidade operacional (a empresa continua faturando durante a transição?).
A reflexão
Um sistema legado não é apenas código antigo. É conhecimento empresarial acumulado, muitas vezes sem documentação, que precisa ser preservado antes de ser transformado.
O risco de modernizar sem diagnóstico não é técnico. É que um pedaço do único registro de como sua empresa funciona — que sobreviveu a 30 anos de mudanças de equipe, de CEO e de erp de concorrente — se perca para sempre.
A linguagem é a parte fácil. O conhecimento é que vale alguma coisa.
O que vem agora
Este é o primeiro post de uma série. Se a tese é que o conhecimento precisa ser mapeado antes de qualquer transformação, a pergunta imediata é: como descobrir tudo o que o sistema faz antes de alterá-lo?
É o assunto da Parte 2: um método prático de diagnóstico que eu uso, com IA como acelerador — sabendo exatamente onde ela é forte e onde vai mentir com convicção.
A pergunta que deixo: se você precisasse explicar, hoje, por que seu sistema calcula o imposto da empresa do jeito que calcula — você conseguiria?
3 Comentários