Legacy Discovery Pipeline: convertir el legacy en conocimiento reutilizable

6 de septiembre de 2026

Al modernizar un sistema, escribir el endpoint suele ser más sencillo que averiguar qué debe devolver. Una columna parece una relación, pero no tiene clave foránea. Un cero puede significar «sin asignar». Un formulario de Access muestra un nombre que no aparece en ninguna tabla. La regla que une esas piezas quizá solo la conoce quien lleva años trabajando con la aplicación.

En IXATU, la sustitución progresiva de Microsoft Access por Operations nos enfrenta a esas preguntas en cada nueva capacidad: contactos, suministros, relaciones o contratos. Azure SQL conserva los datos operativos; la aplicación moderna se construye con Python, Pydantic, FastAPI y React. Antes de traducir una fila a un concepto de negocio hay que entenderla.

La Legacy Discovery Pipeline (LDP) es la propuesta que hemos definido para conservar ese aprendizaje. El nombre es interno y agrupa prácticas conocidas: inventario de esquema, fotografías reproducibles, saneamiento, perfilado y clasificación. A fecha de septiembre de 2026 es un diseño de evolución incremental, no una plataforma completa ya desplegada.

Investigar al ritmo del producto

La modernización avanza por capacidades completas. Cuando abordamos una relación entre contactos y suministros, necesitamos entender ese fragmento del sistema y entregar una funcionalidad que lo use. Esa investigación produce además un segundo resultado: conocimiento que debería servir al siguiente desarrollo.

El problema aparece cuando ese resultado queda repartido entre conversaciones, consultas manuales y decisiones implícitas en un adapter. La siguiente persona repite las mismas preguntas, o interpreta de otra manera un campo que ya habíamos investigado.

LDP propone convertir la parte repetitiva de la exploración en un proceso reproducible. El alcance profundo lo determina la siguiente capacidad de Operations. Un inventario global barato permite detectar cambios de estructura; el análisis de valores, anomalías y relaciones se concentra en las tablas necesarias para el trabajo inmediato.

Este enfoque continúa la modernización incremental del legacy: cada entrega reduce una parte de la incertidumbre sin exigir un modelo exhaustivo de toda la base de datos antes de avanzar.

Congelar, limpiar, medir y clasificar

El recorrido previsto puede expresarse así:

Inventario del esquema
        ↓
Fotografía reproducible
        ↓
Saneamiento de datos
        ↓
Perfilado y clasificación
        ↓
Paquete de evidencia para discovery

Congelar significa registrar qué había en un momento determinado. El esquema, el alcance y la procedencia deben permitir repetir o comparar la observación. Conservar fotografías sucesivas permite detectar columnas añadidas, tipos modificados o relaciones declaradas que antes no existían.

Limpiar significa reducir la exposición de información innecesaria para investigar. Al sustituir identidades, necesitamos conservar las relaciones entre registros: de poco sirve estudiar un vínculo si cada aparición de la misma persona recibe un identificador diferente. Los secretos deben eliminarse del conjunto de investigación. La seudonimización ayuda a preservar estructura, pero no equivale por sí sola a garantizar anonimato.

Medir significa describir la población real. El catálogo dice que una columna admite nulos; el perfilado dice cuántos hay. También puede registrar cardinalidades, valores frecuentes, referencias huérfanas o distribuciones inesperadas. Esos resultados son observaciones: todavía no explican el motivo de la anomalía.

Clasificar exige separar preguntas distintas. La sensibilidad de un dato, el concepto que representa y su posible destino en una migración son tres decisiones diferentes. Que un campo sea financiero no determina si debe migrarse tal cual, transformarse o someterse a revisión manual.

Tres evidencias para una misma pregunta

Los datos no cuentan por sí solos cómo funciona una aplicación. En IXATU distinguimos tres fuentes de evidencia:

Evidencia	Qué permite observar
Datos de Azure SQL	Estructura, valores, relaciones y anomalías
Aplicación Access	Formularios, consultas, eventos y lógica VBA
Conocimiento de usuarios	Intención, excepciones y significado operativo

El trabajo de extracción de formularios y código de Access permanece en la capacidad de modernización de esa aplicación. La LDP de datos se plantea inicialmente dentro de Operations, donde surgen las preguntas del producto. Los dos conjuntos de artefactos se complementan sin mezclar sus herramientas de extracción.

Un paquete de discovery debería reunir el alcance, el esquema, los cambios respecto a la observación anterior, los perfiles, las relaciones candidatas, las anomalías y las hipótesis pendientes. Humanos y agentes podrían empezar por ese documento y reservar las consultas manuales para las incógnitas que sigan abiertas.

De una coincidencia a una regla de dominio

Pensemos en un ejemplo conceptual: una columna de suministros parece contener identificadores de contactos, aunque la base de datos no declare esa relación. El perfilado encuentra coincidencias, algunos nulos, ceros y referencias inexistentes.

Eso permite formular una hipótesis. Para confirmarla hay que observar el formulario que utiliza la columna y contrastar su significado con quien opera el sistema. Solo después podemos decidir que representa, por ejemplo, el contacto que desempeña un determinado rol en un suministro.

Valores y relaciones observadas
              +
Comportamiento de Access
              +
Explicación del usuario experto
              ↓
Hipótesis contrastada
              ↓
Traducción al dominio moderno

Aquí entra la anti-corruption layer (ACL): la capa que traduce el modelo heredado al lenguaje del dominio nuevo. LDP aporta evidencia; la ACL incorpora las conclusiones validadas. Pydantic permite expresar y validar la forma del resultado, pero la traducción también puede residir en consultas, mappings, normalizaciones y funciones.

Una coincidencia estadística no debería convertirse automáticamente en una regla. Tampoco un agente debería resolver por intuición qué significa un cero histórico. Esa decisión necesita evidencia y un tratamiento explícito de los casos dudosos.

Conservar lo aprendido en comportamiento verificable

Cuando la interpretación está validada, los tests pueden expresar algo más útil que «la petición devuelve 200». Pueden comprobar qué ocurre ante una relación ausente, un valor centinela o una referencia huérfana, según las reglas acordadas para ese campo concreto.

Así, el resultado del discovery pasa a ser conocimiento ejecutable: el adapter realiza la traducción y los tests protegen su comportamiento. La siguiente capacidad reutiliza esa interpretación en vez de crear otra ACL con conclusiones diferentes.

La misma disciplina aparece en la ingesta de datos energéticos de IXATU: antes de persistir o exponer una cifra, hay que establecer qué representa y qué evidencia permite aceptarla.

El conocimiento también cambia

Comparar esquemas detecta cambios estructurales. Hace falta además observar cambios en los datos: nuevos estados, distribuciones distintas o un aumento de referencias inválidas. Y existe una tercera variación más difícil: que los usuarios empiecen a utilizar un campo con otro significado aunque su tipo y sus valores parezcan familiares.

Por eso la evidencia de Access y el conocimiento humano siguen formando parte del proceso. Un catálogo no puede sustituir esa conversación.

El primer paso de LDP será acotado: revisar qué capacidades de inventario, saneamiento y generación de informes ya existen, reutilizar las que encajen y producir el paquete mínimo que necesite el siguiente discovery. El valor buscado es que cada nueva funcionalidad deje dos cosas detrás: una mejora visible para quien usa Operations y una explicación verificable del fragmento de legacy que acabamos de entender.