01
Documentar
Extraemos funcionalidades de negocio del código legacy en 4 niveles de profundidad, decididos bloque a bloque por LLMs con salida estructurada.
Migración de core operativo
El core operativo
no se reescribe.
Se re-entiende.
Descomponemos monolitos legacy con IA, generamos su especificación formal y migramos a un nuevo lenguaje con validación automática en shadow mode. Sin apagar el negocio.
En conversaciones conSanta LucíaSegur CaixaCore Aseguradoras
◆ Tres capas, un mismo pipeline
Tres capas, un mismo pipeline
De código spaghetti a un servicio validado en producción, sin fases de big-bang.
02
Especificar
Consolidamos la ontología del sistema: unificamos funciones homónimas divergentes, sinónimas duplicadas y procesados replicados en una spec formal.
03
Migrar validando
Generamos el nuevo servicio y lo ejecutamos en shadow mode contra el legacy. Un diff engine compara outputs hasta la equivalencia funcional.
◇ Ontología rota
Lo que rompe cualquier reescritura del core
Estos son los patrones que hemos identificado en aseguradoras con Informix-4GL, COBOL y ABAP heredados.
Cómo lo resolvemos →Funciones homónimas divergentes
Dos funciones llamadas calc_prima() en módulos distintos hacen cálculos diametralmente opuestos. Migrarlas como iguales corrompe datos.
Funciones sinónimas duplicadas
resolver_folio(), get_folio_data(), lookup_folio() implementan la misma regla de negocio con matices. Se consolidan en una sola.
Estructuras replicadas por capa
La misma tabla se lee desde el frontend, un batch nocturno y un cursor de reporting con validaciones inconsistentes.
Procesado idéntico en entornos distintos
Lógica de liquidación que vive a la vez en un .4gm, un stored procedure y un job de dbt. Nadie sabe cuál es la fuente de verdad.
"No se opera a corazón abierto sin bypass: el core sigue latiendo mientras construimos, en paralelo, el sistema que lo va a reemplazar."
¿Migrar el core sin apagarlo?
Te enseñamos la demo del pipeline en 30 minutos.