Cómo integrar sistemas legacy con herramientas digitales modernas

Llevo años entrando en salas de servidores donde un AS/400 lleva encendido desde antes de que existiera el iPhone. Y funciona. Procesa miles de pedidos al día, calcula nóminas, factura a clientes de toda la vida. Nadie quiere tocarlo porque saben que el día que pare, para el negocio entero. Esa es la conversación real que se tiene en muchas empresas españolas, aunque casi nunca aparezca en el comité.

Lo que voy a contar parte de esa realidad. Integrar un sistema legacy con herramientas modernas no consiste en jubilarlo a la fuerza ni en envolverlo en capas de tecnología hasta hacerlo inmanejable. Consiste en decidir, con criterio técnico, qué partes siguen aportando valor y cuáles se pueden ir sustituyendo sin que el negocio se entere. Esta guía recoge cómo abordamos esos proyectos cuando el objetivo es modernizar sin romper.

Qué son los sistemas legacy y por qué siguen ahí

Un sistema legacy, en el sentido en el que lo usamos los que llevamos años en integración, es cualquier aplicación o base de datos que sigue siendo crítica para el negocio pero está construida sobre tecnología que ya nadie elegiría hoy si tuviera que empezar de cero. En el tejido empresarial español me los encuentro casi a diario:

• ERPs desarrollados a medida en los años 2000 sobre tecnologías como Visual Basic 6, Delphi o Progress OpenEdge.
• Sistemas AS/400 (IBM iSeries) que todavía gestionan la contabilidad, la facturación o la logística en fabricantes, distribuidoras y cooperativas agrarias.
• Bases de datos en Informix, Clipper o FoxPro con décadas de información comercial que nadie sabe extraer con elegancia.
• Aplicaciones de gestión de nóminas o producción desarrolladas internamente y mantenidas por una sola persona (o por nadie, lo cual es peor).

Siguen vivos porque cumplen su función. Detrás de cada uno hay reglas de negocio que se han ido afinando durante quince o veinte años, particularidades que nadie ha documentado y datos que no se pueden reproducir. Según un estudio de Micro Focus de 2023, el 70% de las organizaciones europeas sigue ejecutando procesos críticos sobre sistemas que superan los diez años de antigüedad. En España, en la industria y en el agroalimentario, la cifra es probablemente más alta.

Los riesgos reales de no integrar

Dejar el sistema legacy aislado tiene un precio. No siempre se ve en la cuenta de resultados, pero se acumula.

Islas de datos y decisiones a ciegas

Cuando el ERP no habla con el CRM, ni el CRM con la plataforma de e-commerce, cada departamento opera con su propia versión de la verdad. El comercial promete stock que ya no existe. Finanzas reconstruye los números a mano en hojas de cálculo. Dirección recibe el cuadro de mando con tres semanas de retraso, cuando ya no sirve para decidir. Una encuesta de IDC Spain (2024) cuantificó esto: el 62% de las pymes industriales españolas reconocía dedicar más de 10 horas semanales a conciliar manualmente datos entre sistemas.

Vulnerabilidades de seguridad

Los sistemas legacy suelen apoyarse en sistemas operativos sin soporte (Windows Server 2008, versiones antiguas de AIX) y en protocolos de comunicación que hoy serían inaceptables. Eso convierte cada uno de ellos en una puerta abierta. El Instituto Nacional de Ciberseguridad (INCIBE) lleva años avisando de los riesgos de mantener infraestructura sin parches actualizados, y no es retórica.

Dependencia de perfiles técnicos escasos

Encontrar hoy un programador de RPG para AS/400, o un especialista en COBOL, es un ejercicio caro y frustrante. Cuando el único técnico que entiende el sistema se jubila o cambia de empresa, la organización pasa a depender de un manual que probablemente no existe.

Coste de oportunidad

Mientras la competencia automatiza, lanza canales digitales y decide con datos en tiempo real, la empresa con sistemas aislados sigue trabajando a la velocidad de hace quince años. Ese desfase no se recupera de un trimestre para otro.

Integrar o migrar: cómo tomar la decisión correcta

Antes de mover una línea de código conviene parar y contestar a una pregunta: ¿este sistema, tal y como está, sigue aportando suficiente valor funcional como para justificar su mantenimiento, o lo que toca es sustituirlo?

Integrar tiene sentido cuando:

• El sistema legacy cubre bien las necesidades funcionales del área que lo utiliza.
• El coste de sustitución es desproporcionado respecto al beneficio esperado.
• Los datos históricos son críticos y difíciles de migrar.
• El equipo operativo domina el sistema y un cambio radical generaría resistencia improductiva.

Migrar es preferible cuando:

• El proveedor ha dejado de dar soporte y no existen alternativas de mantenimiento.
• El sistema no puede escalar para absorber el crecimiento previsto.
• Los costes de mantenimiento ya superan los de una solución moderna equivalente.
• Existen requisitos regulatorios (facturación electrónica, RGPD, reporting ESG) que el sistema no puede cumplir.

En proyectos reales la respuesta casi nunca es binaria. Se integra lo que todavía aporta y se migra lo que ya no, pieza a pieza. Lo importante es que la decisión se tome con datos sobre la mesa, no por inercia ni por el ruido del último consultor que pasó por la oficina.

Si necesitas ayuda para evaluar tu caso concreto, contacta con nuestro equipo de consultoría tecnológica y analizamos tu infraestructura sin compromiso.

Estrategias de integración: cuatro enfoques probados

No hay receta única. La estrategia depende del tipo de sistema legacy, del volumen de datos, de la criticidad del proceso y del presupuesto. Estas son las cuatro aproximaciones con las que cubrimos la mayoría de proyectos.

1. Integración mediante APIs (API-led connectivity)

Consiste en levantar una capa de APIs que exponga las funcionalidades del sistema legacy para que las herramientas modernas las consuman como si hablaran con un servicio cloud nativo. Es el enfoque más limpio y el que mejor envejece.

Cómo funciona en la práctica: se desarrolla un servicio intermedio (API REST o GraphQL) que conecta con el legacy por la vía que le sea propia (acceso directo a base de datos, ficheros planos, llamadas RPC, incluso SOAP) y traduce los datos a un formato estándar (JSON, XML). El front, el CRM o la app móvil consumen esa API sin saber que detrás hay un AS/400.

Ventajas:

• Desacoplamiento total entre el sistema legacy y las herramientas nuevas.
• Reutilización: la API se construye una vez y la consume cualquier aplicación.
• Posibilidad de aplicar políticas de seguridad, throttling y monitorización en la capa intermedia.

Limitaciones:

• Requiere desarrollo a medida de la capa API.
• Si el legacy solo expone datos por ficheros batch nocturnos, hacer tiempo real es una pelea y a veces no compensa.

Una advertencia que se me ha quedado de varios proyectos: si el legacy maneja transacciones críticas (cobros, stock reservado, asientos contables), la API no puede limitarse a leer y escribir; tiene que respetar la lógica transaccional del sistema antiguo. Saltarse esa lógica para ir más rápido es la forma más segura de descuadrar un balance.

Ejemplo real: una distribuidora de material eléctrico en Valencia tenía su catálogo de 40.000 referencias en un ERP sobre AS/400. Construimos una API REST que exponía catálogo, precios por cliente y stock en tiempo real. Hoy esa misma API alimenta su tienda online en Drupal Commerce, la app de los vendedores y los portales B2B de sus tres clientes industriales principales.

2. Middleware e iPaaS (Integration Platform as a Service)

Las plataformas de integración funcionan como un bus central que conecta múltiples sistemas, legacy y modernos, sin que ninguno tenga que conocer a los demás. Es la evolución natural del viejo ESB.

Herramientas habituales en el mercado español:

• MuleSoft Anypoint Platform — robusto, orientado a gran empresa, factura alta.
• Dell Boomi — buen equilibrio entre funcionalidad y precio.
• Workato — fuerte en orquestación de procesos de negocio y conectores SaaS.
• Make (antes Integromat) y n8n — opciones más accesibles para pymes, con conectores predefinidos y flujos visuales.
• Apache Camel / Apache NiFi — open source, para equipos con músculo técnico propio.

Ventajas:

• Conectores predefinidos para cientos de aplicaciones.
• Flujos de integración visuales que reducen el tiempo de desarrollo.
• Monitorización y gestión centralizada de todas las integraciones.

Limitaciones:

• Las licencias enterprise (MuleSoft, Boomi) pueden superar los 30.000 euros anuales.
• La dependencia del proveedor iPaaS termina siendo otro lock-in: hay que medir bien qué lógica de negocio se mete dentro de la plataforma, porque sacarla luego no es trivial.

Mi criterio práctico: un iPaaS compensa cuando hay más de cuatro o cinco sistemas que se hablan entre sí. Para dos puntos de integración, montar MuleSoft es matar moscas a cañonazos; una API a medida sale más barata y más mantenible.

3. Arquitectura de microservicios (Strangler Fig Pattern)

El patrón Strangler Fig, acuñado por Martin Fowler, sigue siendo el rey en modernización de legacy y conviene entender por qué. La idea es sustituir el sistema antiguo pieza a pieza, sin apagarlo nunca, hasta que un día se le retira la última función y se desconecta sin drama.

Cómo funciona: se coloca un proxy o gateway delante del sistema legacy. Cada vez que se desarrolla un microservicio que cubre una funcionalidad concreta (por ejemplo, la gestión de pedidos), el proxy redirige las peticiones a ese nuevo servicio en lugar de al sistema antiguo. Con el tiempo, el legacy va perdiendo responsabilidades hasta que ya no queda nada dentro que justifique mantenerlo encendido.

Ventajas:

• Riesgo controlado: cada paso es pequeño y reversible.
• No exige parada del sistema en producción.
• Permite modernizar al ritmo que el negocio puede absorber, no al que dicte una hoja Gantt.

Limitaciones:

• Hace falta una planificación cuidadosa de las dependencias entre funcionalidades.
• Durante la transición se mantienen dos sistemas en paralelo, con el coste y la complejidad de doble operación.

Por qué Strangler Fig sigue ganando a las migraciones big-bang: porque en un big-bang se elige una fecha, se apaga el viejo, se enciende el nuevo y se reza. He visto suficientes proyectos así como para haber aprendido que casi nunca sale como en la presentación. Lo que falla siempre son los casos límite —ese cliente con un descuento histórico hardcodeado en RPG, ese asiento contable que el nuevo ERP no sabe replicar— y son los que ponen la empresa en pausa el lunes por la mañana. Con Strangler avanzas, mides, y si algo se rompe en producción reviertes esa pieza concreta, no el proyecto entero.

Tema delicado: las transacciones distribuidas. Cuando una pieza vive en el legacy y otra en el microservicio nuevo, una transacción que toca a las dos deja de ser atómica. Aquí no hay magia: o aceptas consistencia eventual y diseñas compensaciones (patrón Saga, idempotencia en las operaciones, outbox para eventos), o mantienes esa transacción entera dentro del legacy hasta que esté lista para mudarse completa. Intentar replicar un commit de dos fases entre un AS/400 y un microservicio en Kubernetes es una invitación al insomnio.

4. Integración por ETL y sincronización de datos

Cuando la integración en tiempo real no es imprescindible, un proceso ETL (Extract, Transform, Load) sigue siendo la opción más sensata. Se extraen datos del legacy de forma periódica (cada hora, cada noche, cada semana), se transforman al formato que toque y se cargan en la herramienta moderna.

Herramientas habituales:

• Talend Open Studio — open source, muy utilizado en España.
• Apache Airflow — orquestación de pipelines de datos.
• Pentaho Data Integration — interfaz visual, curva de aprendizaje suave.
• SQL Server Integration Services (SSIS) — si el ecosistema ya es Microsoft.

Ventajas:

• Bajo coste y complejidad técnica.
• No exige modificar el sistema legacy, lo cual a veces es un requisito político tanto como técnico.
• Funciona muy bien para reporting, analítica y migración progresiva de datos.

Limitaciones:

• Los datos no están al minuto.
• No sirve para procesos transaccionales que exigen respuesta inmediata.

Planificación del proyecto: fases y plazos realistas

Un proyecto serio de integración de sistemas legacy sigue, casi siempre, cinco fases con esta cadencia.

Fase 1: Auditoría y diagnóstico (2-4 semanas)

Inventario completo de sistemas, bases de datos, interfaces existentes, flujos de datos y dependencias. Identificación de los procesos críticos y de los puntos de dolor reales (no los del PowerPoint, los del día a día del operario). Evaluación del estado técnico del legacy: versiones, soporte del fabricante, vulnerabilidades conocidas.

Fase 2: Diseño de la arquitectura de integración (2-3 semanas)

Selección de la estrategia (API, middleware, microservicios, ETL o combinación). Definición de los flujos de datos prioritarios. Diseño de la capa de seguridad y autenticación. Estimación de costes y cronograma detallado.

Fase 3: Desarrollo e implementación (8-16 semanas)

Desarrollo iterativo de las integraciones, empezando por las de mayor impacto y menor riesgo. Pruebas unitarias y de integración en entorno de preproducción que se parezca al de verdad, no a un Docker en el portátil del desarrollador. Validación funcional con los usuarios clave de cada departamento.

Fase 4: Puesta en producción y estabilización (2-4 semanas)

Despliegue progresivo (por departamento, por proceso o por volumen de datos). Monitorización intensiva de errores, latencias y consistencia de datos. Ajustes finos basados en el uso real, no en el simulado.

Fase 5: Mantenimiento evolutivo (continuo)

Monitorización permanente de las integraciones. Actualización de conectores cuando alguien toca los sistemas origen o destino sin avisar. Incorporación de nuevas integraciones según vaya pidiendo el negocio.

Plazo total típico: entre 4 y 7 meses para un proyecto de complejidad media, con un equipo de 2-3 personas dedicadas.

Costes orientativos en el mercado español

Los costes varían mucho según alcance, pero estas cifras sirven como referencia para presupuestar sin grandes sorpresas:

Concepto	Rango orientativo
Auditoría y diagnóstico	3.000 - 8.000 EUR
Desarrollo de APIs a medida	10.000 - 40.000 EUR
Licencia iPaaS (anual)	5.000 - 50.000 EUR
Desarrollo de microservicios (por servicio)	5.000 - 15.000 EUR
Implementación ETL	4.000 - 15.000 EUR
Mantenimiento anual	10-20% del coste inicial

Para una pyme industrial con un ERP legacy que quiere conectar con un CRM moderno y una plataforma e-commerce, el presupuesto realista se mueve entre 25.000 y 60.000 euros, incluyendo el primer año de mantenimiento.

Existen ayudas públicas que pueden bajar bastante esa cifra. El programa Kit Digital y su sucesor Kit Consulting cubren parcialmente proyectos de digitalización para pymes. Las comunidades autónomas también tienen líneas propias; en Cataluña, la línea Acció de digitalización industrial, y en País Vasco, el programa Bind 4.0, por citar dos ejemplos.

Gestión del cambio: el factor que decide el éxito o el fracaso

La tecnología explica, como mucho, el 40% del éxito de un proyecto de integración. El 60% restante son las personas. Estos son los errores que más he visto repetidos y cómo evitarlos.

No involucrar a los usuarios desde el inicio. Si el equipo de almacén descubre el nuevo sistema el día del go-live, la resistencia está garantizada. Hay que incorporar a los usuarios clave como validadores ya en la fase de diseño.

Subestimar la formación. Un PDF colgado en SharePoint no es formación. Hay que hacerla práctica, en el puesto, con datos reales. Reservar al menos un 10% del presupuesto total para formación y acompañamiento.

No nombrar un responsable interno. El proyecto necesita un interlocutor dentro de la empresa que conozca los procesos, tenga autoridad para decidir y pueda dedicar entre un 20% y un 50% de su jornada al proyecto en las fases críticas. Sin ese perfil, la integración avanza al ritmo del email más lento.

Intentar hacerlo todo a la vez. Es mejor integrar un proceso completo (por ejemplo, el flujo de pedidos desde la web hasta el ERP) y enseñar resultados antes de abrir el siguiente frente. Cada pequeña victoria construye confianza y desactiva la resistencia.

Seguridad en la integración de sistemas legacy

La seguridad se complica cuando juntas sistemas antiguos con herramientas modernas, porque se amplía la superficie de ataque y se mezclan modelos de confianza distintos.

Principios básicos que debe cumplir cualquier integración:

• Autenticación y autorización en cada punto de conexión. OAuth 2.0 o API keys con rotación periódica como mínimo.
• Cifrado en tránsito (TLS 1.2 o superior) para todas las comunicaciones entre sistemas, incluidas las internas. El “es nuestra red” ya no vale.
• Segmentación de red. El legacy no debe quedar expuesto a Internet. La capa de integración hace de barrera.
• Registro y auditoría. Toda operación de lectura o escritura entre sistemas debe quedar registrada con timestamp, usuario y sistema origen.
• Gestión de credenciales. Las contraseñas del legacy no pueden estar hardcodeadas en el código de integración. Gestores de secretos (HashiCorp Vault, AWS Secrets Manager o equivalentes) y rotación.

Cuando hay datos personales en juego, la integración se diseña conforme al RGPD desde el primer día (privacy by design). Esto significa minimizar los datos que viajan en cada flujo, control de accesos granular y capacidad de responder a ejercicios de derechos (acceso, rectificación, supresión) sin tener que parar nada.

Casos reales en empresas españolas

Fabricante de componentes metálicos (Navarra)

Sistema legacy: ERP propio en Progress OpenEdge, en producción desde 2003. Reto: conectar la producción con un nuevo MES (Manufacturing Execution System) para monitorizar en tiempo real los tiempos de ciclo y las paradas no planificadas.

Solución: API REST que lee las órdenes de fabricación del ERP y las envía al MES. Los datos de producción del MES vuelven al ERP cada 5 minutos mediante un proceso ETL ligero. Plazo: 14 semanas. Inversión: 38.000 euros.

Resultado: reducción del 22% en los tiempos de parada no planificada durante los primeros seis meses. El ERP sigue en uso para contabilidad y gestión comercial, sin tocarlo.

Cooperativa agroalimentaria (Castilla-La Mancha)

Sistema legacy: AS/400 con programas RPG que gestionan la recepción de materia prima, la trazabilidad y la facturación a socios. Reto: los datos de trazabilidad debían estar disponibles en una plataforma web para cumplir con las exigencias de la gran distribución.

Solución: middleware basado en Apache Camel que extrae datos del AS/400 vía JDBC y los publica en una API REST consumida por un portal web en Drupal. Plazo: 10 semanas. Inversión: 28.000 euros (incluida la parte web).

Resultado: la cooperativa cumple los requisitos de trazabilidad digital de sus tres principales clientes de distribución. El AS/400 sigue operando con normalidad para el día a día.

Cadena de tiendas de moda (Madrid)

Sistema legacy: TPV propietario con base de datos Informix que gestiona ventas, stock y fidelización en 12 tiendas. Reto: unificar los datos de las tiendas físicas con la tienda online para ofrecer experiencia omnicanal (consulta de stock, click & collect, historial unificado).

Solución: n8n como plataforma de integración. Flujos automatizados que sincronizan stock cada 15 minutos, trasladan pedidos online al TPV y consolidan datos de clientes en un CRM (HubSpot). Plazo: 8 semanas. Inversión: 18.000 euros.

Resultado: el 35% de los pedidos online utilizan la opción de recogida en tienda en los tres primeros meses. La tasa de devolución online cae del 28% al 19% gracias a la visibilidad de stock real.

Próximos pasos para tu empresa

Si reconoces tu situación en alguno de estos escenarios, lo que toca ahora no es elegir tecnología. Es hacer el diagnóstico: qué tienes en producción de verdad, qué procesos no pueden parar, qué integraciones son urgentes y cuáles pueden esperar. Sin ese mapa, cualquier plataforma que compres se va a usar mal.

A partir de ahí, el camino suele ser el mismo: identificar dos o tres flujos críticos, levantar una primera capa de integración con la estrategia que mejor encaje (API, iPaaS, Strangler o ETL), medir resultados y avanzar. No hace falta tirar el legacy. Hace falta dejar de tratarlo como un sistema aislado y empezar a verlo como un componente más de tu arquitectura, con sus interfaces, sus contratos y sus límites.

Solicita una consultoría inicial gratuita y diseñamos contigo un plan de integración adaptado a tu realidad tecnológica, a tu equipo y a tu presupuesto.