Integrar sin reemplazar: cómo conectar sistemas viejos que nadie quiere tocar

Casi todas las empresas medianas con las que trabajamos tienen un sistema central que nadie quiere tocar. Se instaló hace más de una década, nadie del equipo original sigue en la empresa, la documentación es un manual en PDF, y todo el negocio depende de él.

La propuesta que reciben de la mayoría de los proveedores es migrar. Es un proyecto de doce a veinticuatro meses, con riesgo alto de interrumpir la operación, y muchas veces no es necesario. Hay un camino intermedio.

Primero: averiguar por dónde sale la información

Antes de decidir la arquitectura, hacemos un inventario de las salidas que el sistema ya tiene. En orden de preferencia:

1. API documentada. Poco común en sistemas viejos, pero vale la pena preguntar al proveedor.
2. Acceso de solo lectura a la base de datos. El camino más frecuente y el más seguro. No tocamos el sistema, solo leemos.
3. Exportaciones programadas. Muchos sistemas antiguos pueden dejar un archivo en una carpeta cada noche. Es suficiente para más casos de los que uno cree.
4. Automatización de la interfaz. El último recurso. Frágil, se rompe con cada actualización visual, pero a veces es lo único que hay.

La capa intermedia

Lo que construimos casi siempre es lo mismo: un servicio propio que se sienta entre el sistema viejo y todo lo demás. Lee del sistema por el camino que esté disponible, normaliza los datos a un formato coherente, y expone una API moderna que el resto de las aplicaciones consume.

Esto tiene tres ventajas que importan más que la elegancia técnica:

• El sistema central no se modifica, así que no hay riesgo de romper la operación.
• Las aplicaciones nuevas no saben que existe un sistema viejo detrás. Hablan con una API limpia.
• El día que la empresa decida migrar de verdad, solo hay que cambiar lo que está detrás de la capa. Las aplicaciones nuevas no se enteran.

Ese tercer punto es, en la práctica, el verdadero producto. La capa intermedia convierte una migración imposible en una migración opcional, que se puede hacer por partes y cuando convenga.

Escribir de vuelta: aquí hay que ir despacio

Leer es de bajo riesgo. Escribir en un sistema del que depende la facturación no lo es.

Cuando hace falta escribir, preferimos siempre el mecanismo que el propio sistema ofrece, aunque sea incómodo: un archivo de importación, un procedimiento almacenado del proveedor, una pantalla de carga masiva. Escribir directo en tablas es tentador y peligroso, porque los sistemas viejos suelen tener lógica de negocio dentro de disparadores y procedimientos que uno no ve.

Y siempre, sin excepción: ambiente de prueba con una copia real de los datos, y un registro de todo lo que la integración escribe, con posibilidad de revertir.

Cuánto tarda

Una integración de lectura entre dos sistemas, con su capa intermedia y su monitoreo, suele tomarnos entre tres y seis semanas. Compáralo con los dieciocho meses de una migración completa y se entiende por qué casi siempre empezamos por aquí.

No siempre es la respuesta. Si el sistema central ya no recibe soporte del fabricante, o corre sobre una versión de base de datos sin parches de seguridad, migrar deja de ser opcional. Pero esa es una decisión distinta, y hay que tomarla por esa razón y no porque el sistema "se vea viejo".