Modernizar ou reescrever? Como decidir o futuro de um sistema legado

Reescrever do zero é a decisão mais tentadora e a mais cara. O sistema antigo carrega regras de negócio que ninguém documentou e que só aparecem quando quebram. A maior parte dos projetos de reescrita estoura prazo exatamente por isso.

Antes de decidir, mapeamos o legado como ele é: componentes, dependências, integrações, dados e quem usa o quê. Esse mapa costuma revelar que 20% do sistema concentra 80% do valor e que o resto pode ser desligado ou substituído por algo de prateleira.

Modernizar por etapas preserva mais valor na maioria dos casos: atualizar a stack (PHP 7 para 8, MariaDB para Aurora, Apache para Nginx), mover a hospedagem, extrair um serviço por vez, manter URLs e integrações. A operação não para.

Um portal com cem mil publicações saiu de um data center Oracle para a AWS sem uma escrita sequer no sistema antigo. Canário em um post, depois lotes, depois delta incremental até a paridade. O DNS só virou quando o novo estava igual ao velho.

Reescrever faz sentido quando o custo de manter supera o de refazer, quando a tecnologia impede uma exigência regulatória ou de negócio, ou quando o sistema será substituído por um produto novo com outro modelo. Mesmo assim, a migração de dados segue as mesmas regras: idempotência, canário, rollback.

A pergunta certa não é qual caminho é mais moderno, é qual tem menos risco por real investido nos próximos 24 meses.

As cinco perguntas do mapa do legado

O mapa do legado responde a cinco perguntas, e a decisão sai delas. Primeira: as regras de negócio embutidas no sistema ainda descrevem como a empresa opera? Se a operação mudou e o sistema não, há menos a preservar. Segunda: o código pode ser lido, testado e alterado com segurança, ou é uma caixa preta? Um sistema legível se moderniza por partes; uma caixa preta pede reescrita com o legado somente leitura ao lado. Terceira: os dados estão íntegros? Anos de exceções não tratadas viram semanas de higienização em qualquer um dos caminhos, e o custo delas precisa entrar na conta. Quarta: quantos sistemas e integrações dependem deste, e com que contratos? Cada integração é um ponto de ruptura no dia da virada. Quinta: existe alguém que entenda o todo? Se a resposta é não, a primeira etapa de qualquer caminho é documentar, e o prazo precisa contemplar isso.

Os caminhos intermediários

Entre manter tudo e reescrever tudo há uma escada, e a orientação prescritiva da AWS a descreve em sete estratégias. Retire: desligar o que ninguém usa, e é surpreendente quanto se encontra. Retain: manter o que funciona e não vale a pena tocar agora. Rehost: mover como está para infraestrutura nova, o menor risco e a menor economia. Replatform: mover com ajustes de plataforma, como atualizar a versão da linguagem, trocar o banco por um gerenciado e o servidor web por um mais leve; costuma ser o melhor retorno por real investido. Repurchase: substituir por um produto de mercado quando o processo não é diferencial. Refactor: redesenhar a arquitetura, o caminho mais caro e o único que resolve limites estruturais. Um mesmo sistema pode passar por três desses degraus em ondas diferentes; a decisão não é única nem definitiva.

Como fica o custo em cada caminho

Rehost custa infraestrutura e uma janela de migração, e devolve pouco além de sair do data center. Replatform custa semanas de engenharia por componente e devolve custo de infraestrutura menor, segurança em dia e um sistema que volta a poder ser alterado. Refactor por partes, extraindo um serviço por vez, custa meses e devolve escalabilidade e velocidade de entrega. Reescrever tudo custa um ou dois anos em que dois sistemas coexistem e o negócio paga pelos dois. O mapa do legado transforma essa lista em um plano por fases, cada uma com escopo, marco, critério de aceite e preço, e a empresa paga por fase entregue. Isso também expõe o custo de não fazer nada: infraestrutura desproporcional, pessoas dedicadas a manter o que existe e oportunidades que não acontecem porque o sistema não permite.

O que não pode faltar em nenhum dos caminhos

• Legado mantido somente leitura durante a transição, como referência para validar paridade
• Canário antes do lote: um registro, uma rota, um serviço migrado e validado antes de qualquer massa
• Migração idempotente, com tabela de controle, que pode ser rerodada sem duplicar
• URLs, integrações e relatórios preservados ou redirecionados, com plano por dependência
• Cargas de dados auditadas, com execução a seco antes da real
• Cutover planejado, com rollback, e só quando o novo está em paridade
• Documentação, treinamento e transferência para o time que vai sustentar

O que os dados dizem sobre reescrever

A tentação de reescrever tudo esbarra em três conjuntos de evidências. O estudo da McKinsey com a Universidade de Oxford, sobre mais de 5.400 projetos de TI, encontrou que projetos grandes (acima de US$ 15 milhões) estouram o orçamento em 45%, o prazo em 7% e entregam 56% menos valor do que o previsto. O CHAOS Report, do Standish Group, mostra ao longo de duas décadas que a taxa de sucesso cai à medida que o projeto cresce: projetos pequenos têm sucesso na maioria dos casos; os muito grandes, raramente. E a orientação prescritiva da AWS, ao descrever as sete estratégias de migração, desaconselha refatorar durante uma migração de grande porte, exatamente porque combina dois riscos em um só projeto. Reescrever por etapas, extraindo um serviço por vez, é a forma de manter cada pedaço no tamanho em que projetos dão certo.