Modernizar sistemas heredados sin un cambio de golpe
Cada pocos años alguien propone sustituir el sistema que sostiene el negocio. El plan incluye un fin de semana de cambio, normalmente dentro de dieciocho meses. Casi ninguno de esos planes sobrevive al segundo año, y los que lo hacen suelen llegar tan tarde que el reemplazo ya está anticuado.
El problema no es la ambición. Es que un cambio de golpe te pide acertar en todo a la vez, sin ninguna señal hasta el final.
Por qué la fecha siempre se mueve
Una reescritura tiene que alcanzar la paridad funcional antes de poder sustituir nada. Hasta entonces no entrega nada, así que no hay un momento natural para corregir el rumbo ni forma de descubrir qué hace realmente el sistema antiguo bajo carga hasta que ya no hay marcha atrás.
Mientras tanto el sistema antiguo sigue cambiando, porque el negocio no ha aceptado detenerse. Cada cambio es un blanco móvil que el reemplazo también tiene que acertar.
Mover un corte cada vez
La alternativa es poner una interfaz estable delante del sistema antiguo e ir moviendo funcionalidad a través de ella pieza a pieza. El código nuevo atiende una capacidad; todo lo demás sigue yendo por el camino antiguo. Cuando ese corte está probado, se coge el siguiente.
- Cada corte es lo bastante pequeño para razonarlo y reversible por sí solo.
- El sistema antiguo y el nuevo conviven, así puedes comparar su salida con tráfico real antes de conmutar.
- El trabajo de producto continúa: no hay congelado, y el negocio nunca tiene que aceptar pararse.
- Si el programa se cancela a medias, los cortes ya movidos conservan su valor.
Qué cuesta
Mantener dos sistemas en paralelo es de verdad más trabajo que mantener uno. Hay enrutado que mantener, datos que conservar consistentes a ambos lados de la frontera y un periodo en el que los ingenieros sostienen dos modelos mentales a la vez.
Es un coste real, y es menor que el de una migración fallida. Además está repartido, lo que importa: sale de un presupuesto operativo estable en lugar de un riesgo de capital asumido en un solo fin de semana.
Por dónde empezar
No por lo más difícil. Empieza por una capacidad bien entendida, con límites claros y poco radio de impacto: el objetivo del primer corte es construir la maquinaria de migración y probar el banco de comparación, no resolver el problema interesante. Ese guárdalo para el cuarto corte, cuando mover cosas ya sea rutina.
