La justificación estándar para invertir en calidad de datos se basa en el riesgo operativo: el 84 % de las organizaciones experimentan interrupciones cuantificables debido a la mala calidad de los datos, y más de una cuarta parte pierde más de 5 millones de dólares anuales como consecuencia directa. La respuesta habitual es un programa de gestión de la calidad de los datos que mide la precisión, la integridad, la coherencia, la puntualidad, la validez y la unicidad con respecto a umbrales establecidos, y un panel de control con métricas que verifica si los datos que fluyen a través de los sistemas operativos cumplen con los estándares definidos.
Este marco estándar no fue diseñado para un proyecto de modernización. Migrar datos de un mainframe basado en COBOL a una plataforma nativa de la nube no es un problema continuo de calidad operativa. Es un evento de transformación con requisitos específicos previos a la migración, riesgos específicos durante la migración y necesidades específicas de validación posterior a la migración que las dimensiones estándar de calidad de datos abordan solo parcialmente. El marco de puntuación de calidad de datos apropiado para un proyecto de modernización difiere del marco apropiado para el monitoreo operativo en tres aspectos fundamentales: debe evaluar la idoneidad para la migración en lugar de la idoneidad para las operaciones actuales, debe puntuar el riesgo de migración en lugar de la tasa de error operativo, y debe generar evidencia para el proceso de validación de la migración que confirme si los datos transformados se comportan de manera equivalente a los datos de origen.
Primero el esquema, luego la puntuación.
SMART TS XL Descubre cada entrada FD, REDEFINES la jerarquía y el campo COMP-3 en todo su portafolio COBOL.
DESCUBRE MÁS…Por qué los marcos de calidad de datos estándar son insuficientes para la modernización
Las seis dimensiones del marco DAMA (Data Management Body of Knowledge): precisión, integridad, coherencia, puntualidad, validez y unicidad, miden la calidad de los datos en función de los requisitos operativos. Un registro con un 95 % de precisión, un 98 % de integridad y un 99 % de coherencia cumple con los umbrales de calidad operativa para la mayoría de los sistemas. Puede o no ser apto para la migración, y puede o no producir resultados correctos en el sistema de destino.
La insuficiencia no reside en las dimensiones en sí mismas, sino en lo que miden y lo que no abarcan para el propósito específico de un proyecto de modernización.
La idoneidad para la migración no es lo mismo que la idoneidad operativa. Un registro VSAM con un campo decimal empaquetado COMP-3 válido que funciona correctamente en COBOL puede migrar incorrectamente a una base de datos de destino si el campo de destino se define como FLOAT en lugar de DECIMAL. Este error de precisión supera las comprobaciones de calidad operativa porque los programas COBOL que leen el campo original calculan resultados correctos a partir de la representación COMP-3, pero produce errores de redondeo en el sistema de destino que utiliza aritmética de punto flotante. La puntuación de calidad operativa fue alta; la puntuación de idoneidad para la migración es baja.
Los contratos de datos implícitos del sistema de origen son invisibles para las herramientas de calidad externas. Los programas COBOL garantizan la calidad de los datos mediante código procedimental, comprobaciones de rango en sentencias IF, validación de formato en bloques EVALUATE y reglas de cálculo en sentencias COMPUTE. Estas reglas de calidad residen en el código fuente, no en los datos en sí. Las herramientas de calidad de datos externas que analizan los datos sin estudiar los programas que los generan no pueden detectar estas restricciones implícitas y, por lo tanto, no pueden determinar si el sistema de destino aplica restricciones equivalentes.
La preparación para la IA introduce una tercera dimensión que va más allá de la aptitud operativa y de migración. Gartner predice que el 60 % de los proyectos de IA que no cuenten con datos preparados para la IA serán abandonados para 2026. Los "datos preparados para la IA" no son lo mismo que los "datos limpios" según la definición operativa. Un modelo de IA desconoce que los "Ingresos" en el sistema financiero excluyen los reembolsos, pero los "Ingresos" en el CRM no; los trata como la misma métrica y se basa en la inconsistencia. Los proyectos de modernización que forman parte de una transformación de IA o analítica deben evaluar la calidad de los datos según un tercer estándar: si los datos migrados producirán resultados fiables en las cargas de trabajo analíticas y de IA posteriores.
Dimensiones de la calidad de los datos específicas de la modernización
Un marco de puntuación de la calidad de los datos para proyectos de modernización amplía las seis dimensiones estándar con cinco evaluaciones específicas para la migración:
Las seis dimensiones estándar (aplicadas al contexto de la migración)
Exactitud, el grado en que los datos representan correctamente la entidad o evento del mundo real que describen. En el contexto de la migración, la precisión debe evaluarse en función de la representación del sistema de origen y la representación del sistema de destino. Una cantidad financiera almacenada como PIC S9(11)V99 COMP-3 En COBOL, DECIMAL(13,2) representa un valor con dos decimales implícitos en formato decimal empaquetado. La misma cantidad almacenada como DECIMAL(13,2) en la base de datos de destino representa el mismo valor. La misma cantidad almacenada como FLOAT(8) representa un valor aproximadamente correcto, pero no idéntico, para valores que no pueden representarse con exactitud en coma flotante binaria.
Completitud : el grado en que se encuentran presentes todos los datos necesarios. Los programas COBOL suelen usar campos de relleno (FILLER), bytes de relleno y valores centinela (todos espacios, todos ceros, HIGH-VALUES) como equivalentes funcionales de NULL que no se traducen literalmente a la semántica NULL de SQL. Una evaluación de completitud para la migración debe identificar estos valores nulos funcionales, que están presentes físicamente pero representan la ausencia de datos significativos, y determinar cómo se asignan al manejo de valores nulos del sistema de destino.
La consistencia se refiere al grado en que los datos están libres de contradicciones entre conjuntos de datos o dentro de un mismo conjunto. Para los datos de mainframe, la consistencia entre programas es particularmente importante: una misma entidad comercial (un cliente, una cuenta, una póliza) puede estar representada en varios archivos VSAM o tablas DB2 gestionadas por diferentes programas. Cada programa tiene su propio registro del estado actual de la entidad. La evaluación de la consistencia debe determinar si estas representaciones coinciden o identificar las discrepancias que deben resolverse antes de que la migración genere un conjunto de datos de destino coherente.
La puntualidad se refiere al grado en que los datos reflejan la realidad actual dentro de un plazo aceptable. En el caso de los datos de mainframe procesados por lotes, la puntualidad viene determinada por el ciclo de procesamiento: un lote mensual genera datos actualizados hasta un mes después. El requisito de puntualidad del sistema de destino, que puede necesitar datos casi en tiempo real para cargas de trabajo analíticas que el sistema de origen nunca fue diseñado para soportar, genera una brecha de puntualidad que la migración por sí sola no puede subsanar.
Validez, el grado en que los datos se ajustan a las restricciones de formato y tipo definidas. Los nombres de condición de nivel 88 de COBOL crean restricciones de validez semántica que no son capturadas por el sistema de tipos de datos: un campo definido como PIC 9(2) Puede ser válido en el programa COBOL solo cuando contiene valores 01-12 (meses) o 01-31 (días), y la validez está garantizada por la condición de nivel 88. Las herramientas externas de calidad de datos que analizan el campo ven un campo numérico de dos dígitos; no ven la restricción semántica que invalida los valores 00, 13-99 en este contexto.
Unicidad , el grado en que las entidades de datos se representan una sola vez. La dimensión de unicidad para los datos COBOL requiere comprender que los archivos VSAM KSDS imponen la unicidad de la clave primaria a nivel de archivo, pero que la misma entidad lógica puede aparecer en varios archivos VSAM mantenidos por diferentes programas, con diferentes claves. La resolución de entidades entre archivos, que determina si el registro CUSTOMER en CUSTMSTR.VSAM y el titular de la cuenta en ACTHLD.VSAM representan a la misma persona del mundo real, es un problema de unicidad que no puede evaluarse examinando cada archivo de forma aislada.
Las cinco dimensiones específicas de la migración
Integridad estructural : grado en que la disposición física de los datos coincide con las definiciones de esquema que esperan los programas. Los datos COBOL se almacenan según las especificaciones de las cláusulas PIC; los bytes físicos en disco o en registros VSAM deben ajustarse a estas especificaciones para que los programas los interpreten correctamente. Los fallos de integridad estructural, como los registros donde un campo COMP-3 contiene patrones de bits no válidos para el formato decimal empaquetado o donde un campo numérico contiene caracteres no numéricos, suelen estar presentes en los datos heredados y son invisibles para los programas que nunca utilizan los valores no válidos. Estos fallos se convierten en errores de migración cuando las herramientas de conversión intentan leer dichos campos.
Cobertura de variantes de esquema : el grado en que la puntuación de calidad de datos considera todas las variantes REDEFINES en el esquema de origen. Como se explicó en el contexto del análisis de la estructura de archivos VSAM, un registro VSAM puede tener múltiples diseños superpuestos definidos mediante cláusulas REDEFINES. Una evaluación estándar de la calidad de datos que analiza el diseño base del registro no considera las características de calidad de las variantes REDEFINES, incluidos los valores del campo discriminador que determinan qué variante se aplica a cada registro y la validez de los valores de campo de cada variante bajo la condición apropiada.
La consistencia entre programas se refiere al grado de coherencia de los valores de los datos entre programas que mantienen representaciones superpuestas de las mismas entidades de negocio. Esta dimensión es específica de los entornos de mainframe, donde la misma entidad es gestionada por múltiples programas mediante conjuntos de datos compartidos. Una regla de negocio implementada de forma diferente en dos programas, debido a que uno se actualizó cuando la regla cambió y el otro no, genera una inconsistencia entre programas que resulta invisible para cualquier evaluación de la calidad de los datos de un solo programa.
Calidad con precisión : el grado en que los datos numéricos pueden representarse en el sistema de destino con una precisión equivalente. Esta dimensión aborda específicamente los campos COMP-3, COMP y COMP-5, comunes en los programas COBOL, que requieren una asignación de tipo de destino con precisión. Una evaluación de calidad que identifica todos los campos numéricos y determina si sus valores se encuentran dentro del rango y la precisión del tipo de campo de destino es una comprobación de calidad específica de la migración que las herramientas de perfilado estándar no realizan.
Puntuación de preparación para la migración : una evaluación compuesta que determina si cada entidad de datos está lista para migrar tal cual, requiere corrección previa a la migración o requiere transformación en el destino para lograr un comportamiento equivalente. Esta puntuación es el resultado de la combinación de las dimensiones anteriores: un registro con una puntuación alta en precisión, completitud, consistencia, validez, unicidad, integridad estructural, cobertura de variantes de esquema, consistencia entre programas y calidad con conciencia de la precisión está listo para la migración. Un registro que no cumple con alguna de estas dimensiones requiere disposición, limpieza, transformación, exclusión o aceptación delta con riesgo documentado.
Cálculo de la puntuación de calidad compuesta
La puntuación compuesta de calidad de datos para un proyecto de modernización es un promedio ponderado de las puntuaciones de las dimensiones, donde las ponderaciones reflejan la importancia relativa de cada dimensión para el contexto específico de la migración:
| Dimensión | Peso estándar | Ajuste por datos financieros | Ajuste para el objetivo analítico |
|---|---|---|---|
| Exactitud | 25% | 30% (precisión crítica) | 20% |
| Integridad | 20% | 15% | 25% (La IA necesita funcionalidades completas) |
| Consistencia | 15% | 20% (regulatorio) | 20% |
| Validez | 15% | 15% | 10% |
| Exclusividad | 10% | 10% | 15% (deduplicación para IA) |
| Oportunidad | 5% | 5% | 10% (frescura para modelos) |
| Integridad estructural | 5% | 2% | 0% (después de la conversión) |
| Cobertura de variantes de esquema | 3% | 2% | 0% |
| Coherencia entre programas | 1% | 1% | 0% |
| Calidad que tiene en cuenta la precisión | 1% | 1% | 0% |
Cada dimensión se puntúa de 0 a 100, y la puntuación compuesta es la suma ponderada. La puntuación compuesta determina la clasificación de la preparación para la migración:
| Puntuacion compuesta | Preparación para la migración | Disposición recomendada |
|---|---|---|
| 90-100 | Ready | Migrar con validación estándar |
| 75-89 | Listo con monitoreo | Migración con validación posterior a la migración mejorada |
| 60-74 | Condicional | Solucione los fallos de dimensiones específicas antes de la migración. |
| 40-59 | No está listo | Se requiere una importante labor de remediación previa a la migración. |
| A continuación 40 | Problemas críticos de calidad | No migre hasta que se complete el análisis de la causa raíz y la remediación. |
Medición práctica: El flujo de trabajo de evaluación
La evaluación de la calidad de los datos para un proyecto de modernización sigue un flujo de trabajo específico que difiere del monitoreo de la calidad operativa:
Paso 1: Descubrimiento y documentación del esquema. Antes de poder evaluar cualquier dato, es necesario conocer el esquema que lo define. Para los datos de mainframe, esto implica analizar las entradas FD, los miembros COPY y las cláusulas SELECT de cada programa COBOL que accede a cada conjunto de datos. La fase de descubrimiento del esquema produce: el inventario completo de campos con tipos de datos, longitudes y especificaciones COMP; todas las jerarquías REDEFINES y sus condiciones discriminadoras; los nombres de las condiciones de nivel 88 y sus restricciones semánticas; y las reglas de calidad de datos a nivel de programa integradas en la lógica PROCEDURE DIVISION.
Paso 2: Perfilado de datos con respecto al esquema descubierto. Perfile cada conjunto de datos con respecto al esquema descubierto en el Paso 1, no con respecto a un esquema supuesto o documentado. Perfile para: frecuencias equivalentes nulas (espacios, ceros, VALORES ALTOS en campos donde se pretenden semánticas NULL); distribuciones de rango de valores con respecto a restricciones de nivel 88; integridad estructural (patrones de bits COMP-3 válidos, representaciones COMP-5 válidas); consistencia entre campos (campos de fecha donde los valores del día exceden el máximo para el mes indicado); y consistencia entre registros (registros relacionados que deberían coincidir en atributos compartidos pero no lo hacen).
Paso 3: Evaluación de la coherencia entre programas. Para cada entidad comercial representada en varios programas o conjuntos de datos, evalúe la coherencia entre las representaciones. Esto requiere: identificar qué programas mantienen representaciones superpuestas (mediante el mapeo de dependencias); extraer los registros de cada representación de cada entidad; comparar los valores que deberían ser coherentes; y documentar las discrepancias, indicando su frecuencia y gravedad.
Paso 4: Análisis del impacto en la precisión. Para cada campo numérico binario y COMP-3, calcule las implicaciones en la precisión de la asignación del tipo de campo de destino. Específicamente: identifique cualquier valor en los datos de origen que no pueda representarse con exactitud en el tipo de campo de destino; cuantifique el error de redondeo que resultaría de la conversión de tipo; y determine si el error de redondeo es aceptable dado el caso de uso posterior (los informes regulatorios y los análisis internos tienen diferentes umbrales de tolerancia).
Paso 5: Puntuación de dimensiones y cálculo de la puntuación compuesta. Aplique las puntuaciones de las dimensiones y ponderelas según el tipo de datos y el contexto de destino de la migración. Genere la puntuación compuesta y la clasificación de preparación para la migración para cada conjunto de datos y para la cartera en su conjunto.
Paso 6: Planificación de la remediación. Para los conjuntos de datos que obtengan una puntuación inferior al umbral de preparación para la migración, elabore un plan de remediación que identifique: los elementos de datos específicos que no superaron las comprobaciones de calidad; el volumen de registros afectados; la regla de negocio o la transformación que corregiría el fallo; y la comprobación de validación que confirmará que la remediación se ha completado.
Patrones SQL para la medición de la calidad de los datos
La evaluación práctica de la calidad requiere una medición ejecutable. Los siguientes patrones SQL implementan las comprobaciones de calidad más comunes específicas para la modernización sobre los datos extraídos de sistemas heredados a un entorno de prueba:
sql
-- 1. Completeness: detect functional nulls (spaces/zeros as NULL equivalents)
SELECT
COUNT(*) AS total_records,
SUM(CASE WHEN TRIM(CUSTOMER_NAME) = ''
THEN 1 ELSE 0 END) AS functional_null_name,
SUM(CASE WHEN ACCOUNT_BALANCE = 0
AND ACCOUNT_STATUS NOT IN ('ACTIVE','CLOSED')
THEN 1 ELSE 0 END) AS suspicious_zero_balance,
ROUND(100.0 * SUM(CASE WHEN TRIM(CUSTOMER_NAME) = ''
THEN 1 ELSE 0 END)
/ COUNT(*), 2) AS functional_null_pct
FROM staging_customer_master;
-- 2. Validity: check 88-level equivalent constraints (month range)
SELECT
COUNT(*) AS total_records,
SUM(CASE WHEN TRANSACTION_MONTH NOT BETWEEN 1 AND 12
THEN 1 ELSE 0 END) AS invalid_month_count,
SUM(CASE WHEN TRANSACTION_DAY NOT BETWEEN 1 AND 31
THEN 1 ELSE 0 END) AS invalid_day_count,
SUM(CASE WHEN TRANSACTION_YEAR < 1900
OR TRANSACTION_YEAR > 2100
THEN 1 ELSE 0 END) AS invalid_year_count
FROM staging_transaction_header;
-- 3. Precision impact: identify values that lose precision in FLOAT conversion
SELECT
RECORD_KEY,
ORIGINAL_AMOUNT,
CAST(CAST(ORIGINAL_AMOUNT AS FLOAT) AS DECIMAL(13,2)) AS float_roundtrip,
ABS(ORIGINAL_AMOUNT -
CAST(CAST(ORIGINAL_AMOUNT AS FLOAT) AS DECIMAL(13,2)))
AS precision_loss
FROM staging_financial_amounts
WHERE ABS(ORIGINAL_AMOUNT -
CAST(CAST(ORIGINAL_AMOUNT AS FLOAT)
AS DECIMAL(13,2))) > 0.005
ORDER BY precision_loss DESC;
-- 4. Cross-program consistency: compare entity representations across programs
SELECT
a.CUSTOMER_ID,
a.CUSTOMER_NAME AS name_in_custmstr,
b.ACCOUNT_HOLDER_NAME AS name_in_acthld,
a.CUSTOMER_ADDRESS AS addr_in_custmstr,
b.MAILING_ADDRESS AS addr_in_acthld,
CASE WHEN a.CUSTOMER_NAME <> b.ACCOUNT_HOLDER_NAME
THEN 'NAME_MISMATCH' ELSE 'OK' END AS name_consistency,
CASE WHEN TRIM(a.CUSTOMER_ADDRESS) <> TRIM(b.MAILING_ADDRESS)
THEN 'ADDRESS_MISMATCH' ELSE 'OK' END AS addr_consistency
FROM staging_customer_master a
JOIN staging_account_holder b
ON a.CUSTOMER_ID = b.CUSTOMER_ID
WHERE a.CUSTOMER_NAME <> b.ACCOUNT_HOLDER_NAME
OR TRIM(a.CUSTOMER_ADDRESS) <> TRIM(b.MAILING_ADDRESS)
ORDER BY a.CUSTOMER_ID;
-- 5. Uniqueness: identify duplicates on logical keys
SELECT
CUSTOMER_ID,
COUNT(*) AS occurrence_count,
MIN(RECORD_TIMESTAMP) AS first_occurrence,
MAX(RECORD_TIMESTAMP) AS last_occurrence
FROM staging_customer_master
GROUP BY CUSTOMER_ID
HAVING COUNT(*) > 1
ORDER BY occurrence_count DESC;Marco de control de calidad para las oleadas de migración
Un programa de modernización generalmente migra por fases, grupos de aplicaciones y conjuntos de datos que se mueven juntos. El marco de puntuación de la calidad de los datos determina las decisiones sobre la composición de las fases:
Criterios de elegibilidad para la ola: Un conjunto de datos es elegible para una ola de migración solo cuando su puntuación de calidad compuesta supera el umbral mínimo de la ola. Para las aplicaciones de Nivel 1 (de misión crítica), el umbral mínimo es 85. Para las de Nivel 2, es 75. Esto evita que las aplicaciones de misión crítica migren con datos que no han sido calificados adecuadamente.
Control de calidad previo a la migración: Antes de que comience la migración de cualquier fase, un análisis de calidad final confirma que la puntuación de calidad de los datos no se ha degradado desde la evaluación inicial. La calidad de los datos puede deteriorarse entre la evaluación inicial y la ejecución de la migración si el sistema de origen continúa funcionando y acumulando nuevos registros que no cumplen con los estándares de calidad establecidos durante la evaluación.
Validación de equivalencia posterior a la migración: Tras la migración de cada oleada, el marco de calidad proporciona la línea base de comparación: cada puntuación dimensional calculada en los datos de origen se recalcula en los datos migrados, y la diferencia entre las puntuaciones de origen y destino constituye el informe de calidad de la migración. Una migración que haya generado un conjunto de datos de destino con menor precisión, menor completitud o menor coherencia entre programas que el de origen ha introducido una degradación de la calidad que debe investigarse antes de proceder a la siguiente oleada.
Cómo SMART TS XL Admite la puntuación de calidad de datos para la modernización.
Las dimensiones de calidad específicas de la migración, la cobertura de variantes de esquema, la consistencia entre programas, la calidad con reconocimiento de precisión y la integridad estructural dependen de un nivel de comprensión del código fuente de la aplicación que las herramientas estándar de calidad de datos no poseen. Requieren saber qué definen como válidos los programas que generan los datos, qué campos son COMP-3 y requieren una asignación de destino con reconocimiento de precisión, y qué programas mantienen representaciones superpuestas de las mismas entidades de negocio.
SMART TS XL, análisis de código estático Proporciona la capa de descubrimiento de esquemas: analiza cada entrada de FD, miembro COPY y cláusula SELECT en todo el conjunto de COBOL para generar el inventario completo del esquema, todas las definiciones de campos, todas las jerarquías REDEFINES, todas las restricciones de nivel 88 y todas las especificaciones de precisión COMP-3. Este inventario es la base que requieren las dimensiones de calidad específicas de la migración y que no se puede derivar de los datos en sí.
El mapeo de dependencias de aplicaciones permite evaluar la coherencia entre programas: al crear un mapa que indique qué programas gestionan qué datos, qué programas escriben en qué conjuntos de datos VSAM y qué conjuntos de datos contienen representaciones superpuestas de las mismas entidades de negocio, el mapa de dependencias identifica los pares y grupos que requieren una evaluación de coherencia entre programas. Sin este mapa, no se puede evaluar la coherencia entre programas, ya que el evaluador desconoce qué programas y conjuntos de datos representan las mismas entidades.
La capacidad de análisis de impacto permite que el marco de control de calidad funcione a gran escala: cuando se detecta un problema de calidad en un conjunto de datos específico, el análisis de impacto identifica todas las aplicaciones, programas y procesos de negocio que dependen de ese conjunto de datos, determinando el alcance de las consecuencias posteriores del problema de calidad y priorizando la remediación en función de la cantidad de programas dependientes afectados.
La función de búsqueda empresarial permite consultar el inventario de calidad durante todo el programa de migración: encontrar cada programa que lee un archivo VSAM específico (para definir el alcance de la evaluación de la coherencia entre programas), cada campo definido como COMP-3 (para crear el inventario de calidad con precisión) y cada nombre de condición de nivel 88 (para enumerar las restricciones de validez semántica que las herramientas externas no pueden ver). Esta función de búsqueda respalda tanto la evaluación de calidad inicial como el monitoreo continuo que garantiza que la calidad no se degrade entre la evaluación y la ejecución de la migración.
Para las organizaciones que realizan modernización heredada programas, SMART TS XLEl análisis de [nombre del autor] cierra la brecha entre los marcos de calidad de datos diseñados para el monitoreo operativo y los requisitos de calidad específicos de la migración que determinan si los proyectos de modernización producen los resultados correctos. Las dimensiones estándar de calidad de datos son necesarias. Las extensiones específicas de la migración son las que las hacen suficientes.
Conclusión: La calidad para la migración no es calidad para las operaciones.
El panorama de la calidad de datos en 2026 ofrece una amplia gama de marcos, herramientas y métricas diseñadas para la gestión operativa de datos. Las dimensiones de DAMA están bien establecidas y ampliamente implementadas. Las herramientas, como Great Expectations, Monte Carlo, Collibra y dbt, han alcanzado un nivel de madurez significativo. El enfoque estándar de definir reglas de calidad, perfilar datos y monitorizarlos según umbrales funciona correctamente para el propósito operativo para el que fue diseñado.
Los proyectos de modernización requieren algo diferente. Requieren una evaluación de calidad que valore la idoneidad para la migración, no la idoneidad operativa. Requieren comprender el código fuente que genera los datos, no solo los datos en sí. Requieren un análisis de campos numéricos que tenga en cuenta la precisión, una cobertura de variantes REDEFINES y una evaluación de la coherencia entre programas, dimensiones que los marcos de calidad operativa no abordan porque los sistemas operativos no las requieren.
Las organizaciones que obtienen resultados de migración correctos son aquellas que diseñan sus marcos de puntuación de calidad de datos específicamente para la migración, antes de extenderlos al monitoreo operativo posterior. La calidad de los datos para la migración no es un subconjunto de la gestión operativa de la calidad de los datos. Es una disciplina propia, con sus propias dimensiones, umbrales y requisitos de validación, y tratarla como tal es lo que permite que los programas de modernización cumplan con sus promesas técnicas.
