Tu equipo quiere reescribir un sistema legacy. ¿Cómo lo decides?

Ten como opción por defecto el reemplazo incremental antes que una reescritura completa. Las reescrituras subestiman el comportamiento codificado en el sistema viejo y te obligan a mantener dos cosas sin entregar nada nuevo. Prefiere estrangular el sistema pieza a pieza detrás de una interfaz estable, con cada paso entregando valor por sí mismo. Plantéate una reescritura completa solo cuando la plataforma sea de verdad insostenible y puedas proteger el calendario de la presión de funcionalidades.

Mi respuesta por defecto es no, y luego intento entender qué quieren de verdad, porque reescribir suele ser un síntoma. A veces es realmente una plataforma muerta, y a veces es que la suite de tests tarda cuarenta minutos y cada cambio da pánico, que es un problema mucho más barato de arreglar. Cuando el reemplazo es lo correcto, lo quiero incremental: pones una interfaz delante del sistema viejo, mueves una capacidad cada vez por detrás de ella y te aseguras de que cada porción sea publicable y entregue algo por sí sola. Así el proyecto sobrevive a una repriorización, cosa que una reescritura de dos años a lo grande no hace nunca. En mi último equipo reemplazamos así un pipeline de pedidos legacy en unos nueve meses, y lo pausamos dos veces por motivos de negocio sin perder nada. El caso en el que sí haría una reescritura real es cuando el runtime o el framework está fuera de soporte sin ruta incremental, e incluso entonces quiero una conversación explícita y por escrito con dirección sobre el congelamiento de funcionalidades, porque el fallo clásico es una reescritura más un roadmap completo.