Sistema legado. A expressão já carrega um peso negativo. Muitas empresas tratam seus sistemas antigos como um fracasso, um erro do passado que precisa ser extinto o mais rápido possível. Essa visão é equivocada – e perigosa.
A verdade é que todo sistema que gera valor é um legado em potencial. Um sistema que processa pedidos, armazena dados de clientes ou controla estoque há dez anos não é um problema – é um ativo. Ele representa conhecimento de negócio acumulado, regras testadas em produção, fluxos que geram receita.
O erro não é ter legado. É não saber conviver com ele. Neste post, vamos mostrar estratégias práticas para que o velho e o novo coexistam de forma saudável, sem apagões, sem riscos desnecessários e sem desperdício.
Por que o legado é visto como vilão?
Antes de falarmos de soluções, vamos entender o preconceito:
| Percepção comum | Realidade |
|---|---|
| “Código feio e mal escrito” | Pode ter sido excelente para as restrições da época (hardware, prazo, time) |
| “Tecnologia obsoleta” | Obsoleta para quem? Ainda roda e paga as contas |
| “Ninguém quer mexer” | Justamente por isso ele tem valor: poucos entendem, mas o negócio depende |
| “Precisa ser reescrito” | Reescrever é a opção mais cara e arriscada, não a primeira |
Um sistema legado bem compreendido e bem gerenciado pode continuar gerando valor por muitos anos. A chave é isolar, encapsular e evoluir gradualmente.
Estratégia 1: Anti-Corruption Layer (ACL) – o tradutor entre mundos
Proposto por Eric Evans no Domain-Driven Design, o Anti-Corruption Layer é uma camada de tradução que impede que modelos e conceitos do legado “contaminem” o novo sistema.
Exemplo: O legado armazena “cli_end” como código de cliente e “vlr_tot” como valor total. O novo sistema quer “CustomerId” e “TotalAmount”. A ACL faz a tradução.
Benefícios: O novo sistema não precisa conhecer os detalhes bizarros do legado. Se o legado mudar, só a ACL é ajustada.
Estratégia 2: Strangler Pattern (já mencionado em posts anteriores, aqui com foco em convivência)
Em vez de matar o legado de uma vez, você o “estrangula” gradualmente. A cada funcionalidade extraída, o legado perde importância.
Como funciona na convivência:
- Mantenha o legado rodando para tudo.
- Implemente uma nova funcionalidade no novo sistema.
- Use um roteador (proxy, gateway) para enviar apenas aquela funcionalidade para o novo sistema.
- O legado continua atendendo o resto.
- Repita até que o legado só atenda requisições residuais – e então pode ser desligado.
Conviver bem significa: durante anos, os dois sistemas podem coexistir. Não há pressa para “matar” o legado.
Estratégia 3: Banco de dados compartilhado com governança rigorosa
Às vezes, separar bancos é caro ou inviável. O novo sistema precisa ler/escrever nas mesmas tabelas do legado. Isso é possível, mas exige regras:
- Tabelas de escrita única: cada sistema escreve apenas em suas tabelas. O outro lê.
- Visões ou tabelas de sincronização: o novo sistema escreve em tabelas próprias, e um processo noturno sincroniza com o legado.
- Colunas de controle: adicione colunas como
source_systempara saber quem criou/alterou o registro. - Triggers ou eventos de mudança: quando o legado altera um dado, publique um evento para o novo sistema reagir.
Risco: Alto. Só faça isso se for temporário ou se houver disciplina total.
Estratégia 4: API Facade – o legado como provedor de serviços
Transforme o legado em uma API. Em vez de mexer no código interno, crie uma camada HTTP (ou fila) na frente.
Como fazer:
- Escreva adaptadores que chamam funções do legado (até mesmo via linha de comando ou acesso direto a banco).
- Exponha esses adaptadores como endpoints REST ou mensagens.
- O novo sistema consome a API sem saber que está falando com um COBOL de 1995.
Vantagem: Você ganha interoperabilidade sem risco de alterar o legado.
Estratégia 5: Event Interception – capture mudanças sem modificar o legado
Se o legado não pode ser alterado para publicar eventos, você pode interceptar as mudanças no nível do banco de dados.
Técnicas:
- Trigger no banco de dados – insere uma linha em tabela de eventos.
- Change Data Capture (CDC) – ferramentas como Debezium monitoram o log de transações do banco e publicam eventos em Kafka.
- Polling com timestamp – o novo sistema consulta a cada X minutos a tabela de “última atualização” (se existir uma coluna
updated_at).
Quando vale a pena reescrever o legado?
Reescrever é caro, demorado e arriscado. Mas há situações em que faz sentido:
| Cenário | Reescrever? |
|---|---|
| O legado é estável, roda bem, só é chato de dar manutenção | ❌ Não. Encapsule via API. |
| A tecnologia é tão obsoleta que não há mais profissional disponível | ✅ Sim, mas faça por partes. |
| O legado tem bugs críticos que não podem ser corrigidos (falta de documentação, código perdido) | ✅ Sim, mas recrie funcionalidade por funcionalidade. |
| O negócio mudou completamente e o legado não se adapta | ✅ Sim, mas modele o novo negócio primeiro. |
| A equipe quer “usar tecnologia nova” sem justificativa de negócio | ❌ Jamais. Isso é vaidade técnica. |
Regra de ouro: Só reescreva o que você entende completamente. E mesmo assim, faça de forma incremental (strangler).
Convivência saudável: cultura e documentação
Estratégias técnicas são inúteis se o time trata o legado como “lixo”. Mude a cultura:
- Documente o que o legado faz de fato (não como ele faz, mas o comportamento observado).
- Crie testes de caracterização (testes que registram o comportamento atual, para garantir que mudanças não quebrem nada).
- Tenha um “dono do legado” (alguém responsável por conhecer e tomar decisões sobre ele).
- Comemore as vitórias de convivência (ex: “conseguimos extrair o módulo de notificações sem parar o sistema”).
Exemplo real: seguradora convive com legado COBOL por 5 anos
Uma seguradora cliente da Jacobus tinha um core em COBOL rodando em mainframe. Migrar tudo era inviável (centenas de regras atuariais). A solução:
- API Facade em Go na frente do mainframe, expondo operações de cotação e emissão.
- Anti-Corruption Layer traduzindo modelos COBOL para JSON limpo.
- Novos serviços (notificações, portal do cliente) foram construídos do zero, consumindo a API.
- Aos poucos, funcionalidades críticas foram extraídas do COBOL para microsserviços Go (estrangulamento).
Resultado: O COBOL ainda roda. A empresa lançou 15 novos produtos nos últimos 5 anos. O mainframe não é mais o gargalo. E o conhecimento atuarial foi preservado.
Conclusão
Legado não é vergonha. É patrimônio. A inteligência não está em se livrar dele a qualquer custo, mas em conviver bem – isolando, encapsulando, traduzindo e, quando fizer sentido, extraindo partes.
Na Jacobus Software, não julgamos seu legado. Nós o entendemos, respeitamos e construímos pontes para o novo. Porque o objetivo não é apagar o passado – é construir o futuro sem parar o presente.
🏛️ Quer conviver melhor com seu legado?
Nossos especialistas implementam Anti-Corruption Layers, APIs Facade e estratégias de estrangulamento – mantendo o que funciona e evoluindo o que precisa.