Replicar una base de datos heredada hacia un destino moderno parece un asunto resuelto, hasta el día en que la carga se rompe cada noche por un motivo distinto. Ayer fue un acento convertido en un carácter extraño. Hoy, una columna que no entró. Mañana, una fecha que la base nueva rechaza. El equipo se entera por el reclamo del usuario, reprocesa a mano y se convierte en operador de reintentos.

Ese fue el escenario en una aseguradora brasileña: replicaciones de una base Progress heredada hacia MySQL, orquestadas en Azure Data Factory, que fallaban en cada carga. Contamos aquí lo que hicimos: mapear las fallas en ocho clases, convertir el diccionario de datos entre los dos mundos con apoyo de IA, generar pipelines en lote por línea de comandos y dejar la replicación observable en lugar de heroica.

El síntoma: cada carga falla de una forma nueva

La replicación heredada es frágil por naturaleza. El origen tiene treinta años de decisiones acumuladas: campos reutilizados, tipos creados antes de que existiera un estándar, tablas sin clave primaria declarada. El destino, moderno y riguroso, rechaza lo que el origen toleraba en silencio. Entre los dos, el orquestador solo informa que la actividad falló.

El efecto práctico es conocido. La carga nocturna se rompe, alguien reprocesa por la mañana, funciona «de casualidad» y nadie registra nada. A la semana siguiente el mismo error vuelve en otra tabla y la investigación empieza de cero. Por eso la primera decisión no fue técnica sino de método: dejar de corregir y empezar a clasificar.

Por qué clasificar antes de corregir

Sin clasificación, todo incidente parece nuevo. Con ella, el patrón aparece rápido: ocho clases de error cubrían prácticamente todas las fallas registradas.

• Conectividad y timeout — el runtime de integración perdía la sesión con el driver ODBC en cargas largas.
• Tipo sin equivalente directo — decimales y lógicos que llegaban al destino con otra semántica.
• Truncamiento — columna de destino menor que el contenido real.
• Encoding — acentuación corrompida entre el sistema heredado y el charset del destino.
• Fecha inválida — fechas en cero o fuera de rango, rechazadas por el modo estricto.
• Clave duplicada — tablas sin clave primaria real, con un «identificador» repetido.
• Nulo en columna obligatoria — campo opcional en el origen que pasa a ser NOT NULL en el destino.
• Reproceso sin idempotencia — una carga interrumpida duplicaba filas al volver a ejecutarse.

Cada clase ganó una entrada en el runbook: cómo identificarla por el mensaje, qué consulta SQL la confirma, cuál es la corrección y cómo validar después. Ese documento es el entregable más barato y más subestimado del proyecto: transforma «llamar a quien entiende» en «seguir el procedimiento», el mismo principio que aplicamos en el soporte de TI.

Conversión del diccionario asistida por IA

La parte más trabajosa de la replicación no es mover filas, es traducir el diccionario. Cientos de tablas, miles de columnas, tres decisiones por columna: qué tipo en el destino, qué codificación, qué hacer con la clave y con el nulo. Hecho a mano, es una semana de planilla. Con un asistente de IA que lee el esquema exportado y devuelve el DDL del destino, es una tarde, siempre que la salida se trate como propuesta y no como verdad.

Tres frentes dominan la traducción. Tipo sin equivalente directo: decimal de precisión arbitraria, lógico, texto sin límite declarado. Encoding: el sistema heredado graba en una codificación de página única y el destino espera UTF-8; sin conversión explícita en la lectura, la cedilla y la tilde llegan como basura, y la carga termina con éxito. Clave y nulo: donde el origen no declara clave primaria, hay que decidir entre identificador natural y clave técnica.

Esta parte es desarrollo puro apoyado por IA: el asistente propone el mapeo columna por columna, justifica cada elección y genera el DDL. Nosotros revisamos, y ahí es donde aparece el valor, porque revisar mil líneas de propuesta es mucho más rápido que escribirlas.

Validar la conversión en tres capas

Una conversión sin validación es una apuesta. Usamos tres capas, en este orden.

1. Conteo — filas por tabla, origen contra destino. Detecta carga parcial y duplicación por reproceso. Es barato y debería correr en toda ventana.
2. Checksum por columna — suma de los campos numéricos y hash agregado de los textuales. Delata pérdida de precisión y corrupción de acentuación, ambas invisibles en el conteo.
3. Muestreo dirigido — en lugar de una muestra aleatoria, elegir las filas de borde: el texto más largo de la tabla, el valor con más decimales, registros con acentuación, fechas mínima y máxima, campos nulos. El error de conversión vive en los bordes.

Pipelines en lote, no clic a clic

Con el diccionario cerrado, queda el trabajo mecánico: por tabla, un dataset de origen, uno de destino y una actividad de copia. En el portal, son decenas de clics, con error humano garantizado en el medio.

Lo hicimos distinto. Una plantilla de dataset y una de pipeline, parametrizadas por tabla, columnas y script de precarga; un generador que lee el diccionario convertido y emite los JSON; y la publicación por línea de comandos, versionando todo en el repositorio. La corrección que cierra la clase de reproceso entró ahí: un TRUNCATE controlado como pre-script de la copia, que vuelve idempotente la carga completa: ejecutarla dos veces pasa a dar el mismo resultado que ejecutarla una. Seis pipelines corregidos y republicados en una sola ventana.

La ganancia es de orden de magnitud. Corregir un pipeline en el portal llevaba horas, y la corrección no se propagaba a los demás. Con plantilla, parámetro y línea de comandos, aplicar la misma corrección al conjunto entero lleva minutos, y queda registrada como cambio de código, no como memoria de quien estaba de guardia. Es la disciplina de la infraestructura como código aplicada a los datos.

Lo que queda después de la corrección

El objetivo nunca fue cero fallas, sino que la falla se vuelva un evento tratable. Al final, la replicación pasó a tener cuatro cosas que no tenía: clasificación (toda falla cae en una de las ocho clases), runbook (cada clase con diagnóstico y corrección), alerta (quien necesita saber se entera antes que el usuario) y validación automática en la ventana de carga.

Eso cambia quién puede atender. Antes, solo quien conocía el histórico resolvía. Después, cualquier persona de guardia con el runbook trata las clases rutinarias y escala únicamente lo que es realmente nuevo.

Vale marcar el límite honesto: la IA no reemplazó a nadie aquí. Leyó esquemas, propuso mapeos, generó JSON y resumió cientos de mensajes en ocho patrones. Las decisiones que salen caras —qué es clave, qué se puede redondear, qué se puede truncar— siguieron siendo de personas que responden por el dato.

Para profundizar, dos materiales de la Inove Academy preparan el terreno. La guía rápida de migración a la nube ayuda a decidir qué va tal como está y qué merece rediseño antes de convertirse en pipeline: una replicación mal diseñada es deuda que uno se lleva sin darse cuenta. Y la calculadora FinOps cubre el otro lado de la cuenta: una ventana de carga mal hecha es runtime encendido más tiempo del necesario.

El aprendizaje es simple de enunciar y difícil de practicar. La replicación confiable no viene de intentar de nuevo con más esmero, sino de reducir las fallas a un conjunto pequeño y conocido, convertir el diccionario con validación real y corregir en lote. La IA acorta cada una de esas etapas, pero quien decide qué es un dato correcto sigue siendo el equipo, y está bien que siga siendo así.