Del Monolito a Microservicios: El Patrón Strangler en Banca

El reemplazo total de un core bancario fracasa cerca de cuatro de cada cinco veces. Y aun así, sigue siendo el plan por defecto en demasiadas instituciones. Hay una forma mejor, y se la debemos a una higuera.

Empecemos por el dato incómodo. El directivo de un proveedor europeo de software bancario, Karl im Brahm de Objectway, estimó en 2025 que la tasa de éxito de las migraciones de core ronda apenas el 20% —es decir, alrededor del 80% de los proyectos fracasan—, casi siempre por datos incompletos o por la magnitud del cambio de golpe, según declaró en The Wealth Mosaic. Apagar el viejo, encender el nuevo: la apuesta de todo o nada que ya describimos como pesadilla en otro artículo. La buena noticia es que no es la única opción.

Una higuera, un patrón

En 2001, el ingeniero de software Martin Fowler viajó a las selvas de Queensland, en Australia, y observó las strangler figs —higueras estranguladoras—. Estas plantas germinan en lo alto de un árbol huésped, crecen hacia abajo rodeándolo, y poco a poco lo van envolviendo hasta volverse autosuficientes. Con el tiempo, el árbol original muere y queda solo la higuera, con la forma exacta de lo que reemplazó. Fowler vio ahí una metáfora de cómo modernizar software, y nombró el patrón: el Strangler Fig, como él mismo lo cuenta.

La idea es elegante por lo simple. En lugar de reemplazar el core de un solo golpe, construyes lo nuevo alrededor de lo viejo, pieza por pieza. Cada capacidad nueva se levanta por separado, y poco a poco vas migrando comportamiento del sistema legado al nuevo, hasta que el viejo ya no hace nada y se puede apagar sin drama. El sistema nunca deja de operar. El riesgo se reparte en el tiempo en vez de concentrarse en un fin de semana aterrador.

Cómo funciona, en concreto

El mecanismo, tal como lo documenta la arquitectura de referencia de Microsoft, gira en torno a una fachada —un proxy— que se coloca entre las aplicaciones cliente y los sistemas (el viejo y el nuevo). Esa fachada intercepta cada petición y la enruta: al legado lo que todavía vive ahí, a los servicios nuevos lo ya migrado. Conforme avanza la migración, la fachada manda cada vez más tráfico al sistema nuevo. Cuando ya no queda nada en el viejo, se decomisiona; al final, hasta la fachada desaparece.

Va en cuatro fases, repetidas por cada capacidad: construir el servicio nuevo, redirigir el tráfico hacia él, retirar la función del legado y, al cierre, limpiar.

La parte que de verdad cuesta: los datos

Aquí conviene ser honestos, porque es donde casi todos los artículos pasan de puntillas. Descomponer la lógica de la aplicación es la parte manejable. La base de datos es donde las migraciones se atascan. Un core bancario no es una app cualquiera: es el libro mayor, y tiene que cuadrar al centavo mientras lo modernizas en caliente.

La práctica documentada por Microsoft para esto combina carga inicial de datos por dominio con captura de cambios en tiempo real (CDC) para mantener sincronizados el sistema viejo y el nuevo durante la convivencia, validando la consistencia antes de cualquier cambio definitivo y dejando siempre la puerta abierta a un rollback. Nada de migrar a ciegas.

Y hay un reto técnico propio de descomponer un core en microservicios que merece nombrarse: la consistencia transaccional. Cuando una transacción cruza varios servicios, las garantías fuertes de siempre se vuelven difíciles de sostener. El patrón estándar para coordinar transacciones distribuidas —la Saga— resuelve la coordinación, pero sacrifica el aislamiento: otros procesos pueden ver datos intermedios antes de que la transacción termine, como advierte la propia documentación de Microsoft. En la mayoría de los sistemas eso es tolerable; en el movimiento de dinero y la consistencia del ledger bancario, no. Por eso la descomposición de un core no se hace con recetas genéricas de microservicios: se hace sabiendo qué partes exigen garantías de hierro y cuáles no.

Por dónde empezar (y por dónde no)

La regla práctica que funciona: empieza por las costuras de bajo riesgo y bajo acoplamiento —normalmente lo que da hacia el cliente, lo que cambia seguido y duele tener atrapado en el monolito— y deja para el final los flujos transaccionales del corazón del core. Para que lo viejo y lo nuevo convivan sin contaminarse, se interpone una capa anticorrupción que traduce entre ambos mundos y evita que la semántica del legado se filtre al diseño nuevo. Es lo que permite ir desacoplando sin heredar los vicios de veinte años.

Esta no es una apuesta de nicho. La consultora IDC proyecta que el 40% de los bancos del mundo correrá un core moderno en paralelo al legado para 2026, según cita Galileo Financial Technologies, una cifra que se espera siga subiendo en los años siguientes. La modernización progresiva dejó de ser la opción cauta para volverse la mayoritaria.

Cómo lo vemos en WAU

En WAU aplicamos el patrón Strangler a la realidad de un core bancario: identificamos la primera costura que libera valor rápido, levantamos el servicio nuevo, sincronizamos los datos con captura de cambios y rollback siempre disponible, y protegemos cada dominio con una capa anticorrupción. Y tratamos la consistencia transaccional con el cuidado que el dinero exige, no con recetas de manual. Modernizas sin apagar nada.

Si tu core ya pesa pero el reemplazo total te parece —con razón— demasiado riesgo, hablemos. Trazamos juntos cuál es tu primera costura. 👉 Agenda una conversación con nuestro equipo.

Fuentes

• The Wealth Mosaic / Objectway — Karl im Brahm: por qué el 80% de las migraciones de core fracasa (oct 2025)

• Martin Fowler — Strangler Fig Application (2024; observación original de 2001)

• Microsoft Learn — Patrón Strangler Fig: fachada, fases, CDC y rollback

• Microsoft Learn — Patrón Saga: transacciones distribuidas y pérdida de aislamiento

• Microsoft Learn — Patrón Anti-Corruption Layer (capa anticorrupción)

• Galileo Financial Technologies — 40% de los bancos correrá un sidecar core para 2026 (cita a IDC)