¿Modernizar o rehacer una aplicación?

La antigüedad no decide por sí sola

Una aplicación puede ser antigua y cumplir bien su función; otra, relativamente nueva, puede impedir cambios necesarios. Formula primero el objetivo: reducir incidentes, recuperar soporte, integrar un canal, acortar despliegues o eliminar una dependencia. Describe cómo medirlo y qué impacto tiene no actuar.

Después separa síntomas de causas. Incidentes repetidos pueden proceder de una arquitectura frágil, pero también de pruebas incompletas, falta de observabilidad o procesos de cambio. Reescribir sin identificar la causa puede reproducir el problema en una tecnología nueva.

Compara las opciones

Criterio	Modernizar por partes	Rehacer la aplicación
Alcance	Cambios incrementales sobre capacidades existentes	Sustitución amplia del sistema o sus componentes
Conocimiento	Se conserva el comportamiento existente mientras se aprende	Hay que descubrir y reconstruir reglas y casos límite
Continuidad	Puede desplegarse por módulos, según dependencias	Puede exigir coexistencia y migración de datos prolongada
Riesgo	Riesgo localizado, con complejidad temporal entre partes	Riesgo concentrado en alcance, equivalencia y corte
Encaje	Hay componentes aprovechables y objetivo divisible	Una limitación estructural impide cumplir necesidades relevantes

Estas son tendencias, no garantías. La opción correcta depende de arquitectura, equipo, pruebas, datos y calendario.

Haz visible la incertidumbre

Antes de elegir, inventaría integraciones, trabajos programados, permisos, formatos, reglas tácitas y dependencias de proveedores. Habla con usuarios y operadores; contrasta los documentos con comportamiento observado. Identifica datos que quizá no puedan migrarse exactamente y sistemas externos que no controlas.

Puntúa de forma cualitativa y justificada: valor esperado, coste de mantenimiento, capacidad de cambio, riesgos de continuidad y esfuerzo de transición. No ocultes falta de información con una puntuación numérica precisa. Para las incógnitas críticas, define una investigación o prueba acotada.

Ejemplo de evaluación

Imagina una aplicación interna que gestiona pedidos y todavía recibe cambios de negocio. Si los fallos se concentran en un módulo con reglas claras y existen pruebas para el resto, aislar y modernizar ese módulo puede permitir aprender y entregar valor antes. Si el sistema depende de una base de datos sin soporte y no puede cumplir un requisito de seguridad, investiga si puede actualizarse gradualmente; si no, compara una sustitución con un plan explícito de datos, convivencia y reversión.

El ejemplo es un método de análisis, no un caso de cliente ni una recomendación para una aplicación concreta. La decisión requiere evidencia de tu sistema.

Evalúa por etapas

1. Define resultados y restricciones con negocio y operaciones.
2. Haz un mapa de componentes y dependencias verificadas.
3. Prueba las incógnitas de mayor riesgo: rendimiento, compatibilidad, migración de datos o integración.
4. Compara coste de construcción, convivencia, operación y retirada.
5. Elige un corte pequeño con criterios de aceptación y vuelta atrás.

La guía de modernización de aplicaciones de AWS trata decisiones de modernización de persistencia como parte de un cambio más amplio; consulta documentación equivalente para tu plataforma y arquitectura. Documenta qué resultados modificarían la decisión. Mantén abierta la opción de renovar, sustituir o retirar componentes si el valor esperado cambia.