Modernizar o legado sem parar o negócio

Todo o sistema legado que ainda está em produção é, antes de mais, um sistema que funciona. Processa pagamentos, emite documentos e sustenta a receita da empresa. O problema é que mudar ficou caro: cada alteração demora meses, poucas pessoas conhecem o código e a integração com os canais digitais transforma-se num remendo. A tentação é reescrever tudo de raiz. Na experiência com grandes bancos, meios de pagamento e setor público, a grande mudança de uma só vez costuma ser o caminho mais arriscado. O que funciona é modernizar por partes, com a operação a correr.

Strangler fig: substituir aos poucos

O padrão strangler fig propõe construir o sistema novo em torno do antigo, assumindo uma funcionalidade de cada vez. Cada parte migrada passa a ser servida pelo novo, e o legado vai encolhendo até poder ser desligado. O risco fica repartido em entregas pequenas, e cada etapa gera valor desde logo.

APIs à frente do legado

O primeiro passo costuma ser uma camada de APIs entre os canais e o sistema antigo. Os consumidores passam a comunicar com um contrato estável, sem saber o que está por trás. Assim, é possível trocar a implementação de uma rota sem mexer em aplicações, parceiros ou integrações. Esta camada é também o sítio certo para a observabilidade, a segurança e o controlo de tráfego.

Migrar por domínios, não por camadas

Migrar toda a base de dados ou toda a interface de uma vez cria dependências enormes. É preferível recortar por domínio de negócio: registo de clientes, cobranças, limites, apoio ao cliente. Cada domínio entra em produção com um responsável, métricas e uma equipa que responde por ele de ponta a ponta.

Dados: a parte mais difícil

O código reescreve-se; os dados têm de ser preservados. Durante a transição, o legado e o sistema novo coexistem, e é preciso definir qual é a fonte de verdade de cada informação. Sincronização por eventos, reconciliação diária e regras claras de escrita evitam divergências que só aparecem no fecho do mês.

Modernizar não é trocar de tecnologia. É reduzir o custo de mudar sem aumentar o risco de operar.

Reescrever ou encapsular?

• Encapsular: quando a regra de negócio é estável, o sistema é fiável e o problema está na integração ou na experiência do utilizador.
• Reescrever: quando a regra muda com frequência, a manutenção bloqueia a evolução ou a tecnologia já não tem suporte nem profissionais disponíveis.
• Testes de regressão primeiro: antes de mexer, registe o comportamento atual com testes automatizados e compare os resultados do legado e do novo. Sem isso, não há forma de provar que nada se partiu.
• Caminho de regresso: cada migração precisa de uma passagem gradual de tráfego e de um retrocesso testado.

Com este método, a modernização deixa de ser uma aposta de alto risco e passa a ser uma sequência de entregas previsíveis. O negócio continua a funcionar, e o legado sai de cena ao ritmo que a operação aguenta.