Strangler fig vs big bang en modernización legacy bancaria

Publicado el 27 de mayo de 2026 · Tiempo de lectura ~10 min · Por equipo Vermont Solutions

La decisión sobre cómo modernizar un core bancario o una plataforma actuarial legacy se reduce, en la práctica, a dos opciones de arquitectura: strangler fig (sustitución incremental con coexistencia controlada) o big bang (corte limpio en una ventana programada). La industria no tiene una respuesta única — depende del activo, del riesgo regulatorio y de la madurez del equipo. Este artículo recoge los criterios que aplicamos en proyectos reales de banca tier-1 y seguros europeos sujetos a DORA.

Strangler fig: definición operativa

El patrón strangler fig, formalizado por Martin Fowler en 2004 a partir de los árboles del mismo nombre, consiste en construir el sistema nuevo alrededor del legacy y trasladar funcionalidad incrementalmente, mientras el legacy sigue dando servicio. Los componentes nuevos interceptan tráfico vía una capa de proxy (façade), procesan lo que ya saben hacer y delegan en el legacy lo que queda pendiente. Al final, el legacy queda apagado sin que el negocio haya notado discontinuidad.

Características técnicas típicas en banca:

• API gateway o ESB intermedio que dirige peticiones a legacy o nuevo según ruta.
• Sincronización de datos bidireccional o eventual entre core viejo y nuevo durante la transición.
• Dual-write o CDC (Change Data Capture) para mantener consistencia.
• Despliegue por slices funcionales (cuentas → tarjetas → préstamos → ...).
• Capacidad de rollback granular por componente.

Big bang: definición operativa

El rewrite big bang sustituye el sistema completo en una ventana programada (típicamente fin de semana largo o festivo). El legacy se apaga y el nuevo entra en producción simultáneamente. Requiere paralelización exhaustiva previa (UAT, performance, regresión) y un plan de rollback robusto si algo falla en las primeras horas.

Es el patrón clásico de las migraciones de core bancario de los años 2000-2015, todavía vigente cuando el legacy no admite coexistencia técnica o cuando el coste de mantener dos sistemas en paralelo durante años es prohibitivo.

Comparativa práctica

Cuándo strangler fig

• El servicio es crítico bajo DORA y la ventana de corte aceptable es de horas, no de un fin de semana.
• El legacy admite façade (interfaces estables, APIs no caóticas).
• Existe conocimiento parcial del legacy — no se puede prometer un rewrite total exacto.
• El equipo tiene cultura DevOps madura para mantener dos pipelines productivos en paralelo.
• El negocio quiere capitalizar mejoras incrementales — no esperar 24 meses para ver valor.

Cuándo big bang

• El legacy es incompatible con coexistencia (datos cifrados con clave única, secuencias contables no fragmentables, motor transaccional sin posibilidad de proxy).
• El coste anual de mantener el legacy es prohibitivo y el negocio acepta riesgo de ventana.
• Hay una fecha forzosa regulatoria o contractual (fin de soporte del fabricante, end-of-life de hardware crítico).
• El servicio no es crítico para continuidad de pago en horario hábil (back-office reporting, batch contable nocturno).
• Existe paralelización completa pre-cutover (UAT, sombra, regresión y performance) y plan de rollback validado al detalle.

Patrón híbrido en la práctica

Los proyectos reales en banca tier-1 europea rara vez son estrictamente uno u otro. El patrón más frecuente que vemos es strangler fig para el núcleo crítico (cuentas, pagos, autenticación) combinado con big bang controlados para componentes adyacentes que pueden cortarse en ventana sin impacto al cliente final (reporting interno, ETL de regulatorio, plataformas actuariales en aseguradoras).

Esto admite que cada componente tenga su propia ventana de riesgo y que el negocio capitalice mejoras incrementales sin la guillotina del big bang único. La penalización es la complejidad de gobernanza: hay que llevar el programa con disciplina porque los slices acumulan dependencias que no aparecen en el diagrama inicial.

Tres errores recurrentes

1. Subestimar el coste de la coexistencia. En strangler fig, mantener dos sistemas con consistencia transaccional añade entre el 20 % y el 40 % al coste total. No considerarlo desde el business case produce sorpresas a los 18 meses.
2. Big bang sin sombra completa. La sombra (shadow execution) no es opcional para un core bancario — es la única forma de validar el comportamiento bajo carga real. Saltarlo por presión de calendario es la causa más frecuente de los incidentes catastróficos publicados los últimos años.
3. No definir el "definition of done". Strangler fig se eterniza cuando no hay criterio claro para apagar el legacy. El programa entra en zona gris durante años, los slices nunca terminan y el coste de coexistencia se hace permanente.

Decisión recomendada

Para core bancario y plataformas críticas bajo DORA, Vermont Solutions recomienda strangler fig por defecto, salvo que el legacy o el contexto contractual lo hagan técnicamente imposible. La continuidad operativa demostrable es difícilmente sustituible — y el supervisor cada vez la valora más.

En componentes adyacentes con criticidad media-baja, big bang controlado es una opción razonable si el equipo puede sostener paralelización completa pre-cutover.

Lecturas relacionadas

• Glosario: DORA Artículo 28
• Martin Fowler — StranglerFigApplication (artículo original)

Última actualización: 2026-05-27. Contenido editorial Vermont Solutions, citable bajo atribución.