Un sistema antiguo puede ser difícil de cambiar y, al mismo tiempo, contener años de reglas de negocio correctas. Reescribirlo desde cero elimina deuda visible, pero también elimina aprendizaje incorporado y obliga a redescubrir excepciones bajo presión.
Modernizar no significa conservarlo todo. Significa cambiar con una secuencia que permita comparar, aprender y volver atrás cuando la evidencia contradice el plan.
Estabilizar antes de separar
Si no existen métricas, logs útiles, copias restaurables o un proceso de despliegue repetible, cualquier extracción tendrá un riesgo difícil de medir. La primera fase suele ser operativa: observar los flujos críticos, reducir variabilidad y documentar dependencias.
Esta etapa también revela qué partes cambian con frecuencia y cuáles son estables. La frontera correcta rara vez coincide con las carpetas del código.
Elegir una costura con valor
Una buena primera separación tiene entradas y salidas reconocibles, volumen controlable y un beneficio que pueda medirse. Puede ser una exportación, un proceso de notificación, un portal o una consulta que hoy bloquea al núcleo.
El objetivo no es crear un microservicio por moda. Es establecer un límite que permita cambiar una capacidad sin coordinar todo el sistema.
Datos: migrar sin perder historia
Los datos exigen más cuidado que el código. Hay que definir autoridad, sincronización, reconciliación y corte. Durante una transición puede existir doble lectura, pero la doble escritura sin control crea divergencias silenciosas.
- Identificar la fuente autoritativa por entidad.
- Versionar transformaciones y conservar rechazos.
- Comparar conteos, totales y muestras semánticas.
- Ensayar restauración y repetición.
- Definir qué ocurre si la nueva ruta falla.
Entregar en cortes reversibles
Cada corte debe limitar usuarios, datos o tráfico. Feature flags, shadow reads y comparación de resultados permiten obtener evidencia antes de retirar el camino anterior. El rollback debe probarse mientras todavía es barato.
La nueva arquitectura no se considera mejor porque usa tecnología reciente. Debe reducir una restricción concreta: tiempo de cambio, fallos, coste, seguridad o capacidad de producto.
Saber cuándo parar
No todo legado necesita desaparecer. Una parte estable, aislada y bien operada puede seguir siendo una decisión razonable. El éxito se mide por la capacidad de evolucionar el negocio, no por el porcentaje de código reescrito.
Preguntas frecuentes
¿Los microservicios son el destino natural de una modernización?
No. Un monolito modular o una extracción limitada pueden reducir complejidad con menos coste operativo.
¿Cuándo debe migrarse la base de datos?
Cuando existe una razón de negocio o control clara y se han definido autoridad, reconciliación, corte y rollback.
¿Cómo se demuestra que una fase funcionó?
Con una métrica vinculada a la restricción original: menor tiempo de cambio, menos fallos, mejor recuperación o una capacidad antes bloqueada.
