No reemplaces más de lo necesario.

• Cada release se siente riesgoso — Pocos tests, deployment manual, conocimiento concentrado o componentes demasiado acoplados.
• Actualizar una librería rompe otra cosa — Versiones antiguas y dependencias que limitan seguridad, compatibilidad o mantenimiento.
• El sistema todavía sirve, pero cambiarlo es lento — La operación depende de él; reemplazarlo de golpe puede introducir más riesgo que beneficio.
• Integrar algo nuevo es cada vez más difícil — No existen APIs claras o la lógica está mezclada con interfaz, base de datos y reglas históricas.
• Nadie quiere tocar ciertas partes — Es una señal de deuda técnica y conocimiento perdido, no una prueba automática de que haya que reescribir.

Un assessment puede revisar:

• versiones;
• dependencias;
• arquitectura;
• módulos;
• datos;
• integraciones;
• build;
• testing;
• deployment;
• configuración;
• seguridad técnica relevante;
• observabilidad;
• ownership de componentes;
• criticidad operacional;
• facilidad de rollback.
• Salida esperada — Un mapa de opciones con prioridad y riesgo, no una lista de tecnologías nuevas.

Ejemplo conceptual: No todos los proyectos requieren todos los pasos.

• estabilizar build;
• crear tests de caracterización;
• separar configuración;
• añadir observabilidad;
• contenerizar si aporta valor;
• exponer API alrededor de un módulo;
• migrar una experiencia visible;
• actualizar runtime/framework;
• retirar componentes antiguos;
• medir y decidir el siguiente paso.

• Lo que evaluamos
• impacto de downtime;
• reversibilidad;
• datos;
• integraciones;
• dependencias externas;
• equipo disponible;
• ventanas de cambio;
• pruebas existentes;
• observabilidad;
• capacidad de rollback.
• Principio — > Una modernización no es buena porque termine en una arquitectura más moderna. Es buena si mejora la capacidad de operar y cambiar el sistema con un riesgo aceptable.

Elegimos los patrones según el volumen, los fallos posibles y quién operará la integración.

• Patrones que pueden aparecer
• strangler pattern;
• modularización;
• APIs alrededor de legacy;
• event/messaging cuando existe una razón;
• separación frontend/backend;
• contenerización;
• replatforming;
• upgrade incremental de Java/Spring;
• migración de base de datos cuando corresponda.