O argumento padrão para o investimento em qualidade de dados baseia-se no risco operacional: 84% das organizações sofrem interrupções mensuráveis devido à baixa qualidade dos dados, e mais de um quarto delas perde mais de US$ 5 milhões anualmente como consequência direta. A resposta padrão é um programa de gestão da qualidade de dados que mede a precisão, a integridade, a consistência, a atualidade, a validade e a singularidade dos dados em relação a limites predefinidos, um painel de métricas que monitora se os dados que fluem pelos sistemas operacionais atendem aos padrões definidos.
O que essa estrutura padrão não foi projetada para é um projeto de modernização. Migrar dados de um mainframe baseado em COBOL para uma plataforma nativa da nuvem não é um problema contínuo de qualidade operacional. Trata-se de um evento de transformação com requisitos específicos de pré-migração, riscos específicos durante a migração e necessidades específicas de validação pós-migração, que as dimensões padrão de qualidade de dados abordam apenas parcialmente. A estrutura de pontuação de qualidade de dados apropriada para um projeto de modernização difere da estrutura apropriada para monitoramento operacional em três aspectos fundamentais: ela deve avaliar a adequação à migração, em vez da adequação às operações atuais; deve pontuar o risco de migração, em vez da taxa de erros operacionais; e deve produzir evidências para o processo de validação da migração que confirmem se os dados transformados se comportam de forma equivalente aos dados de origem.
Primeiro o esquema, depois a pontuação.
SMART TS XL Descobre todas as entradas FD, redefine a hierarquia e o campo COMP-3 em todo o seu portfólio COBOL.
SAIBA MAIS…Por que as estruturas padrão de qualidade de dados são insuficientes para a modernização
As seis dimensões da estrutura DAMA (Data Management Body of Knowledge) — precisão, completude, consistência, atualidade, validade e unicidade — medem a qualidade dos dados em relação aos requisitos operacionais. Um registro com 95% de precisão, 98% de completude e 99% de consistência atende aos limites de qualidade operacional da maioria dos sistemas. Ele pode ou não ser adequado para migração e pode ou não produzir resultados corretos no sistema de destino.
A insuficiência não reside nas dimensões em si, mas no que elas medem e no que deixam de fora para o propósito específico de um projeto de modernização.
A adequação da migração não é o mesmo que a adequação operacional. Um registro VSAM com um campo decimal compactado COMP-3 válido, que funciona corretamente em COBOL, pode migrar incorretamente para um banco de dados de destino se o campo de destino for definido como FLOAT em vez de DECIMAL. Esse erro de precisão passa nas verificações de qualidade operacional porque os programas COBOL que leem o campo original calculam os resultados corretos a partir da representação COMP-3, mas produz erros de arredondamento no sistema de destino que usa aritmética de ponto flutuante. A pontuação de qualidade operacional foi alta; a pontuação de adequação da migração é baixa.
Os contratos de dados implícitos do sistema de origem são invisíveis para ferramentas externas de qualidade. Os programas COBOL impõem a qualidade dos dados por meio de código procedural, verificações de intervalo em instruções IF, validação de formato em blocos EVALUATE e regras de cálculo em instruções COMPUTE. Essas regras de qualidade existem no código-fonte, não nos próprios dados. Ferramentas externas de qualidade de dados que criam perfis dos dados sem analisar os programas que os produzem não conseguem visualizar essas restrições implícitas e, portanto, não podem determinar se o sistema de destino impõe restrições equivalentes.
A prontidão para IA introduz uma terceira dimensão além da adequação operacional e da migração. A Gartner prevê que 60% dos projetos de IA não suportados por dados prontos para IA serão abandonados até 2026. “Dados prontos para IA” não são o mesmo que “dados limpos” na definição operacional. Um modelo de IA não sabe que a “Receita” no sistema financeiro exclui reembolsos, mas a “Receita” no CRM não a exclui; ele trata ambas como a mesma métrica e se baseia nessa inconsistência. Projetos de modernização que fazem parte de uma transformação de IA ou análise de dados devem avaliar a qualidade dos dados com base em um terceiro padrão: se os dados migrados produzirão resultados confiáveis em cargas de trabalho de IA e análise subsequentes.
Dimensões de Qualidade de Dados Específicas da Modernização
Uma estrutura de pontuação da qualidade dos dados para projetos de modernização amplia as seis dimensões padrão com cinco avaliações específicas para migração:
As Seis Dimensões Padrão (Aplicadas ao Contexto da Migração)
Precisão, o grau em que os dados representam corretamente a entidade ou evento do mundo real que descrevem. No contexto da migração, a precisão deve ser avaliada em relação à representação do sistema de origem e à representação do sistema de destino. Um valor financeiro armazenado como PIC S9(11)V99 COMP-3 Em COBOL, representa um valor com duas casas decimais implícitas no formato decimal compactado. O mesmo valor armazenado como DECIMAL(13,2) no banco de dados de destino representa o mesmo valor. O mesmo valor armazenado como FLOAT(8) representa um valor aproximadamente correto, mas não idêntico, para valores que não podem ser representados exatamente em ponto flutuante binário.
Completude é o grau em que todos os dados necessários estão presentes. Programas COBOL frequentemente usam campos FILLER, bytes de preenchimento e valores sentinela (todos os espaços, todos os zeros, HIGH-VALUES) como equivalentes funcionais a NULL, que não se traduzem literalmente para a semântica de NULL do SQL. Uma avaliação de completude para migração deve identificar esses valores nulos funcionais, que estão fisicamente presentes, mas representam a ausência de dados significativos, e determinar como eles se relacionam com o tratamento de nulos do sistema de destino.
Consistência é o grau em que os dados estão livres de contradições entre conjuntos de dados ou dentro de um mesmo conjunto. Para dados de mainframe, a consistência entre programas é particularmente importante: a mesma entidade de negócios (um cliente, uma conta, uma apólice) pode ser representada em vários arquivos VSAM ou tabelas DB2 mantidos por diferentes programas. Cada programa possui seu próprio registro do estado atual da entidade. A avaliação de consistência deve verificar se essas representações coincidem ou identificar as discrepâncias que precisam ser resolvidas antes que a migração produza um conjunto de dados de destino coerente.
A pontualidade refere-se ao grau em que os dados refletem a realidade atual dentro de um período de tempo aceitável. Para dados de mainframe processados em lote, a pontualidade é determinada pelo ciclo do lote: um lote mensal gera dados atualizados com uma margem de erro de um mês. A exigência de pontualidade do sistema de destino, que pode necessitar de dados quase em tempo real para cargas de trabalho analíticas que o sistema de origem nunca foi projetado para suportar, estabelece uma lacuna de pontualidade que a migração por si só não consegue sanar.
Validade, o grau em que os dados estão em conformidade com as restrições de formato e tipo definidas. Os nomes de condição de 88 níveis do COBOL criam restrições de validade semântica que não são capturadas pelo sistema de tipos de dados: um campo definido como PIC 9(2) Pode ser válido no programa COBOL somente quando contiver valores de 01 a 12 (meses) ou de 01 a 31 (dias), com a validade garantida pela condição de nível 88. Ferramentas externas de qualidade de dados que analisam o campo o visualizam como um campo numérico de dois dígitos; elas não veem a restrição semântica que torna os valores 00 e de 13 a 99 inválidos no contexto.
Unicidade é o grau em que as entidades de dados são representadas uma única vez. A dimensão de unicidade para dados COBOL exige a compreensão de que os arquivos VSAM KSDS impõem unicidade por chave primária no nível do arquivo, mas que a mesma entidade lógica pode aparecer em múltiplos arquivos VSAM mantidos por programas diferentes, com chaves diferentes. A resolução de entidades entre arquivos, ou seja, determinar se o registro CUSTOMER-RECORD em CUSTOMERSTR.VSAM e o registro ACCOUNT-HOLDER em ACTHLD.VSAM representam a mesma pessoa real, é um problema de unicidade que não pode ser avaliado examinando-se cada arquivo isoladamente.
As cinco dimensões específicas da migração
Integridade estrutural é o grau em que o layout físico dos dados corresponde às definições de esquema esperadas pelos programas. Os dados COBOL são armazenados de acordo com as especificações da cláusula PIC; os bytes físicos em disco ou em registros VSAM devem estar em conformidade com essas especificações para que os programas os interpretem corretamente. Falhas de integridade estrutural, como registros em que um campo COMP-3 contém padrões de bits inválidos para decimal compactado ou em que um campo numérico contém caracteres não numéricos, são comuns em dados legados e invisíveis para os programas que nunca utilizam os valores inválidos. Elas se tornam falhas de migração quando as ferramentas de conversão tentam ler esses campos.
A cobertura de variantes de esquema refere -se ao grau em que a pontuação da qualidade dos dados considera todas as variantes REDEFINES no esquema de origem. Conforme discutido no contexto da análise da estrutura de arquivos VSAM, um registro VSAM pode ter vários layouts sobrepostos definidos por meio de cláusulas REDEFINES. Uma avaliação padrão da qualidade dos dados que analisa o layout do registro base não considera as características de qualidade das variantes REDEFINES, incluindo os valores no campo discriminador que determinam qual variante se aplica a cada registro e a validade dos valores de campo de cada variante sob a condição apropriada.
Consistência entre programas é o grau em que os valores dos dados são consistentes entre programas que mantêm representações sobrepostas das mesmas entidades de negócio. Essa dimensão é específica para ambientes mainframe, onde a mesma entidade é mantida por múltiplos programas através de conjuntos de dados compartilhados. Uma regra de negócio implementada de forma diferente em dois programas, porque um foi atualizado quando a regra mudou e o outro não, produz inconsistência entre programas que é invisível para qualquer avaliação de qualidade de dados de um único programa.
Qualidade com reconhecimento de precisão , o grau em que os dados numéricos podem ser representados no sistema de destino com precisão equivalente. Essa dimensão aborda especificamente os campos COMP-3, COMP e COMP-5, comuns em programas COBOL, que exigem mapeamento de tipo de destino com reconhecimento de precisão. Uma avaliação de qualidade que identifica todos os campos numéricos e verifica se seus valores estão dentro do intervalo e da precisão do tipo de campo de destino é uma verificação de qualidade específica da migração que as ferramentas de perfilamento padrão não realizam.
A pontuação de prontidão para migração é uma avaliação composta que determina se cada entidade de dados está pronta para migrar tal como está, se requer correção pré-migração ou se requer transformação no destino para atingir um comportamento equivalente. A pontuação de prontidão para migração é o resultado da combinação das dimensões anteriores: um registro com alta pontuação em precisão, completude, consistência, validade, unicidade, integridade estrutural, cobertura de variantes de esquema, consistência entre programas e qualidade com reconhecimento de precisão está pronto para migração. Um registro que não atenda a qualquer uma dessas dimensões requer descarte, limpeza, transformação, exclusão ou aceitação da alteração com risco documentado.
Cálculo da pontuação de qualidade composta
A pontuação composta de qualidade de dados para um projeto de modernização é uma média ponderada das pontuações das dimensões, onde os pesos refletem a importância relativa de cada dimensão para o contexto específico da migração:
| Dimensão | Peso Padrão | Ajuste para dados financeiros | Ajuste para o alvo de análise |
|---|---|---|---|
| Precisão | 25% | 30% (precisão crítica) | 20% |
| plenitude | 20% | 15% | 25% (A IA precisa de todas as funcionalidades) |
| Consistência | 15% | 20% (regulamentar) | 20% |
| Validade | 15% | 15% | 10% |
| Singularidade | 10% | 10% | 15% (desduplicação para IA) |
| oportunidade | 5% | 5% | 10% (frescor para modelos) |
| Integridade Estrutural | 5% | 2% | 0% (pós-conversão) |
| Cobertura de variantes de esquema | 3% | 2% | 0% |
| Consistência entre programas | 1% | 1% | 0% |
| Qualidade com foco na precisão | 1% | 1% | 0% |
Cada dimensão recebe uma pontuação de 0 a 100, e a pontuação composta é a soma ponderada. A pontuação composta determina a classificação de prontidão para migração:
| Pontuação composta | Preparação para migração | Disposição recomendada |
|---|---|---|
| 90-100 | Pronto | Migrar com validação padrão |
| 75-89 | Pronto para monitoramento | Migre com validação pós-migração aprimorada. |
| 60-74 | Condicional | Corrija falhas específicas de dimensão antes da migração. |
| 40-59 | Não está pronto | É necessária uma remediação pré-migratória significativa. |
| Abaixo 40 | questões críticas de qualidade | Não migre até que a análise da causa raiz e a remediação estejam concluídas. |
Medição prática: o fluxo de trabalho de avaliação
A avaliação da qualidade dos dados em um projeto de modernização segue um fluxo de trabalho específico que difere do monitoramento da qualidade operacional:
Etapa 1: Descoberta e documentação do esquema. Antes que qualquer dado possa ser pontuado, o esquema que o define deve ser conhecido. Para dados de mainframe, isso significa analisar as entradas FD, os membros COPY e as cláusulas SELECT de cada programa COBOL que acessa cada conjunto de dados. A fase de descoberta do esquema produz: o inventário completo de campos com tipos de dados, comprimentos e especificações COMP; todas as hierarquias REDEFINES e suas condições discriminadoras; os nomes das condições de nível 88 e suas restrições semânticas; e as regras de qualidade de dados em nível de programa incorporadas na lógica PROCEDURE DIVISION.
Etapa 2: Perfilamento de dados em relação ao esquema descoberto. Analise o perfil de cada conjunto de dados em relação ao esquema descoberto na Etapa 1, e não em relação a um esquema presumido ou documentado. Analise os seguintes aspectos: frequências equivalentes a valores nulos (espaços, zeros, valores ALTOS em campos onde a semântica NULL é pretendida); distribuições de intervalo de valores em relação às restrições de nível 88; integridade estrutural (padrões de bits COMP-3 válidos, representações COMP-5 válidas); consistência entre campos (campos de data em que os valores do dia excedem o máximo para o mês especificado); e consistência entre registros (registros relacionados que deveriam concordar em atributos compartilhados, mas não concordam).
Etapa 3: Avaliação da consistência entre programas. Para cada entidade de negócio representada em múltiplos programas ou conjuntos de dados, avalie a consistência entre as representações. Isso requer: identificar quais programas mantêm representações sobrepostas (por meio do mapeamento de dependências); extrair os registros para cada representação de cada entidade; comparar os valores que deveriam ser consistentes; e documentar as discrepâncias, incluindo sua frequência e gravidade.
Etapa 4: Análise do impacto na precisão. Para cada campo numérico binário e COMP-3, calcule as implicações de precisão do mapeamento do tipo de campo de destino. Especificamente: identifique quaisquer valores nos dados de origem que não possam ser representados exatamente no tipo de campo de destino; quantifique o erro de arredondamento que resultaria da conversão de tipo; e determine se o erro de arredondamento é aceitável, considerando o caso de uso subsequente (relatórios regulatórios versus análises internas têm limites de tolerância diferentes).
Etapa 5: Pontuação dimensional e cálculo da pontuação composta. Aplique as pontuações dimensionais e pondere-as de acordo com o tipo de dados e o contexto de destino da migração. Gere a pontuação composta e a classificação de prontidão para migração para cada conjunto de dados e para o portfólio como um todo.
Etapa 6: Planejamento de remediação. Para conjuntos de dados que obtiverem pontuação abaixo do limite de prontidão para migração, elabore um plano de remediação que identifique: os elementos de dados específicos que falharam em quais verificações de qualidade; o volume de registros afetados; a regra de negócio ou transformação que corrigiria a falha; e a verificação de validação que confirmará a conclusão da remediação.
Padrões SQL para Medição da Qualidade de Dados
A avaliação prática da qualidade requer medições executáveis. Os seguintes padrões SQL implementam as verificações de qualidade mais comuns específicas para modernização, aplicadas a dados extraídos de sistemas legados para um ambiente de teste:
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;O Quadro de Controle de Qualidade para Ondas Migratórias
Um programa de modernização normalmente migra em ondas, grupos de aplicações e conjuntos de dados que se movem em conjunto. A estrutura de pontuação da qualidade dos dados orienta as decisões sobre a composição das ondas:
Critérios de elegibilidade da onda: Um conjunto de dados é elegível para uma onda de migração somente quando sua pontuação de qualidade composta excede o limite mínimo da onda. Para aplicações de Nível 1 (missão crítica), o limite mínimo é 85. Para Nível 2, é 75. Isso impede que aplicações de missão crítica migrem com dados que não foram adequadamente qualificados.
Controle de qualidade pré-onda: Antes do início da execução da migração em qualquer onda, uma verificação final de qualidade confirma se a pontuação de qualidade dos dados não se degradou desde a avaliação inicial. A qualidade dos dados pode deteriorar-se entre a avaliação inicial e a execução da migração se o sistema de origem continuar em funcionamento e acumulando novos registros que não atendam aos padrões de qualidade identificados durante a avaliação.
Validação de equivalência pós-migração: Após a migração de cada onda, a estrutura de qualidade fornece a linha de base de comparação: cada pontuação de dimensão calculada nos dados de origem é recalculada nos dados migrados, e a diferença entre as pontuações de origem e destino constitui o relatório de qualidade da migração. Uma migração que produziu um conjunto de dados de destino com menor precisão, menor completude ou menor consistência entre programas do que a origem introduziu uma degradação de qualidade que deve ser investigada antes de prosseguir para a próxima onda.
Como SMART TS XL Suporta a avaliação da qualidade dos dados para a modernização.
As dimensões de qualidade específicas da migração, a cobertura de variantes de esquema, a consistência entre programas, a qualidade com reconhecimento de precisão e a integridade estrutural dependem de um nível de compreensão do código-fonte do aplicativo que as ferramentas padrão de qualidade de dados não possuem. Elas exigem saber o que os programas que produzem os dados definem como válido, quais campos são COMP-3 e exigem mapeamento de destino com reconhecimento de precisão e quais programas mantêm representações sobrepostas das mesmas entidades de negócios.
SMART TS XL'S análise de código estático Fornece a camada de descoberta de esquema: analisando cada entrada de FD, membro COPY e cláusula SELECT em todo o portfólio COBOL para produzir o inventário completo do esquema, todas as definições de campo, todas as hierarquias REDEFINES, todas as restrições de nível 88 e todas as especificações de precisão COMP-3. Esse inventário é a base que as dimensões de qualidade específicas da migração exigem e que não podem ser derivadas dos próprios dados.
O mapeamento de dependências de aplicações permite a avaliação da consistência entre programas: ao construir um mapa que mostre quais programas mantêm quais dados, quais programas gravam em quais conjuntos de dados VSAM e quais conjuntos de dados contêm representações sobrepostas das mesmas entidades de negócio, o mapa de dependências identifica os pares e grupos que requerem pontuação de consistência entre programas. Sem esse mapa, a dimensão de consistência entre programas não pode ser avaliada, pois o avaliador não sabe quais programas e conjuntos de dados representam as mesmas entidades.
A capacidade de análise de impacto torna a estrutura de controle de qualidade operacional em escala: quando um problema de qualidade é encontrado em um conjunto de dados específico, a análise de impacto identifica todos os aplicativos, programas e processos de negócios que dependem desse conjunto de dados, determinando o escopo das consequências subsequentes do problema de qualidade e priorizando a correção com base em quantos programas dependentes são afetados.
A funcionalidade de busca corporativa permite consultar o inventário de qualidade em todo o programa de migração: encontre todos os programas que leem um arquivo VSAM específico (para delimitar a avaliação de consistência entre programas), todos os campos definidos como COMP-3 (para construir o inventário de qualidade com reconhecimento de precisão) e todos os nomes de condições de nível 88 (para enumerar as restrições de validade semântica que ferramentas externas não conseguem visualizar). Essa funcionalidade de busca oferece suporte tanto à avaliação inicial de qualidade quanto ao monitoramento contínuo, garantindo que a qualidade não se degrade entre a avaliação e a execução da migração.
Para organizações que realizam modernização legada programas, SMART TS XLA análise de [nome da empresa] preenche a lacuna entre as estruturas de qualidade de dados projetadas para monitoramento operacional e os requisitos de qualidade específicos da migração, que determinam se os projetos de modernização produzem os resultados corretos. As dimensões padrão de qualidade de dados são necessárias. As extensões específicas da migração são o que as tornam suficientes.
Conclusão: Qualidade para migração não é qualidade para operações.
O cenário de qualidade de dados para 2026 é rico em frameworks, ferramentas e métricas projetadas para o gerenciamento de dados operacionais. As dimensões DAMA estão bem estabelecidas e amplamente implementadas. As ferramentas, como Great Expectations, Monte Carlo, Collibra e dbt, amadureceram significativamente. A abordagem padrão de definir regras de qualidade, criar perfis de dados e monitorá-los em relação a limites predefinidos funciona bem para o propósito operacional para o qual foi projetada.
Projetos de modernização exigem algo diferente. Exigem uma avaliação de qualidade que analise a adequação da migração, e não a adequação operacional. Exigem a compreensão do código-fonte que produz os dados, e não apenas dos próprios dados. Exigem análise de campos numéricos com foco na precisão, cobertura de variantes REDEFINES e avaliação da consistência entre programas, dimensões que as estruturas de qualidade operacional não abordam porque os sistemas operacionais não as exigem.
As organizações que obtêm resultados de migração corretos são aquelas que constroem suas estruturas de pontuação de qualidade de dados especificamente para a migração, antes de estendê-las para o monitoramento operacional posterior. A qualidade de dados para migração não é um subconjunto da gestão da qualidade de dados operacionais. Trata-se de uma disciplina própria, com suas próprias dimensões, seus próprios limites e seus próprios requisitos de validação, e tratá-la como tal é o que permite que os programas de modernização cumpram suas promessas técnicas.
