The standard case for data quality investment is built on operational risk: 84 percent of organizations experience measurable disruption from poor data quality, and more than a quarter lose over $5 million annually as a direct consequence. The standard response is a data quality management program that measures accuracy, completeness, consistency, timeliness, validity, and uniqueness against ongoing thresholds, a dashboard of metrics that tracks whether the data flowing through operational systems meets defined standards.
What this standard framework was not designed for is a modernization project. Moving data from a COBOL-backed mainframe to a cloud-native platform is not an ongoing operational quality problem. It is a transformation event with specific pre-migration requirements, specific migration-time risks, and specific post-migration validation needs that the standard data quality dimensions address only partially. The data quality scoring framework appropriate for a modernization project differs from the framework appropriate for operational monitoring in three fundamental ways: it must assess fitness for migration rather than fitness for current operations, it must score migration risk rather than operational error rate, and it must produce evidence for the migration validation process that confirms whether the transformed data behaves equivalently to the source data.
Schema First, Then Score
SMART TS XL discovers every FD entry, REDEFINES hierarchy, and COMP-3 field across your COBOL portfolio.
DAHA FAZLASINI ÖĞRENİN…Why Standard Data Quality Frameworks Are Insufficient for Modernization
The six dimensions of the DAMA (Data Management Body of Knowledge) framework, accuracy, completeness, consistency, timeliness, validity, and uniqueness, measure data quality against operational requirements. A record that is 95 percent accurate, 98 percent complete, and 99 percent consistent meets operational quality thresholds for most systems. It may or may not be fit for migration, and it may or may not produce correct results in the target system.
The insufficiency is not in the dimensions themselves but in what they measure and what they miss for the specific purpose of a modernization project.
Migration fitness is not the same as operational fitness. A VSAM record with a valid COMP-3 packed decimal field that functions correctly in COBOL may migrate incorrectly to a target database if the target field is defined as FLOAT rather than DECIMAL, a precision error that passes operational quality checks because the COBOL programs that read the original field compute correct results from COMP-3 representation, but produces rounding errors in the target system that uses floating-point arithmetic. The operational quality score was high; the migration fitness score is low.
The source system’s implicit data contracts are invisible to external quality tools. COBOL programs enforce data quality through procedural code, range checks in IF statements, format validation in EVALUATE blocks, calculation rules in COMPUTE statements. These quality rules exist in the source code, not in the data itself. External data quality tools that profile the data without analyzing the programs that produce it cannot see these implicit constraints, and therefore cannot determine whether the target system enforces equivalent constraints.
AI readiness introduces a third dimension beyond operational and migration fitness. Gartner predicts that 60 percent of AI projects unsupported by AI-ready data will be abandoned through 2026. “AI-ready data” is not the same as “clean data” by the operational definition. An AI model does not know that “Revenue” in the finance system excludes refunds but “Revenue” in the CRM does not, it treats both as the same metric and builds on the inconsistency. Modernization projects that are part of an AI or analytics transformation must score data quality against a third standard: whether the migrated data will produce reliable results in downstream AI and analytical workloads.
The Modernization-Specific Data Quality Dimensions
A data quality scoring framework for modernization projects extends the standard six dimensions with five migration-specific assessments:
The Standard Six Dimensions (Applied to Migration Context)
doğruluk, the degree to which data correctly represents the real-world entity or event it describes. In the migration context, accuracy must be assessed against both the source system’s representation and the target system’s representation. A financial amount stored as PIC S9(11)V99 COMP-3 in COBOL represents a value with two implied decimal places in packed decimal format. The same amount stored as DECIMAL(13,2) in the target database represents the same value. The same amount stored as FLOAT(8) represents a value that is approximately correct, but not identical, for values that cannot be represented exactly in binary floating-point.
tamlık, the degree to which all required data is present. COBOL programs frequently use FILLER fields, padding bytes, and sentinel values (all spaces, all zeros, HIGH-VALUES) as functional equivalents to NULL that do not translate literally to SQL NULL semantics. A completeness assessment for migration must identify these functional nulls, values that are physically present but represent the absence of meaningful data, and determine how they map to the target system’s null handling.
Tutarlılık, the degree to which data is free of contradictions across datasets or within a dataset. For mainframe data, consistency across programs is particularly significant: the same business entity (a customer, an account, a policy) may be represented in multiple VSAM files or DB2 tables maintained by different programs. Each program has its own record of the entity’s current state. Consistency scoring must assess whether these representations agree, or identify the discrepancies that must be resolved before migration produces a coherent target dataset.
güncellik, the degree to which data reflects current reality within an acceptable time window. For batch-processed mainframe data, timeliness is determined by the batch cycle: a monthly batch creates data that is current to within one month. The timeliness requirement of the target system, which may need near-real-time data for analytics workloads that the source system was never designed to support, establishes a timeliness gap that migration alone cannot close.
Geçerlilik, the degree to which data conforms to defined format and type constraints. COBOL’s 88-level condition names create semantic validity constraints that are not captured by the data type system: a field defined as PIC 9(2) may be valid in the COBOL program only when it contains values 01-12 (months) or 01-31 (days), with validity enforced by the 88-level condition. External data quality tools that profile the field see a two-digit numeric field; they do not see the semantic constraint that makes values 00, 13-99 invalid in context.
Benzersizlik, the degree to which data entities are represented once and only once. The uniqueness dimension for COBOL data requires understanding that VSAM KSDS files enforce prime key uniqueness at the file level, but that the same logical entity may appear in multiple VSAM files maintained by different programs, with different keys. Cross-file entity resolution, determining whether the CUSTOMER-RECORD in CUSTMSTR.VSAM and the ACCOUNT-HOLDER in ACTHLD.VSAM represent the same real-world person, is a uniqueness problem that cannot be assessed by examining either file in isolation.
The Five Migration-Specific Dimensions
Yapısal bütünlük, the degree to which the data’s physical layout matches the schema definitions that programs expect. COBOL data is stored according to PIC clause specifications; the physical bytes on disk or in VSAM records must conform to these specifications for programs to interpret them correctly. Structural integrity failures, records where a COMP-3 field contains bit patterns that are invalid for packed decimal, or where a numeric field contains non-numeric characters, are often present in legacy data and invisible to the programs that happen never to exercise the invalid values. They become migration failures when conversion tools attempt to read these fields.
Schema variant coverage, the degree to which the data quality scoring accounts for all REDEFINES variants in the source schema. As discussed in the context of VSAM file structure analysis, a VSAM record may have multiple overlapping layouts defined through REDEFINES clauses. A standard data quality assessment that profiles the base record layout misses the quality characteristics of the REDEFINES variants, including the values in the discriminator field that determine which variant applies to each record, and the validity of each variant’s field values under the appropriate condition.
Cross-program consistency, the degree to which data values are consistent across programs that maintain overlapping representations of the same business entities. This dimension is specific to mainframe environments where the same entity is maintained by multiple programs through shared datasets. A business rule that is implemented differently across two programs, because one was updated when the rule changed and the other was not, produces cross-program inconsistency that is invisible to any single-program data quality assessment.
Precision-aware quality, the degree to which numeric data can be represented in the target system with equivalent precision. This dimension specifically addresses the COMP-3, COMP, and COMP-5 fields that are common in COBOL programs and that require precision-aware target type mapping. A quality assessment that identifies all numeric fields and evaluates whether their values fall within the range and precision of the target field type is a migration-specific quality check that standard profiling tools do not perform.
Migration readiness score, a composite assessment of whether each data entity is ready to migrate as-is, requires pre-migration remediation, or requires target-side transformation to achieve equivalent behavior. The migration readiness score is the output of the preceding dimensions combined: a record that scores high on accuracy, completeness, consistency, validity, uniqueness, structural integrity, schema variant coverage, cross-program consistency, and precision-aware quality is migration-ready. A record that fails any of these dimensions requires disposition, clean, transform, exclude, or accept the delta with documented risk.
Calculating the Composite Quality Score
The composite data quality score for a modernization project is a weighted average of the dimension scores, where the weights reflect the relative importance of each dimension to the specific migration context:
| Boyut | Standart Ağırlık | Adjustment for Financial Data | Adjustment for Analytics Target |
|---|---|---|---|
| doğruluk | 25% | 30% (precision critical) | 20% |
| tamlık | 20% | 15% | 25% (AI needs complete features) |
| Tutarlılık | 15% | 20% (regulatory) | 20% |
| Geçerlilik | 15% | 15% | 10% |
| Benzersizlik | 10% | 10% | 15% (deduplication for AI) |
| güncellik | 5% | 5% | 10% (freshness for models) |
| Yapısal bütünlük | 5% | 2% | 0% (post-conversion) |
| Schema variant coverage | 3% | 2% | 0% |
| Cross-program consistency | 1% | 1% | 0% |
| Precision-aware quality | 1% | 1% | 0% |
Each dimension is scored 0-100, and the composite score is the weighted sum. The composite score drives the migration readiness classification:
| Karma Not | Göç Hazırlığı | Recommended Disposition |
|---|---|---|
| 90-100 | Hazır | Migrate with standard validation |
| 75-89 | Ready with monitoring | Migrate with enhanced post-migration validation |
| 60-74 | Şartlı | Remediate specific dimension failures before migration |
| 40-59 | Hazır değil | Significant pre-migration remediation required |
| 40 altında | Critical quality issues | Do not migrate until root cause analysis and remediation complete |
Practical Measurement: The Assessment Workflow
A data quality scoring assessment for a modernization project follows a specific workflow that differs from operational quality monitoring:
Step 1: Schema discovery and documentation. Before any data can be scored, the schema that defines it must be known. For mainframe data, this means parsing FD entries, COPY members, and SELECT clauses from every COBOL program that accesses each dataset. The schema discovery phase produces: the complete field inventory with data types, lengths, and COMP specifications; all REDEFINES hierarchies and their discriminator conditions; the 88-level condition names and their semantic constraints; and the program-level data quality rules embedded in PROCEDURE DIVISION logic.
Step 2: Data profiling against the discovered schema. Profile each dataset against the schema discovered in Step 1, not against an assumed or documented schema. Profile for: null equivalent frequencies (spaces, zeros, HIGH-VALUES in fields where NULL semantics are intended); value range distributions against 88-level constraints; structural integrity (valid COMP-3 bit patterns, valid COMP-5 representations); cross-field consistency (date fields where day values exceed the maximum for the stated month); and cross-record consistency (related records that should agree on shared attributes but do not).
Step 3: Cross-program consistency assessment. For each business entity that is represented across multiple programs or datasets, assess consistency across representations. This requires: identifying which programs maintain overlapping representations (through dependency mapping); extracting the records for each representation of each entity; comparing the values that should be consistent; and documenting the discrepancies with their frequency and severity.
Step 4: Precision impact analysis. For every COMP-3 and binary numeric field, calculate the precision implications of the target field type mapping. Specifically: identify any values in the source data that cannot be represented exactly in the target field type; quantify the rounding error that would result from the type conversion; and determine whether the rounding error is acceptable given the downstream use case (regulatory reporting versus internal analytics have different tolerance thresholds).
Step 5: Dimension scoring and composite score calculation. Apply the dimension scores and weight them according to the data type and migration target context. Produce the composite score and migration readiness classification for each dataset and for the portfolio as a whole.
Step 6: Remediation planning. For datasets that score below the migration readiness threshold, produce a remediation plan that identifies: the specific data elements that failed which quality checks; the volume of records affected; the business rule or transformation that would correct the failure; and the validation check that will confirm remediation is complete.
SQL Patterns for Data Quality Measurement
Practical quality assessment requires executable measurement. The following SQL patterns implement the most common modernization-specific quality checks against data that has been extracted from legacy systems into a staging environment:
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;The Quality Gate Framework for Migration Waves
A modernization program typically migrates in waves, groups of applications and datasets that move together. The data quality scoring framework drives the wave composition decisions:
Wave eligibility criteria: A dataset is eligible for a migration wave only when its composite quality score exceeds the wave’s minimum threshold. For Tier 1 (mission-critical) applications, the minimum threshold is 85. For Tier 2, it is 75. This prevents mission-critical applications from migrating on data that has not been adequately qualified.
Pre-wave quality gate: Before any wave begins migration execution, a final quality scan confirms that the data’s quality score has not degraded since the initial assessment. Data quality can deteriorate between the initial assessment and migration execution if the source system continues running and accumulating new records that do not meet the quality standards identified during assessment.
Post-migration equivalence validation: After each wave migrates, the quality framework provides the comparison baseline: every dimension score calculated on the source data is recalculated on the migrated data, and the delta between source and target scores is the migration quality report. A migration that produced a target dataset with lower accuracy, lower completeness, or lower cross-program consistency than the source has introduced quality degradation that must be investigated before proceeding to the next wave.
Ne kadar SMART TS XL Supports Data Quality Scoring for Modernization
The migration-specific quality dimensions, schema variant coverage, cross-program consistency, precision-aware quality, and structural integrity, all depend on a level of understanding of the source application code that standard data quality tools do not have. They require knowing what the programs that produce the data define as valid, what fields are COMP-3 and require precision-aware target mapping, and which programs maintain overlapping representations of the same business entities.
SMART TS XL'S statik kod analizi provides the schema discovery layer: parsing every FD entry, COPY member, and SELECT clause across the COBOL portfolio to produce the complete schema inventory, all field definitions, all REDEFINES hierarchies, all 88-level constraints, all COMP-3 precision specifications. This inventory is the foundation that the migration-specific quality dimensions require and that cannot be derived from the data itself.
MKS uygulama bağımlılık eşlemesi enables the cross-program consistency assessment: by building the map of which programs maintain which data, which programs write to which VSAM datasets, which datasets contain overlapping representations of the same business entities, the dependency map identifies the pairs and groups that require cross-program consistency scoring. Without this map, the cross-program consistency dimension cannot be assessed because the assessor does not know which programs and datasets represent the same entities.
MKS etki analizi capability makes the quality gate framework operational at scale: when a quality issue is found in a specific dataset, the impact analysis identifies every application, program, and business process that depends on that dataset, determining the scope of the quality issue’s downstream consequences and prioritizing remediation based on how many dependent programs are affected.
MKS kurumsal arama capability makes the quality inventory queryable throughout the migration program: find every program that reads a specific VSAM file (to scope the cross-program consistency assessment), every field defined as COMP-3 (to build the precision-aware quality inventory), every 88-level condition name (to enumerate the semantic validity constraints that external tools cannot see). This search capability supports both the initial quality assessment and the ongoing monitoring that ensures quality does not degrade between assessment and migration execution.
Faaliyet gösteren kuruluşlar için miras modernizasyonu programları SMART TS XL’s analysis bridges the gap between the data quality frameworks designed for operational monitoring and the migration-specific quality requirements that determine whether modernization projects produce the correct results. The standard data quality dimensions are necessary. The migration-specific extensions are what makes them sufficient.
Conclusion: Quality for Migration Is Not Quality for Operations
The 2026 data quality landscape is rich with frameworks, tools, and metrics designed for operational data management. The DAMA dimensions are well-established and widely implemented. The tooling, Great Expectations, Monte Carlo, Collibra, dbt, has matured significantly. The standard approach of defining quality rules, profiling data, and monitoring against thresholds works well for the operational purpose it was designed for.
Modernization projects require something different. They require quality scoring that assesses migration fitness, not operational fitness. They require understanding of the source code that produces the data, not just the data itself. They require precision-aware numeric field analysis, REDEFINES variant coverage, and cross-program consistency assessment, dimensions that operational quality frameworks do not address because operational systems do not require them.
The organizations that produce correct migration results are the ones that build their data quality scoring frameworks for the specific purpose of migration before extending them for operational monitoring afterward. Data quality for migration is not a subset of operational data quality management. It is its own discipline, with its own dimensions, its own thresholds, and its own validation requirements, and treating it as such is what makes modernization programs deliver on their technical promises.
