El instinto del equipo técnico es tentador: apagar el ESB legacy en un fin de semana, encender MuleSoft el lunes, y celebrar el corte limpio. Ese plan falla siempre — y falla por tres razones que llevan años repitiéndose en cada intento de migración big-bang que hemos visto en clientes.
Por qué las migraciones "big bang" siempre se atascan
- El inventario nunca está completo. Después de años de scripts, integraciones de emergencia y conectores hechos por gente que ya no está en la empresa, siempre aparecen procesos que nadie había documentado. En un big bang, aparecen el lunes por la mañana, cuando el negocio ya está trabajando.
- El negocio no puede pararse el tiempo que el corte necesita. Si vender, facturar, entregar o atender clientes depende de una integración, no hay ventana de mantenimiento razonable para migrar veinte de golpe. Cualquier hueco es demasiado corto o demasiado caro.
- El rollback no existe. Una vez apagado el sistema legacy, volver atrás significa reactivar infraestructura que llevaba tres meses sin actualizarse, con configuraciones perdidas y equipos que ya han pasado a otras cosas. No es un rollback: es un desastre distinto.
Cuando un plan de migración depende de que las tres cosas anteriores no ocurran, no es un plan: es una apuesta. Y las apuestas de arquitectura las paga el negocio.
El patrón strangler aplicado a integraciones
El patrón strangler fig — descrito por Martin Fowler para migraciones de aplicaciones — traduce bien a integraciones. La idea es simple: el sistema nuevo crece alrededor del viejo, lo rodea, y solo cuando lo ha absorbido completamente el viejo se apaga.
En integración eso significa cuatro cosas concretas:
- MuleSoft se instala en paralelo, sin romper nada. El legacy sigue funcionando exactamente igual el día de instalación.
- Cada nueva integración se hace directamente en MuleSoft, no en el legacy. A partir del día uno, el legacy deja de crecer.
- Las integraciones existentes migran una a una, no en bloque, priorizadas por criticidad y coste de mantenerlas en el legacy.
- Cuando la última integración se migra, el legacy se apaga sin ceremonia — porque ya no lo usa nadie y el negocio no lo nota.
Este patrón no acelera la migración: la hace posible sin apagar el negocio. La diferencia entre las dos cosas suele valer varios cientos de miles de euros al año en operativa evitada.
Una migración bien hecha termina con el apagado del sistema viejo como un evento administrativo, no como un evento operativo.
Inventariar lo que hay: guía práctica
Antes de priorizar, hay que saber qué se está migrando. La lista suele ser más larga de lo que el equipo cree. Cuatro fuentes que rara vez fallan:
- La consola del propio ESB o middleware. Todos los conectores actualmente activos. Es la fuente más limpia, pero solo cubre lo formal.
- Los cron jobs de servidores. Scripts que mueven ficheros, exports programados, cargas nocturnas. Suelen ser integraciones "informales" que nadie renombró como tal.
- Los buzones de correo compartidos y las carpetas de red. Si un proceso depende de que alguien mueva un CSV cada lunes o de que llegue un XML por correo, es una integración manual — y hay que decidir si migra a MuleSoft o desaparece.
- Los tickets recurrentes de soporte. "Se ha caído la sincronización de X" durante los últimos seis meses. Cada tema recurrente esconde una integración frágil que existe pero nadie tiene mapeada.
Con esas cuatro fuentes se llega al 90% del inventario real. El otro 10% aparece durante la migración; que aparezca durante, y no después del apagado, es exactamente el sentido de hacer strangler.
Priorizar por criticidad y coste, no por lo que "molesta"
Con el inventario en la mano, la tentación es migrar primero lo que más ruido hace. Es un error. La priorización que funciona combina dos ejes:
- Criticidad para el negocio: ¿qué se rompe si esta integración deja de funcionar? Lo que rompe facturación pesa más que lo que rompe un informe interno.
- Coste de mantener el status quo: ¿cuánto duele mantenerla en el legacy? Una integración estable que nadie toca puede quedarse dos años más; una integración que se rompe cada mes cuesta más de lo que aparenta en horas y en confianza del negocio.
El cuadrante ganador para empezar es "alto coste de status quo, baja criticidad": un fallo no rompe el negocio, pero el retorno técnico es inmediato y el equipo aprende MuleSoft sobre casos que no queman. El siguiente cuadrante es "alto coste, alta criticidad" — más lento, más disciplinado, más planificado.
Lo que es "bajo coste, alta criticidad" se migra al final: la integración que "funciona bien y todos los años vamos a tocar" puede esperar sin drama. Y lo que es "bajo coste, baja criticidad" a menudo no se migra: se apaga, porque el proyecto es una oportunidad rara de eliminar carga que nadie iba a eliminar de otra forma.
La capa transitoria: MuleSoft convive con el legado
Durante la migración, MuleSoft y el sistema legacy conviven meses. Esa convivencia no es un problema: es exactamente el punto del patrón. Tres reglas para que sea sostenible:
- Ninguna integración vive en los dos sitios a la vez. Cuando una se migra, la del legacy se apaga o se convierte en un pasivo — deja de recibir cambios, solo se mantiene si suena.
- MuleSoft es el destino, no un puente. No se hace una integración temporal en MuleSoft "hasta que". Si va a MuleSoft, va con la arquitectura final; si no, no va todavía.
- El equipo trabaja solo en MuleSoft para lo nuevo. El día uno, cualquier integración nueva de negocio se hace en MuleSoft, aunque el legacy siga vivo. Si no, el legacy sigue creciendo — y no se apaga nunca.
Cuándo puedes apagar el sistema viejo (y cómo saberlo)
La señal para apagar no es "hemos migrado todas las integraciones de la lista". La lista siempre estará incompleta. La señal es esta:
- Ninguna integración productiva pasa por el sistema legacy durante 30 días consecutivos.
- Ningún equipo de negocio pide una nueva integración en el legacy durante ese periodo.
- Los logs del legacy no muestran tráfico distinto de health checks.
Cuando esas tres condiciones se cumplen simultáneamente, el legacy se apaga y se archiva su configuración por si aparece algo que nadie recuerde. En una migración bien hecha, ese día llega sin drama — porque el sistema, en la práctica, ya no hacía nada. El anuncio de apagado se envía por correo interno, no en una nota de prensa.
¿Tienes una migración por delante y no sabes por dónde empezar? — En Eme Integrations diseñamos y ejecutamos migraciones a MuleSoft con este enfoque. Hablemos.