Contexto
Aseguradora Continental México opera su núcleo de emisión y siniestros de pólizas sobre un monolito Java (versión 8) de más de 12 años, con cerca de 2.8 millones de líneas de código en un solo repositorio. El sistema es crítico — corre 24/7 y gestiona la emisión de pólizas, cálculo de primas y gestión de siniestros — pero cada despliegue tomaba una ventana de mantenimiento nocturno y cualquier cambio pequeño requería regresión completa.
El reto
- Ciclos de despliegue de 3-4 semanas por cambio, incluso para ajustes menores.
- Un solo equipo grande, sin propiedad clara de módulos — cualquier desarrollador podía romper una funcionalidad no relacionada.
- Dependencias implícitas y acoplamiento oculto entre el módulo de emisión y el de siniestros, no documentadas.
- Java 8 al final de su ciclo de soporte extendido, con librerías con vulnerabilidades conocidas sin parche disponible.
- Alto riesgo de una migración "big bang": el sistema no podía detenerse ni degradarse durante el proceso.
La solución: modernización incremental con patrón Strangler Fig
En lugar de una reescritura completa, el equipo adoptó una estrategia de extracción gradual, apoyada en herramientas de IA para acelerar el análisis del código legado.
ENFOQUE
- Mapeo de dependencias asistido por IA: antes de tocar código, se generó un mapa de acoplamiento real del monolito (no el documentado, sino el que realmente existía en el código), identificando qué módulos podían extraerse primero con menor riesgo.
- Patrón Strangler Fig: se colocó un API Gateway frente al monolito; cada capacidad de negocio (cotización, emisión, gestión de siniestros, facturación) se extrajo una por una como microservicio en Java 21, redirigiendo tráfico gradualmente sin apagar el sistema original.
- Primero lo de bajo riesgo: se empezó por funcionalidades de cara al cliente (consulta de estatus de póliza, notificaciones) para ganar experiencia antes de tocar el núcleo transaccional de emisión.
- Generación de código asistida: para los módulos de menor complejidad de negocio, un asistente de IA generó el andamiaje base del microservicio (contratos OpenAPI, esqueleto Spring Boot, pruebas unitarias iniciales), siempre con revisión y aprobación humana antes de integrar — ningún código generado se desplegó sin validación de un desarrollador senior.
- Datos: cada microservicio adoptó su propia base de datos; sincronización con el monolito durante la transición mediante Change Data Capture (CDC), evitando escrituras duales propensas a error.
- Mensajería asíncrona: eventos vía Kafka entre servicios extraídos y el monolito remanente, para desacoplar sin romper la consistencia del negocio.
Resultados a 10 meses
| Métrica | Antes | Después |
| Frecuencia de despliegue | Cada 3-4 semanas | Varias veces por semana |
| Tiempo de ciclo (commit a producción) | ~18 días | ~2 días |
| Incidentes de producción por despliegue | Base 100% | -54% |
| Módulos extraídos como microservicios | 0 | 7 de 12 dominios |
| Cobertura de pruebas automatizadas | 22% | 68% (extraídos) |
El sistema nunca dejó de operar durante la transición; los módulos aún no extraídos siguen corriendo en el monolito, ahora aislado detrás del API Gateway, sin bloquear el avance del resto.
Factores clave de éxito
- Nunca "big bang" — el patrón Strangler Fig permitió avanzar sin ventanas de mantenimiento riesgosas ni parar el negocio.
- Empezar por lo de menor riesgo para ganar confianza antes de tocar el núcleo transaccional.
- IA como acelerador de análisis y andamiaje, no como reemplazo del criterio humano — todo el mapeo de dependencias y código generado pasó por revisión de arquitectos y desarrolladores senior.
- Contratos de API explícitos (OpenAPI) desde el primer servicio extraído, evitando recrear el acoplamiento oculto del monolito en la nueva arquitectura.
Lección para replicar
La modernización de un sistema crítico no se gana por velocidad de reescritura, sino por reducir el riesgo de cada paso — extraer, validar, desplegar, repetir — con las herramientas de IA acelerando el análisis y la generación de andamiaje, pero sin sustituir la validación humana en un sistema del que depende la operación diaria del negocio.