Seu time quer reescrever um sistema legado. Como você decide?

Tenha substituição incremental como padrão, em vez de reescrita completa. Reescritas subestimam o comportamento codificado no sistema antigo e obrigam você a manter duas coisas enquanto não entrega nada novo. Prefira estrangular o sistema pedaço por pedaço atrás de uma interface estável, com cada passo entregando valor por conta própria. Considere reescrita completa apenas quando a plataforma é genuinamente insustentável e você consegue proteger o cronograma da pressão por funcionalidades.

Meu padrão é não, e então tento entender o que eles realmente querem, porque reescrita costuma ser sintoma. Às vezes é genuinamente uma plataforma morta, e às vezes é que a suíte de testes leva quarenta minutos e cada mudança é aterrorizante, o que é um problema bem mais barato de resolver. Quando substituir é o certo, quero que seja incremental: colocar uma interface na frente do sistema antigo, mover uma capacidade por vez para trás dela e garantir que cada fatia seja publicável e entregue algo por si só. Assim o projeto sobrevive a uma repriorização, o que uma reescrita big bang de dois anos nunca faz. No meu último time substituímos um pipeline de pedidos legado desse jeito ao longo de uns nove meses, e pausamos duas vezes por razões de negócio sem perder nada. O caso em que eu faria uma reescrita de verdade é quando o runtime ou o framework está fora de suporte sem caminho incremental, e mesmo aí quero uma conversa explícita e por escrito com a liderança sobre o congelamento de funcionalidades, porque a falha clássica é uma reescrita mais um roadmap completo.