A reescrita total é a tentação mais cara
Todo time técnico que herda um sistema legado tem o mesmo primeiro impulso: jogar fora e começar de novo. É compreensível — ler código alheio e antigo é desagradável, e a versão imaginada é sempre melhor que a versão real.
O problema é que a reescrita total troca um risco conhecido por um desconhecido. O sistema legado é feio, mas funciona e já absorveu anos de regras de exceção que ninguém documentou. A reescrita começa sem essas regras e vai reencontrando cada uma delas em produção, uma de cada vez, na forma de incidente.
Reescrever se justifica quando a tecnologia base saiu de suporte, quando não existe mais no mercado quem saiba mantê-la, ou quando a arquitetura impede uma mudança de negócio que já foi decidida. Fora desses casos, costuma ser a saída mais cara para um problema que tinha saída mais barata.
Migrar resolve infraestrutura, não arquitetura
Migrar é tirar o sistema de onde ele está e colocá-lo em outro lugar — tipicamente do datacenter para a nuvem — mexendo o mínimo possível no código.
Funciona bem quando a dor é de custo, de capacidade ou de fim de contrato de hospedagem. Não funciona quando a dor é de velocidade de mudança: um sistema difícil de alterar continua difícil de alterar depois de mudar de endereço.
Vale o alerta porque migração para nuvem é vendida com frequência como modernização. Levar para a nuvem um sistema mal estruturado costuma só mudar o endereço do problema — e aumentar a conta, porque o modelo de cobrança da nuvem pune justamente arquitetura ineficiente.
Manter é uma decisão legítima
Parte do sistema legado provavelmente não precisa mudar. Se um módulo é estável, raramente alterado e não bloqueia nada, mexer nele é gastar dinheiro para adicionar risco.
A diferença entre manter por decisão e manter por omissão é ter escrito o porquê em algum lugar, junto com o gatilho que faria isso mudar. "Mantemos como está até que precise integrar com o novo canal de vendas" é uma decisão. Não falar sobre o assunto não é.
Na prática, a resposta é sempre uma combinação
Sistema legado raramente é uma coisa só. É um conjunto de módulos com idades, criticidades e taxas de mudança diferentes, e cada um comporta uma decisão diferente. O trabalho de modernização começa por separar esse bloco em partes.
No projeto que fizemos para o registro de imóveis, o desafio não era substituir os sistemas dos cartórios — eram milhares deles, e são eles que sustentam a atividade registral todo dia. Construímos por cima a camada que unifica a pesquisa e o acesso, integrando os legados por trás. Eles seguiram operando durante toda a transição, e o resultado atende 3 milhões de usuários por mês.
É o padrão que funciona: o novo assume função por função, com o antigo no ar e com caminho de volta a cada etapa. O legado sai de cena quando não resta nada crítico nele — não antes, e não num fim de semana de virada.
Por onde começar quando ninguém documentou nada
Documentação ausente é o cenário comum, não a exceção, e não é pré-requisito para começar. O mapeamento se faz lendo o que existe: código, banco de dados, integrações e, principalmente, as pessoas que operam o sistema todo dia.
O que você quer ao fim desse mapeamento é uma lista de módulos com três colunas: o quanto é crítico, o quanto muda, e o que quebra se parar. Com isso na mão, a escolha entre reescrever, migrar e manter deixa de ser preferência técnica e vira decisão de negócio.