Modernización por partes sin congelar el negocio
Cómo reemplazar un sistema heredado por partes mientras sigue funcionando, qué parte tomar primero y las tres condiciones que hacen fallar el patrón.
Todo reemplazo de un sistema heredado empieza con la misma propuesta: congelar el viejo, construir el nuevo, migrar un fin de semana. Casi nunca sobrevive al contacto con un negocio que tiene que seguir vendiendo el lunes.
El patrón strangler-fig es la alternativa. Pones una capa de enrutamiento delante del sistema heredado, mueves una capacidad a la vez detrás de ella y dejas que el sistema viejo encoja hasta que no quede nada que valga la pena mantener. El nombre viene del higuerón que crece alrededor del árbol anfitrión y termina sosteniéndose solo.
El patrón es conocido. Lo que se discute menos es qué parte tomar primero y bajo qué condiciones falla en silencio.
La capa de enrutamiento es todo el truco
Nada funciona hasta que las peticiones puedan ir a uno u otro sistema sin que quien llama lo note. Eso significa una fachada delante de la aplicación heredada: un proxy inverso, un gateway de API o un servicio delgado que pasa a ser dueño del contrato público.
Dos propiedades importan más que la tecnología que elijas:
- El enrutamiento es por capacidad, no por usuario. Mandar un porcentaje de usuarios al sistema nuevo significa que ambos sistemas son dueños del mismo dato al mismo tiempo. Eso es un proyecto de reconciliación de datos disfrazado de migración.
- La fachada es dueña del contrato. Si los clientes todavía llaman al sistema heredado directamente para algo, no lo puedes retirar. Cada llamador directo que se te escape es una razón más para que el sistema viejo siga vivo otro año.
Qué parte tomar primero
El instinto es empezar por lo menos riesgoso. Eso suele estar mal, porque lo menos riesgoso también es lo que menos demuestra.
Clasifica las partes candidatas en cuatro ejes. La primera debe puntuar bien en los cuatro, no brillantemente en uno.
| Eje | Qué quieres primero | Por qué |
|---|---|---|
| Razón lectura/escritura | Predominio de lectura | Un camino de lectura puede correr en ambos sistemas y compararse sin corromper nada. |
| Propiedad de los datos | Dueña de sus propias tablas | La escritura compartida sobre las mismas tablas desde dos bases de código es el modo de falla que termina estos proyectos. |
| Visibilidad en el negocio | Visible, no crítica | Un logro invisible no compra margen para la segunda parte. Uno crítico hace fatal el primer fallo. |
| Frecuencia de cambio | En evolución activa | Una capacidad que nadie toca no tiene fuerza motriz. Se queda a medio migrar para siempre. |
En la práctica esto suele significar reportes, búsqueda, notificaciones o una vista de lectura de cara al cliente. Rara vez significa facturación, y casi nunca autenticación.
Correr ambos, comparar, después cambiar
Para un camino de lectura, el corte más seguro no es un corte. Es un período en el que ambos sistemas responden y solo una respuesta se entrega.
- La fachada manda la petición al sistema heredado y devuelve su respuesta.
- En paralelo, manda la misma petición al servicio nuevo y descarta la respuesta.
- Registra dónde discrepan.
- Cuando la discrepancia baja a cero, o a un conjunto de diferencias que aceptaste explícitamente, cambias qué respuesta se devuelve.
Esto cuesta una llamada duplicada por petición y compra algo que ninguna suite de pruebas da: prueba contra tráfico real de producción, incluidas las entradas que nadie documentó.
Las tres condiciones que lo hacen fallar
El patrón no falla por tecnología. Falla por tres razones, y puedes verificar las tres antes de escribir una línea de código.
Nadie es dueño de retirar el sistema viejo. Si el presupuesto de la migración se mide en funcionalidades entregadas, el último 20% del sistema heredado nunca desaparece, porque las partes que quedan son las feas. Ahora corres dos sistemas para siempre y pagas por ambos. Haz que el retiro de un componente heredado con nombre sea el criterio de finalización de cada parte, no la entrega del nuevo.
La base de datos es compartida y sigue compartida. Dos aplicaciones escribiendo las mismas tablas no es un estado intermedio, es un acoplamiento permanente sobre el que ambos lados van a construir. Si la parte no puede ser dueña de sus datos, o eliges otra parte o aceptas una capa anticorrupción como el entregable real y dejas de llamarlo migración.
El equipo que conoce el sistema heredado no participa. El comportamiento no documentado es la mayor parte de lo que hace un sistema de veinte años. Las personas que saben qué flags importan son justamente a las que el proyecto reemplaza, lo cual es un problema de gobierno antes que de ingeniería. Reserva su tiempo explícitamente, y págalo.
Qué medir
Tres números dicen si la migración avanza o solo acumula código:
- Endpoints heredados todavía alcanzables directamente, sin pasar por la fachada. Debe tender a cero. Si no, nunca se podrá retirar nada.
- Componentes heredados realmente retirados, no "migrados". Migrado significa que el nuevo existe. Retirado significa que el viejo fue borrado.
- Partes en curso, que deberían ser una o dos. Cinco partes al 70% es peor que una al 100%, porque cada parte inconclusa mantiene viva una dependencia heredada.
Si esos tres números no están en un panel que alguien lee cada mes, la migración corre sobre optimismo.
Cuándo no usarlo
El patrón se paga cuando el sistema heredado debe seguir funcionando y el reemplazo tomará más de un trimestre. Si el sistema es lo bastante pequeño para reescribirse en seis semanas, la fachada, la comparación en sombra y la operación doble son puro costo. Reescríbelo y migra.
Tampoco aplica cuando el problema es el modelo de datos y no el código. Envolver un esquema malo en un servicio nuevo produce un servicio nuevo con un esquema malo. Eso es una migración de datos con un proyecto de aplicación adjunto, y debe planificarse como tal.
Así trabajamos en proyectos de modernización, y las mismas reglas sobre propiedad y acceso a datos aparecen en nuestras prácticas de ingeniería y seguridad.