Modernización legacy.
Tu mainframe sigue corriendo. El resto del negocio deja de notarlo.
AS/400, mainframes, Cobol, Oracle Forms, FoxPro: sistemas que funcionan, que mueven el negocio, y que también lo bloquean. Reescribirlos en una iteración casi siempre fracasa. La estrategia que sí funciona es strangler fig: rodear el legacy con APIs modernas, ir migrando funcionalidad nueva al stack moderno y descomisionar el legacy gradualmente. MuleSoft es la capa que lo hace posible.
¿Qué resuelve modernización legacy con MuleSoft?
Cada nueva iniciativa digital (app móvil, web, partner, chatbot, agente, BI moderno) suele terminar pidiendo un desarrollo al equipo del mainframe o del AS/400. El legacy se vuelve cuello de botella, los proyectos demoran y el riesgo de tocar el core crece. MuleSoft expone el legacy detrás de System APIs estables alineadas al negocio. El stack moderno crece sin tocar el core, y cada nuevo caso de uso descomisiona una parte más del legacy.
- Adapters específicos por protocolo legacy: JDBC sobre DB2/AS400, MQ Series, CICS Transaction Gateway, file-based, screen scraping con Anypoint RPA.
- Anti-corruption layer en cada System API para que el dominio moderno quede limpio del modelo legacy.
- Throttling configurable: el legacy es el cuello de botella, MuleSoft no lo satura.
- Migración progresiva — cada caso de uso nuevo bypassea más legacy.
Sistemas típicos involucrados
Las familias que conviven en un proyecto serio de modernización legacy.
Mainframe y midrange IBM
z/OS con CICS, COBOL, DB2 e IMS para banca grande, AS/400 / iSeries con DB2 y programas RPG/CL en banca media, retail y manufactura LATAM.
Stacks de los 90s
Aplicaciones Oracle Forms / Reports, FoxPro con SQL Server, Visual Basic 6, ASP clásico, monolitos Java EE de los 2000s, SAP R/3 anteriores a ECC.
Mensajería y archivos legacy
WebSphere MQ, JMS, IBM Sterling, intercambio CSV o fixed-width sobre FTP / SFTP, batch jobs nocturnos, tablas compartidas como integración.
Apps modernas que consumen
App móvil del cliente, web, partners, chatbot, BI moderno y Salesforce u otros SaaS que necesitan datos del legacy en tiempo real.
Arquitectura objetivo
El legacy queda detrás de System APIs modernas. Process y Experience APIs no saben que existe.
+----------------------------------------------------------------+
| Aplicaciones modernas y nuevas |
| (App móvil, web, partner APIs, chatbot, Salesforce, BI moderno)|
+--------------------------+-------------------------------------+
|
| REST / GraphQL / Webhooks
v
+----------------------------------------------------------------+
| Capa Experience APIs |
+--------------------------+-------------------------------------+
|
v
+----------------------------------------------------------------+
| Capa Process APIs |
+--------------------------+-------------------------------------+
|
+--------------+-----------------+
v v
+--------------------+ +-------------------------+
| System API moderna | | System API legacy |
| (microservicios | | adapter (AS/400, MQ, |
| nuevos) | | COBOL, file-based) |
+--------+-----------+ +----------+--------------+
| |
v v
+------------------+ +-------------------+
| Microservicios | | AS/400 / Mainframe|
| Java / Node | | + MQ + DB2 / CICS |
+------------------+ +-------------------+System APIs
Una System API por sistema legacy y dominio: as400-account-sapi, mainframe-policies-sapi, oracle-forms-orders-sapi. Cada una con su anti-corruption layer y su throttle configurable.
Process APIs
Donde se construye la lógica nueva, libre del peso del legacy. account-balance-pa, claims-intake-pa, mobile-onboarding-pa orquestan System APIs legacy y modernas según convenga.
Experience APIs
Una Experience API por canal: mobile-banking-eapi, web-portal-eapi, partner-eapi, chatbot-eapi. Para los canales, el legacy es invisible.
Flujo paso a paso
Consulta de saldo desde una app móvil contra un AS/400 que el cliente quiere descomisionar.
- 1 La app móvil del cliente llama GET /accounts/{id}/balance contra mobile-banking-eapi. La Experience API valida el JWT del cliente y autoriza acceso a esa cuenta.
- 2 La Experience API delega en account-balance-pa, que orquesta la consulta al legacy y el enriquecimiento moderno.
- 3 La Process API llama a as400-account-sapi. Esa System API consulta DB2 vía JDBC con statement parametrizado sobre la tabla maestra de cuentas, sin tocar la app del legacy.
- 4 El adapter recibe el resultset, lo transforma a JSON con DataWeave y aplica la anti-corruption layer: nombres del modelo legacy quedan adentro, afuera viaja un contrato limpio.
- 5 La Process API enriquece con as400-rates-sapi para la tasa del día y calcula equivalente en moneda extranjera cuando aplica. El AS/400 no sabe nada del nuevo caso de uso.
- 6 Si el legacy responde lento o el circuit breaker abre, la Process API devuelve saldo cacheado con timestamp de última actualización para no bloquear al cliente.
- 7 La Experience API filtra campos sensibles, agrega metadata y devuelve a la app. Cada nuevo canal (web, partner, chatbot) consume las mismas APIs sin pedir un nuevo desarrollo al equipo del mainframe.
- 8 Cada llamada al legacy queda registrada con throttle por adapter para mantenerlo debajo del umbral acordado con el equipo Basis o el equipo i-Series del cliente.
- 9 Durante la ventana de mantenimiento del legacy, el adapter responde 503 con Retry-After. La app muestra mensaje al usuario y reagenda; nada en el stack moderno se rompe.
- 10 Cada nuevo caso de uso resuelto por esta vía descomisiona una pieza más del legacy. La superficie del mainframe se achica progresivamente, sin big bang.
Patterns aplicados
Los patrones que sostienen un strangler fig en producción.
Strangler fig
Patrón paraguas: rodear el legacy con APIs modernas e ir desviando funcionalidad nueva hasta poder apagar componentes del legacy uno a uno.
Anti-corruption layer
Cada System API legacy traduce el modelo del mainframe al modelo del negocio. El dominio moderno queda libre del peso conceptual del legacy.
Throttling por adapter
El cuello de botella siempre es el legacy. Rate limiting local protege al mainframe o al AS/400 de saturarse cuando crecen los consumers.
Circuit breaker con fallback
Si el legacy degrada, el adapter abre el circuito y devuelve respuesta cacheada con timestamp. Mejor un saldo aproximado que una pantalla rota.
Outbox y polling
Cuando el legacy no puede emitir eventos, escribe a una tabla outbox que MuleSoft polletea o consume vía CDC. El legacy no aprende protocolos nuevos.
Quarantine para batches
Lecturas de archivos CSV o fixed-width validan, archivan y dejan en cuarentena los registros con error. Operación tiene visibilidad sin bloquear el flujo.
Cómo lo implementamos
Cinco fases coordinadas con el equipo del legacy del cliente, sin big bang.
Inventario del legacy y quick wins
Mapeo de sistemas legacy en uso, protocolos disponibles (JDBC, MQ, file, screen), licencias, ventanas de mantenimiento y dependencias críticas. Identificación de los primeros casos de uso que generan valor sin tocar el core. Entregables: assessment, lista priorizada de System APIs candidatas, plan de strangler.
Contratos modernos sobre el legacy
Diseño API-Led: una System API por sistema y dominio, contratos OAS limpios alineados al negocio, anti-corruption layer formal, modelo de eventos para descomisionado progresivo, estrategia de cache y fallback, gobernanza.
Adapters y primer caso en producción
Implementación de los adapters legacy (JDBC, MQ, file, CICS, RPA cuando es inevitable), Process APIs, Experience API del primer caso, throttle configurable, tests MUnit, runbooks coordinados con el equipo del legacy.
Hardening y go-live coordinado
Hardening, security review, load testing acordado con el equipo del legacy, configuración de monitoring, ventanas de mantenimiento honradas en config. Go-live por caso de uso, sin big bang, con hypercare y bypass disponible.
Descomisionado progresivo
Cada nuevo proyecto digital reusa las System APIs existentes en lugar de pedir desarrollo al equipo del legacy. Casos de uso enteros migran al stack moderno y se apagan piezas del legacy. Managed services y CoE acompañan.
Requisitos del proyecto
Lo que tiene que estar disponible del lado del cliente para arrancar.
Datos mínimos
Acceso técnico al legacy (usuario JDBC al AS/400, credenciales MQ, conectividad CICS o IMS Connect, SFTP a directorios de batch). Inventario de programas RPG / COBOL y de archivos en uso.
Licencias y capacidades
Anypoint Platform, conectores específicos (IBM MQ, AS400 / iSeries, IMS, CICS Transaction Gateway, FTP/SFTP, Anypoint RPA cuando hay screen scraping inevitable).
Integraciones típicas
Apps móviles y web del cliente, partners, chatbot, BI moderno, Salesforce u otros SaaS, microservicios nuevos del stack moderno que reciben el flujo desviado del legacy.
Pre-requisitos organizacionales
IT lead, equipo del legacy comprometido para acordar throttle y ventanas de mantenimiento, sponsor del negocio (digital, operaciones o tecnología), criterio claro sobre el plan de descomisionado.
KPIs operativos
Las métricas que típicamente mejoran al rodear el legacy con la capa moderna.
| KPI | Qué mide | Por qué importa |
|---|---|---|
| Legacy call P95 latency | Latencia P95 contra el mainframe o AS/400 por dominio. | Detecta degradación temprana del legacy antes de que el cliente final lo perciba. |
| Legacy error rate | Porcentaje de llamadas al legacy que terminan en error técnico no de negocio. | Métrica clave de salud del legacy y disparador para abrir circuit breaker. |
| Circuit breaker open rate | Frecuencia con la que el adapter abre el circuito al legacy y sirve fallback. | Indicador directo de la fragilidad del sistema y del impacto al negocio. |
| Bytes y calls por día contra legacy | Tráfico total que llega al mainframe o AS/400. | Insumo para licenciamiento del legacy (MIPS, sesiones) y para decidir cuándo cachear más. |
| % de features nuevas que bypassean legacy | Casos de uso resueltos puramente en el stack moderno. | Materializa el avance del strangler fig y el ROI del proyecto. |
| Consumers por System API | Cantidad de canales y aplicaciones que reusan cada System API legacy. | Cuanto más alto, mayor el ahorro acumulado vs. desarrollos puntuales en el legacy. |
Time-to-value: primer caso de uso (típicamente una consulta de cliente o un evento de negocio) en producción tras 14 a 18 semanas, con métricas observables a las 4 semanas siguientes.
Cómo se mide: dashboard sobre Anypoint Monitoring por adapter, integrado con Splunk, Datadog o Grafana cuando ya existe ese stack del lado del cliente.
Preguntas frecuentes
Porque los rewrites big bang del legacy fracasan más veces de las que tienen éxito. El conocimiento del negocio acumulado en el mainframe, las personalizaciones, las reglas no documentadas y las integraciones invisibles convierten un proyecto de 18 meses en uno de 4 años. La estrategia que sí funciona es strangler fig: rodear el legacy con APIs modernas, mover funcionalidad nueva al stack moderno y descomisionar piezas del legacy a medida que dejan de tener consumers.
Depende del tamaño y de la criticidad. Casos típicos en LATAM van de 18 a 36 meses para apagar componentes representativos del legacy, manteniendo el core de transacciones críticas más tiempo. La métrica útil no es "cuándo apagamos todo" sino "qué porcentaje de las features nuevas dejaron de pasar por el legacy". Cuando ese número crece consistentemente, el descomisionado se vuelve una decisión de negocio en lugar de un riesgo técnico.
Se mapean caso por caso. Las que siguen siendo necesarias se exponen como capacidades en la System API correspondiente, hablando el lenguaje del negocio (no el de la personalización). Las que se acumularon por workarounds históricos se documentan, se valida con el negocio si todavía aplican y muchas veces se descartan al moverlas al stack moderno. El proyecto es también una oportunidad para limpiar deuda.
Se tratan como configuración del adapter. Durante la ventana, el adapter responde 503 con Retry-After. La Experience API muestra al cliente un mensaje contextual y reagenda. Los flows que toleran espera asincrónica encolan y reintentan al cierre de la ventana. El stack moderno aprende a convivir con la cadencia operativa del legacy en lugar de pelear contra ella.
Es uno de los drivers que justifica el proyecto. A medida que las System APIs cubren los casos críticos, el conocimiento sobre cómo consume el negocio al legacy queda documentado en contratos, diagramas y runbooks. El riesgo de fuga de talento se mitiga porque cada vez menos equipos necesitan tocar el legacy directamente, y el conocimiento operativo está donde puede mantenerse.
No, al contrario: el equipo del legacy es socio clave. Conoce el sistema, las personalizaciones y las ventanas operativas. Solu trabaja con ese equipo para acordar throttle, ventanas, contratos de las System APIs y plan de descomisionado. Su rol cambia de atender pedidos puntuales de cada nuevo proyecto digital a estabilizar el core mientras la organización gana velocidad afuera.
Tu legacy, en su rincón. El resto del negocio, sin notarlo.
Hablemos de tu mainframe o AS/400 y diseñamos juntos el plan de strangler.