En este artículo
En resumen: un sistema legado es una aplicación antigua que sigue siendo crítica para la operación, aunque su tecnología ya no sea la actual. Integrarlo significa conectarlo con sistemas nuevos sin reescribirlo de una vez. La práctica más segura es gradual: una capa de integración estable, reemplazo por partes (el patrón strangler fig) y pruebas con escenarios reales antes de cada corte.
Un sistema legado no es necesariamente un sistema obsoleto. Puede ser la aplicación que liquida pagos, conserva expedientes, gestiona estudiantes, administra trámites o concentra datos operativos que la organización no puede detener. Por eso, una guía de integración de sistemas legados debe partir de una decisión arquitectónica: conectar capacidades sin comprometer la continuidad operativa, la seguridad ni la trazabilidad.
El riesgo habitual está en tratar la integración como un desarrollo puntual entre dos aplicaciones. En entornos institucionales y empresariales, esa aproximación suele crear dependencias difíciles de sostener, duplicar datos y convertir cada cambio en una intervención de alto riesgo. Integrar bien exige entender procesos, propietarios de información, reglas de negocio y condiciones reales de operación.
Qué debe resolver una integración de sistemas legados
El objetivo no es sustituir todos los sistemas a la vez ni exponer indiscriminadamente sus datos. Es habilitar un intercambio controlado de información y acciones entre una plataforma heredada, los canales digitales actuales y los servicios que la organización necesita incorporar.
Esto puede incluir un portal Drupal que consulta el estado de un trámite en un sistema interno, una aplicación móvil que registra solicitudes en una plataforma histórica o un agente de inteligencia artificial que recupera información autorizada para asistir a equipos de atención. En todos los casos, la integración debe respetar límites claros: qué se puede consultar, quién puede ejecutar una acción, dónde se conserva el dato maestro y cómo se audita cada operación.
Una arquitectura bien planteada reduce la dependencia de procesos manuales, evita que los equipos trabajen con versiones contradictorias de la información y permite evolucionar los canales sin alterar el núcleo transaccional. Pero no todas las integraciones requieren la misma profundidad. A veces basta con una consulta programada y validada; en otros casos, se necesita sincronización casi inmediata, gestión de eventos y recuperación ante fallos.
Empiece por el proceso, no por la API
Una API disponible no garantiza que una integración sea viable. Antes de seleccionar tecnologías, conviene documentar el proceso que se quiere mejorar: qué evento lo inicia, qué datos intervienen, qué validaciones existen, qué personas aprueban decisiones y qué ocurre cuando una transacción falla.
Por ejemplo, integrar un formulario institucional con un sistema de gestión documental no consiste solo en enviar campos. Hay que definir si el ciudadano recibe un número de radicado en tiempo real, qué sucede si el gestor documental no responde, cómo se adjuntan soportes, cuál es la retención de la información y quién puede corregir una solicitud. Estas reglas suelen estar repartidas entre áreas operativas, tecnología, atención al usuario y cumplimiento.
El levantamiento inicial debe identificar también el sistema de registro principal. Si el mismo dato puede modificarse en dos aplicaciones sin una regla de precedencia, la integración generará conflictos. Una organización necesita establecer qué sistema crea el dato, cuál lo enriquece, cuáles lo consumen y cómo se propagan los cambios.
Clasifique los datos y las acciones
No todos los datos tienen el mismo nivel de sensibilidad ni todas las acciones generan el mismo impacto. Una consulta pública de horarios requiere controles distintos a la modificación de un expediente, la emisión de un certificado o el acceso a información personal.
La clasificación permite definir autenticación, autorización, cifrado, tiempos de conservación y mecanismos de auditoría adecuados. También evita un error frecuente: entregar acceso amplio a una nueva plataforma para resolver rápidamente una necesidad concreta. Las integraciones críticas deben aplicar el principio de mínimo privilegio y utilizar credenciales gestionadas, rotadas y separadas por entorno.
Diseñe una capa de integración mantenible
Conectar directamente cada canal con cada sistema legado parece rápido al inicio. Con el tiempo, esa estructura se convierte en una red difícil de modificar: un cambio en el sistema fuente obliga a ajustar portales, aplicaciones, automatizaciones y reportes al mismo tiempo.
Una capa de integración desacopla los canales de la complejidad interna. Puede adoptar la forma de servicios de aplicación, una pasarela de APIs, colas de mensajería o conectores especializados. La elección depende del volumen, la criticidad, las capacidades disponibles y la necesidad de respuesta inmediata.
Para una consulta de información no crítica, un servicio síncrono puede ser suficiente. Para procesos con picos de demanda o tareas que no deben perderse, como la recepción de solicitudes o la actualización de estados, una cola permite procesar mensajes con reintentos y conservar evidencia de lo ocurrido. No se trata de imponer una arquitectura única, sino de elegir mecanismos coherentes con el comportamiento del proceso.
Evite trasladar la lógica heredada sin revisión
Los sistemas antiguos suelen acumular reglas que respondieron a necesidades válidas en otro momento. Algunas deben preservarse por razones legales, operativas o financieras; otras solo reflejan limitaciones técnicas que ya no existen.
La integración es una oportunidad para separar reglas de negocio vigentes de comportamientos históricos. Esta revisión debe hacerse con los responsables funcionales, no únicamente desde desarrollo. Si se copia toda la lógica sin cuestionarla, la nueva solución hereda la complejidad sin aportar una mejora real. Si se elimina sin validación, se pueden afectar controles que protegían procesos críticos.
Trate la calidad del dato como una condición de salida
Una integración no corrige por sí sola datos incompletos, duplicados o con formatos inconsistentes. De hecho, puede ampliar el problema al replicarlo en nuevos canales. Antes de sincronizar información, conviene evaluar identificadores, catálogos, campos obligatorios, reglas de formato y relaciones entre registros.
Es especialmente relevante cuando se integran varias fuentes institucionales. Un mismo ciudadano, estudiante, proveedor o trámite puede aparecer con nombres diferentes, identificadores parciales o estados incompatibles. Definir un identificador confiable y reglas de reconciliación reduce errores de atención y evita que los equipos resuelvan incidencias manualmente.
La trazabilidad debe cubrir el recorrido completo: origen del dato, momento de la sincronización, transformación aplicada, destino y resultado. En procesos sensibles, además, deben registrarse el usuario o servicio que inició la operación y la respuesta recibida. Esta evidencia es necesaria para auditoría, soporte y análisis de incidentes.
Seguridad y continuidad operativa en la guía de integración de sistemas legados
Las integraciones amplían la superficie de exposición de una organización. Un sistema que antes solo era accesible desde una red interna puede quedar conectado a servicios, portales o automatizaciones. Esto no impide la evolución, pero obliga a diseñar controles desde el inicio.
La autenticación entre sistemas debe basarse en mecanismos actuales y verificables, con secretos protegidos y permisos específicos por servicio. Los datos deben viajar cifrados y las interfaces expuestas deben limitar solicitudes, validar entradas y registrar accesos. En el sector público, estas decisiones deben alinearse además con requisitos de accesibilidad, protección de datos, seguridad digital y lineamientos institucionales aplicables.
La continuidad también requiere prever indisponibilidades. Si el sistema legado se cae, el canal digital no debería mostrar un error técnico sin contexto ni perder solicitudes que puedan conservarse para procesamiento posterior. Según el caso, la solución puede informar al usuario, almacenar una petición en espera o habilitar una ruta alternativa. Lo relevante es que el comportamiento esté definido, probado y comunicado a operación.
Pruebe escenarios reales antes de pasar a producción
Las pruebas no pueden limitarse a comprobar que dos sistemas intercambian un registro. Una integración debe validarse con casos representativos: datos completos e incompletos, registros duplicados, tiempos de respuesta altos, caídas temporales, reintentos, errores de autorización y cambios de versión.
También es necesario involucrar a los equipos que operarán el proceso. Ellos detectan excepciones que rara vez aparecen en una especificación técnica, como solicitudes que llegan fuera de horario, casos que requieren revisión humana o documentos que no cumplen formatos esperados. La aceptación funcional debe contemplar tanto el camino ideal como las situaciones que requieren intervención.
El paso a producción debe ser gradual cuando el proceso lo permita. Ejecutar una prueba controlada con un grupo de usuarios, monitorizar resultados y mantener un plan de reversión reduce la exposición. La observabilidad posterior es igual de relevante: métricas de disponibilidad, tiempo de respuesta, errores, mensajes pendientes y operaciones rechazadas ofrecen señales tempranas antes de que una incidencia afecte al servicio.
Prepare la operación para el cambio
Una integración sostenible tiene responsables definidos. Tecnología puede administrar la infraestructura, pero las áreas dueñas del proceso deben validar reglas, priorizar cambios y revisar la calidad de la información. Sin esta gobernanza, la solución queda expuesta a modificaciones informales y dependencias de personas concretas.
La documentación debe ser útil para operar: contratos de datos, flujos de excepción, responsables, acuerdos de nivel de servicio y procedimientos de recuperación. Mantener estos elementos actualizados facilita auditorías, acelera el soporte y permite que la organización evolucione sin reconstruir conocimiento en cada intervención.
Integrar sistemas legados no consiste en ocultar su existencia tras una interfaz moderna. Consiste en convertir sistemas valiosos pero aislados en parte de una arquitectura gobernable, donde cada conexión tenga propósito, controles y una responsabilidad operativa clara. Esa disciplina permite modernizar con acciones acotadas, auditables y medibles, sin poner en riesgo lo que ya sostiene a la organización.
Tres estrategias y cuándo usarlas
| Estrategia | Cuándo conviene | Riesgo principal |
|---|---|---|
| Integrar sin cambiar el legado (APIs, mensajería) | El sistema funciona y solo falta conectarlo | Acoplar los sistemas nuevos a sus limitaciones |
| Reemplazo gradual (strangler fig) | El legado debe salir, pero no puede detenerse | Convivencia larga de dos versiones de la verdad |
| Migración completa | La plataforma perdió soporte, como Drupal 7 desde enero de 2025 | Pérdida de datos o de reglas de negocio no documentadas |
Cómo lo aplica Coresis
En Legiscomex, la plataforma de comercio exterior de Legis, aportamos la lógica de desarrollo y la implementación para estabilizar la plataforma, traduciendo reglas de negocio complejas en procesos claros y consistentes. En Postdata (CRC) acompañamos el paso de Drupal 7 a Drupal 10 dentro de un ecosistema de datos existente. Cuando el legado es un Drupal sin soporte, este es nuestro proceso de migración a Drupal 11; cuando la integración incluye agentes, lo abordamos con agentes de IA con acciones acotadas.
Lecturas relacionadas
- Automatización de procesos con IA: guía práctica
- Transformación digital en Colombia: qué exige hoy
- Qué es RAG y cómo funciona en la empresa