Notas técnicas
Migrar un monolito sin parar la operación
· 7 min de lectura
El error clásico es intentar reescribirlo todo de una vez. Seis meses después hay dos sistemas a medias, el equipo mantiene los dos y el negocio no ha visto ninguna mejora. Hay otra forma: mover el sistema por piezas, con la operación en marcha.
Empezar por lo que más duele
No se migra por orden alfabético ni por capas. Se pregunta al equipo qué módulo frena más: el que nadie se atreve a tocar, el que rompe cada despliegue, el que tarda semanas en aceptar un cambio pequeño. Ese sale primero. Así la primera entrega ya devuelve algo: el punto más lento del equipo deja de serlo.
Probar antes de mover
Cada pieza se cubre con pruebas automáticas contra el comportamiento actual, no contra el deseado. Primero se fija lo que el sistema hace hoy, con sus rarezas incluidas. Después se mueve la pieza y las mismas pruebas confirman que nada cambió. Los arreglos vienen después, en un cambio aparte, para saber siempre qué rompió qué.
Convivir sin dolor
Durante meses el sistema viejo y el nuevo conviven. Un proxy decide qué petición va a cada lado, módulo a módulo. Si una pieza recién movida falla, se devuelve el tráfico al monolito en minutos, sin tocar código.
La secuencia, en corto
# por cada módulo, en orden de dolor
1. fijar comportamiento actual con pruebas
2. extraer la pieza, mismas pruebas en verde
3. enrutar tráfico gradualmente (1% → 100%)
4. retirar el código viejo cuando nadie lo llameLa migración termina cuando el monolito se queda sin tráfico, no cuando alguien lo declara terminado. Y si a mitad de camino el negocio cambia de prioridades, lo migrado ya funciona solo: no hay trabajo a medias que tirar.