Cómo modernizar APIs de sistemas legacy sin reescribir

Diagnóstico previo (semana 1)

Antes de tocar código, mapeamos qué procesos de negocio viven en el legacy, qué integraciones existen, qué SLA se espera y qué throughput real soporta el sistema. Sin este diagnóstico, cualquier API que construyas va a filtrar problemas del legacy hacia arriba.

Patrón Strangler Fig

Introducimos una capa API que enrutamos progresivamente: al principio delega todo al legacy; con el tiempo, endpoints concretos se sirven desde nuevos servicios sin que el consumidor se entere. La API es contrato, la implementación evoluciona por debajo.

• Fase 1: fachada REST/GraphQL sobre el legacy (adapters, no lógica nueva).
• Fase 2: cache y read-models para descargar el mainframe.
• Fase 3: migración por dominios (facturación, inventario, clientes).
• Fase 4: retirada del legacy o convivencia estable.

Cómo hablar con AS/400 y mainframe

Las opciones habituales: DB2 directamente para lecturas, IBM MQ o transacciones RPG/COBOL vía middleware para escrituras, y ficheros posicionados para batch. Nunca exponemos DB2 directamente al exterior: siempre pasa por la capa API con validación y rate limiting.

Seguridad y observabilidad

OAuth 2.0 / mTLS para autenticación, WAF delante, y trazabilidad end-to-end con OpenTelemetry. Cada llamada al legacy queda correlacionada con el request original: es la única forma de depurar fallos en producción sin escalar tickets al equipo del mainframe.

Errores comunes que evitamos

Traducir 1:1 las tablas del legacy en endpoints REST: el resultado es una API tan frágil como el sistema debajo. La API debe representar el dominio de negocio, no la estructura interna del ERP.