/01
Comenzar por el costo del problema
Que un sistema sea antiguo no justifica por sí solo reemplazarlo. Documente retrasos en entregas, incidentes evitables, costos de soporte, exposición de seguridad y limitaciones de integración. Confirme dónde ocurre el problema y quién lo sufre. Establezca una línea base antes de elegir tecnología.
/02
Mapear dependencias y recuperación
Identifique componentes, flujos de datos, integraciones externas y responsables operativos. Incluya respaldos, procedimientos de restauración y despliegues. Un cambio de base de datos sin reversión requiere controles distintos de un ajuste visual. La falta de información es una razón para investigar, no para suponer.
/03
Elegir la mejora reversible más pequeña
Una primera intervención útil puede ser actualizar una dependencia, agregar una API alrededor de un módulo frágil, optimizar consultas, automatizar pruebas o mejorar despliegues. Defina criterios de éxito y reversión. Mida antes de ampliar el cambio.
/04
Reservar reescrituras para casos justificados
Algunas aplicaciones necesitan reemplazo cuando ya no cumplen requisitos esenciales o no existe mantenimiento viable. Compare esa alternativa con mejoras graduales, costos totales, riesgos de transición y la carga de operar sistemas viejos y nuevos simultáneamente.