Cuándo conviene reparar una aplicación existente y cuándo rehacerla
Reescribir no elimina automáticamente los riesgos. La decisión debe comparar operación actual, deuda, datos y coste de transición.
Rehacer una aplicación puede ser necesario, pero también sustituye problemas conocidos por riesgos nuevos. Antes de decidir conviene comparar la capacidad del sistema actual para seguir cambiando, el coste de estabilizarlo y la dificultad de migrar datos y operación a una versión nueva.
Cuándo reparar suele ser razonable
Mantener y mejorar tiene sentido cuando los flujos principales funcionan, los datos son fiables y la arquitectura permite cambios localizados. Dependencias antiguas, pruebas escasas o documentación incompleta pueden abordarse por etapas si existe una forma segura de desplegar y observar.
Cuándo una reconstrucción merece evaluarse
La reconstrucción gana peso cuando el sistema no puede ejecutar sobre versiones soportadas, el modelo de datos impide requisitos esenciales, cada cambio afecta zonas impredecibles o la plataforma original ya no puede operarse. Aun así, hace falta demostrar que una base nueva resuelve esas restricciones.
El coste oculto de empezar de cero
La aplicación existente contiene reglas que quizá nunca se documentaron: permisos, excepciones, reportes y comportamientos que los usuarios dan por hechos. Reconstruir implica descubrirlas, priorizarlas, migrar datos y mantener ambos sistemas durante la transición. El código nuevo es solo una parte del proyecto.
La alternativa gradual
A veces conviene estabilizar primero y sustituir después módulos con límites claros. Una API, un proceso de datos o una interfaz nueva pueden convivir temporalmente con el sistema anterior. Esta estrategia permite validar decisiones y evita concentrar todo el riesgo en un único cambio.
Qué comparar antes de decidir
Compara criticidad, frecuencia de cambio, soporte de dependencias, calidad de datos, capacidad de prueba, coste operativo y ventana de transición. Incluye también el conocimiento del equipo: una tecnología más moderna no ayuda si nadie puede mantenerla.
Una decisión por fases
El primer entregable puede ser una auditoría técnica y un pequeño cambio representativo. Con esa evidencia se estima qué partes conviene conservar, modernizar o reemplazar. Reparar y rehacer no siempre son opciones excluyentes; pueden formar parte de la misma ruta.