Modernización de Core Bancario con Cero Downtime
Un banco europeo de tamaño medio con más de 2M de clientes necesitaba abandonar su sistema de core bancario COBOL legacy. Plazos estrictos de cumplimiento PSD2 y un mandato de disponibilidad 24/7 significaban que el fracaso no era una opción.
70%
Reducción de Lead Time
99.99%
Uptime Durante Migración
14
Meses de Duración
Industria
Banca y Fintech
Modelo
Equipo Dedicado
Duración
14 meses
Equipo
6 ingenieros
Resultado Clave
70% más rápido en deploys
Contexto del Cliente
La Situación del Cliente
El cliente es un banco retail europeo de tamaño medio que atiende a más de dos millones de clientes en múltiples países. Su plataforma de core bancario, construida sobre sistemas mainframe COBOL a principios de los 2000, había alcanzado un punto de inflexión crítico. Los lanzamientos de nuevos productos tardaban 6-9 meses, las integraciones con partners fintech requerían costosas capas de middleware, y el equipo de ingeniería interno carecía de experiencia en cloud-native y microservicios.
Se acercaba el plazo de cumplimiento PSD2 del Banco Central Europeo, que exigía APIs de open banking, autenticación reforzada de clientes (SCA) y monitorización de transacciones en tiempo real. La arquitectura legacy del banco no podía soportar estas capacidades sin una refactorización significativa. Simultáneamente, la recertificación PCI-DSS estaba en curso, añadiendo otra capa de requisitos de auditoría y seguridad a cualquier cambio en la plataforma core.
El mandato del CTO era claro: modernizar el sistema de core bancario a una arquitectura de microservicios manteniendo la disponibilidad del servicio 24/7. No se aceptaban ventanas de downtime planificadas — cada paso de la migración debía ejecutarse con cero impacto al cliente. El equipo interno de 12 ingenieros necesitaba refuerzo externo con profunda experiencia en sistemas distribuidos, event sourcing y entornos financieros regulados.
Un intento fallido de modernización 18 meses antes con otro proveedor había erosionado la confianza ejecutiva. Las partes interesadas requerían planes detallados de mitigación de riesgos, visibilidad semanal del progreso y un marco de gobernanza que mantuviera informado al consejo sin microgestionar al equipo técnico.
Alcance y Enfoque
Qué Se Contrató a Envadel Para Hacer
Envadel fue contratado para diseñar y ejecutar una migración por fases del monolito COBOL a una arquitectura de microservicios basada en DDD ejecutándose sobre Kubernetes. El engagement siguió el modelo de Equipo Dedicado: un squad autogestionado de 6 ingenieros operando bajo el marco de gobernanza de Envadel, integrado con el entorno Jira y Confluence existente del cliente.
El enfoque fue el patrón strangler fig — reemplazando progresivamente módulos legacy con nuevos microservicios detrás de un API gateway, usando Kafka event streaming para mantener la consistencia de datos entre los sistemas antiguo y nuevo durante el período de transición. Cada módulo (cuentas, pagos, préstamos, compliance) se migró de forma independiente con despliegues canary y capacidades de rollback automatizado.
El roadmap de 14 meses se dividió en tres fases: Fundación (meses 1-4) cubriendo infraestructura, CI/CD y los dos primeros microservicios; Migración Core (meses 5-10) para los módulos bancarios críticos; y Optimización (meses 11-14) para tuning de rendimiento, certificación API PSD2 y transferencia de conocimiento al equipo interno ampliado del cliente.
Composición del Equipo
Estructura del Equipo
El squad dedicado constaba de 6 ingenieros de Envadel trabajando a tiempo completo junto al equipo de ingeniería existente de 12 personas del cliente. Se definieron límites de propiedad claros: Envadel era propietario de la nueva capa de microservicios y la ejecución de la migración, mientras que el equipo del cliente mantenía el sistema legacy y la validación de la lógica de negocio.
Tech Lead / Arquitecto (1) — 12+ años, sistemas distribuidos
Ing. Backend Sr. (2) — Java/Spring Boot, event sourcing
DevOps / Ing. Plataforma (1) — K8s, Terraform, AWS
Ing. QA Automation (1) — Contract testing, rendimiento
Ing. Backend Sr. (1) — Kafka, migración de datos
Delivery Manager (compartido) — Gobernanza, reporting
Arquitectura y Tecnología
Arquitectura y Decisiones Técnicas
La nueva arquitectura se construyó sobre Java 17 con Spring Boot 3, siguiendo principios de diseño orientado al dominio (DDD). Cada bounded context (Cuentas, Pagos, Préstamos, Compliance, Cliente) se implementó como un microservicio independiente con su propia base de datos PostgreSQL, aplicando el patrón database-per-service para eliminar el acoplamiento de datos entre servicios.
Apache Kafka sirvió como backbone de eventos, implementando event sourcing para todos los cambios de estado en los dominios de Cuentas y Pagos. Esto permitió la sincronización de datos en tiempo real entre el sistema COBOL legacy y los nuevos microservicios durante el período de transición, y proporcionó una pista de auditoría completa requerida para el cumplimiento PCI-DSS. Kafka Connect gestionó el CDC (Change Data Capture) desde la base de datos DB2 legacy.
La infraestructura se codificó completamente con Terraform en AWS. El clúster Kubernetes se ejecutó en EKS con Helm charts para despliegues estandarizados. El pipeline CI/CD (GitHub Actions) incluía escaneo SAST (SonarQube), escaneo de vulnerabilidades de contenedores (Trivy), contract tests automatizados (Pact) y orquestación de despliegues canary. Cada despliegue de microservicio se realizaba por fases: 5% canary → 25% → 50% → 100%, con rollback automático activado por umbrales de tasa de error.
Un API gateway (Kong) gestionaba el enrutamiento, rate limiting y autenticación (OAuth 2.0 / OpenID Connect) tanto para servicios internos como para las APIs de open banking mandatadas por PSD2. La observabilidad se construyó sobre Prometheus, Grafana y distributed tracing vía Jaeger, con integración PagerDuty para alerting de guardia.
Seguridad y Cumplimiento
Cumplimiento Normativo y Medidas de Seguridad
Dado el entorno financiero regulado, la seguridad se integró en cada capa. Todos los ingenieros accedían a la infraestructura del cliente a través de una VPN dedicada con tokens MFA de hardware. Los repositorios de código usaban reglas de protección de rama, code review obligatorio por al menos dos revisores (uno de cada equipo) y commits firmados. Ningún ingeniero tenía acceso a la base de datos de producción — todas las interacciones con datos se realizaban a través de APIs versionadas con logging de auditoría completo.
El cumplimiento PSD2 se validó mediante la implementación de flujos de Autenticación Reforzada de Clientes (SCA), APIs de análisis de riesgo de transacciones y la interfaz de open banking certificada contra la especificación Berlin Group NextGenPSD2. Los controles PCI-DSS se mantuvieron durante todo el proceso: segmentación de red, cifrado en reposo (AES-256) y en tránsito (TLS 1.3), gestión de secretos vía AWS Secrets Manager con rotación automática y evaluaciones trimestrales de vulnerabilidades.
El equipo de Envadel participó en dos tests de penetración externos durante el engagement, abordando todos los hallazgos dentro del SLA acordado. Se ejecutó un NDA mutuo y un DPA antes del inicio del engagement, con residencia de datos garantizada en la UE. Todos los ingenieros de Envadel completaron la formación obligatoria de concienciación en seguridad del cliente y pasaron verificaciones de antecedentes.
Proceso de Delivery
Cadencia de Sprints y Gobernanza
El equipo operó en sprints de 2 semanas con una cadencia de ceremonias bien definida: planificación de sprint los lunes, daily standups a las 09:30 CET, revisión de mitad de sprint los miércoles, revisión de sprint y retrospectiva los viernes alternos. El Product Owner del cliente participaba en todas las sesiones de planificación y revisión, asegurando la alineación con las prioridades de negocio.
El reporting seguía una cadencia estructurada: informes de estado semanales entregados cada viernes cubriendo velocidad, bloqueos, evaluación de riesgos y próximos hitos. Los resúmenes ejecutivos mensuales se presentaban al CTO y VP de Ingeniería, incluyendo gráficos burn-down, métricas de calidad (defect escape rate, cobertura de tests) y una vista del roadmap en formato RAG. Las Revisiones Trimestrales de Negocio (QBR) con stakeholders C-level cubrían alineación estratégica, seguimiento de ROI y planificación de continuidad del equipo.
Se aplicó gestión formal de cambios para cualquier modificación de alcance. Las solicitudes de cambio requerían evaluación de impacto (esfuerzo, riesgo, dependencias), aprobación tanto del delivery manager de Envadel como del Product Owner del cliente, y ajustes de alcance documentados. Este proceso evitó el scope creep mientras permitía pivotes legítimos — se procesaron 4 solicitudes de cambio en 14 meses, todas dentro del marco de gobernanza.
Resultados e Impacto
Resultados Medibles
70%
Reducción en lead time de despliegue (de 6 semanas a 1,3 semanas)
99,99%
Uptime mantenido durante los 14 meses de migración
PSD2
Cumplimiento PSD2 completo alcanzado antes del plazo regulatorio
45%
Reducción en costes de infraestructura y operaciones
12→4 hrs
Reducción del Tiempo Medio de Recuperación (MTTR)
94%
Cobertura de tests automatizados en todos los nuevos microservicios
Lecciones Aprendidas
Insights Clave de Este Engagement
El patrón strangler fig fue crítico para gestionar el riesgo en un entorno de cero downtime. Ejecutando los sistemas legacy y nuevo en paralelo con sincronización de eventos basada en Kafka, pudimos validar cada paso de migración con datos de producción antes de hacer el cutover — eliminando el riesgo de migración "big bang" que había descarrilado el intento anterior.
Los despliegues canary con rollback automático resultaron esenciales en un entorno financiero regulado. La capacidad de desplegar al 5% del tráfico y revertir automáticamente ante la detección de anomalías dio al equipo de compliance la confianza de que ninguna violación regulatoria podría persistir en producción.
Invertir en observabilidad completa desde el día uno (no como una ocurrencia tardía) aceleró drásticamente la capacidad del equipo para diagnosticar problemas en el sistema distribuido. La correlación entre eventos de despliegue y métricas del sistema fue invaluable durante las fases críticas de migración.
La gobernanza estructurada y el reporting transparente reconstruyeron la confianza ejecutiva después de un engagement previo fallido con otro proveedor. Los informes semanales y el formato QBR se convirtieron en la plantilla que el banco adoptó para todas las relaciones con proveedores posteriores.
Hablemos de un Desafío Similar
Agenda una discovery call confidencial para explorar cómo podemos entregar resultados medibles para tu organización.
Agendar Llamada