Integrar sistemas legados sin reemplazarlos
«Legado» no significa malo. Significa que funciona, que lleva años acumulando reglas que nadie ha vuelto a escribir en ningún sitio, y que sustituirlo entero es un proyecto con más riesgo del que la empresa puede asumir de golpe.
Cuéntanos qué sistema necesitas modernizar →Hay una persona que sabe cómo funciona. A veces ya no trabaja aquí y se le llama cuando algo falla. El sistema no tiene entorno de pruebas, la documentación es un manual de hace ocho años, y cada cambio se prueba directamente en producción a las siete de la mañana.
Por qué una reescritura completa concentra demasiado riesgo
La propuesta de rehacerlo todo es atractiva porque promete terminar con el problema. En la práctica exige mantener dos sistemas en paralelo durante meses, redescubrir reglas de negocio que solo existen dentro del código viejo, y aguantar la presión de un proyecto largo sin entregas visibles. Una alternativa con menos riesgo es envolver el sistema antiguo, poner delante una capa que traduzca y extraer funciones de forma progresiva. Cada paso entrega valor y se diseña para poder validarse antes de retirar la función anterior, manteniendo una vía de retorno cuando sea viable. El sistema viejo se apaga cuando ya no hace nada, no en una fecha señalada en un plan.
Los flujos que hay que resolver
Cada uno con la decisión de diseño que decide si aguanta en producción.
Capa de traducción por delante
Se construye una interfaz moderna que hace de fachada. Los sistemas nuevos hablan con ella y nunca con el legado, de forma que sus rarezas —códigos numéricos, campos con doble significado, fechas en formatos propios— quedan encapsuladas en un solo sitio.
Sin esa capa, cada nueva integración aprende las rarezas del legado y las hereda. Con varias integraciones acopladas directamente al legado, sustituirlo acaba implicando tocar múltiples dependencias.
Captura de cambios en lugar de consultas periódicas
Cuando el legado no emite eventos, se detectan los cambios en su base de datos —por marca de tiempo, por tabla de auditoría o leyendo el registro de transacciones— y se publican hacia fuera como eventos.
Consultar continuamente una base de datos de producción puede añadir carga innecesaria y detectar los cambios con retraso. Y con solo marca de tiempo se pierden los borrados, que es justo lo que nadie prueba.
Sustitución por partes
Las funciones salen del legado de una en una, empezando por las que tienen menos dependencias y más dolor. La fachada decide en cada momento si una petición va al sistema nuevo o al viejo.
Empezar por el módulo central porque «es el importante» es la forma más rápida de que el proyecto se pare a mitad. Se empieza por los bordes.
Cuando no hay ninguna vía de datos
Quedan sistemas que solo se dejan usar por pantalla. Ahí caben ficheros de intercambio en una carpeta acordada, o automatización de interfaz como último recurso.
La automatización de pantalla es especialmente sensible a cambios visuales y suele ofrecer menos garantías transaccionales que una integración a nivel de datos o API. Es una solución puente con fecha de caducidad, y hay que tratarla como tal desde el primer día.
Qué recibes
- ▪ Documentación de las reglas de negocio recuperadas del sistema antiguo
- ▪ Capa de traducción con contrato de datos estable
- ▪ Publicación de cambios hacia el resto del ecosistema
- ▪ Plan de sustitución por fases, con orden justificado y puntos de retorno
- ▪ Documentación operativa y técnica que reduce la dependencia de conocimiento concentrado en personas concretas
Cómo lo construimos
Idempotencia por defecto
Toda operación se puede repetir sin duplicar nada. Es lo que permite reintentar sin miedo, y sin ello ninguna integración sobrevive al primer corte de red.
Estado observable
Cada mensaje tiene estado consultable: pendiente, enviado, confirmado, fallido. Una integración que solo se ve cuando falla ya falló antes.
Un solo dueño por dato
Para cada campo hay un sistema que manda y los demás obedecen. La sincronización bidireccional sin esa regla acaba en bucles y en datos que cambian solos.
IA donde decide, no donde calcula
Clasificar, extraer y redactar son tareas de modelo. Sumar, validar y encaminar son tareas de código. Mezclarlo al revés sale caro y es imposible de auditar.
Cómo lo abordamos
El mismo equipo que diagnostica es el que construye, sin traspasos. El método completo y el resto de capacidades están en la página de integración de sistemas.
- 01 Diagnóstico · 3–5 días
Mapeamos sistemas, flujos de datos y dependencias reales, incluidas las que no están documentadas. Salida: alcance cerrado y la lista de lo que se rompe hoy.
- 02 Diseño de la integración · 1 semana
Contratos de datos, dirección de la sincronización, política de reintentos y quién es dueño de cada campo. Se decide antes de escribir código porque es lo caro de cambiar después.
- 03 Implementación y pruebas · 2–6 semanas
Construcción con la casuística real, no con el caso feliz. Pruebas contra los sistemas de verdad y despliegue por fases.
- 04 Producción y observabilidad · continuo
Panel de estado, alarmas cuando algo lleva demasiado tiempo sin confirmar y mantenimiento de las integraciones cuando las APIs de terceros cambian.
Relacionado con sistemas legados
Lo que suele venir antes o después, con el motivo por el que lo enlazamos.
Auditoría de sistemas
El paso previo obligado: sin saber qué hace el legado, cualquier plan de sustitución es una apuesta.
Ver →APIs y webhooks
Lo que se construye por delante del legado, una vez existe la capa de traducción.
Ver →Roadmap tecnológico
Para ordenar qué sale primero del sistema antiguo y con qué criterio.
Ver →Por dónde se empieza
Las siete opciones clásicas, las tres que se usan, y cómo se recuperan las reglas que solo viven en el código viejo.
Ver →Preguntas frecuentes sobre sistemas legados
¿Cuándo conviene integrar y cuándo reemplazar? +
Integrar cuando el sistema cumple su función y el problema es que está aislado, cuando contiene reglas de negocio que nadie ha documentado, o cuando la operación no puede permitirse un corte. Reemplazar cuando el proveedor ha desaparecido y no hay quien lo mantenga, cuando la tecnología impide cumplir una obligación legal que no se puede resolver por fuera, o cuando el coste de mantenerlo ya supera al de rehacerlo. La decisión se toma después de entender dependencias, coste de mantenimiento, restricciones operativas y riesgo de cambio.
¿Se puede integrar un sistema sin API ni documentación? +
A menudo sí, pero depende de que exista alguna vía controlada para acceder a los datos o interactuar con el sistema, aunque normalmente implica más trabajo y vías menos elegantes: acceso de lectura a la base de datos, detección de cambios, ficheros de intercambio o —cuando no queda otra— automatización de pantalla. Lo que decide la viabilidad no es la edad del sistema, es si existe alguna vía controlada para leer los datos y, cuando el flujo lo requiera, escribir o ejecutar acciones. Eso se comprueba en el diagnóstico, y es la primera pregunta que hacemos.
¿Cuánto se tarda? +
La capa de traducción y la primera integración suelen estar en producción en cuatro a ocho semanas. La sustitución completa, si se decide hacerla, se mide en trimestres y por diseño no tiene una fecha única de corte: cada función que sale es una entrega en sí misma. Esa es justamente la ventaja frente a la reescritura, no un efecto secundario.
¿Y si la persona que conoce el sistema ya no está? +
Entonces la primera fase deja de ser técnica y pasa a ser arqueológica: se reconstruyen las reglas desde los datos y desde el comportamiento observado, no desde el código. Es más lento y conviene decirlo por adelantado. También es la razón por la que documentar lo que se descubre es un entregable del proyecto y no una cortesía.
Empieza por el diagnóstico
Tres a cinco días para saber qué se conecta primero, con alcance y precio cerrados antes de escribir una línea de código.
Hablar con un especialista ↗Otras integraciones