MDM Migration Playbook

Executive Summary

Master data management (MDM) migration moves key business records (e.g., customers, products and suppliers) from an existing system to a new MDM system. MDM migration involves transferring record identifiers, relationships, quality rules and access controls to the new environment so connected systems can continue using the data after cutover.

The completion of a full data load indicates that records have been transferred, but does not by itself confirm a successful migration. In addition to checking that the intended business records have been migrated, business stakeholders need confirmation that valid values within each record have been retained, that relationships associated with the records have remained intact and that essential workflow processes continue to operate properly. Testing also checks whether generative AI (GenAI) or AI agents consuming master data can retrieve the relevant information within defined permissions and perform only authorized actions using the appropriate tools.

This playbook organizes the work into four phases: Mobilize, Design, Prove and Transition. Each phase produces evidence for the next decision. The proposed controls and readiness measures are planning tools; teams adapt them to their domain, architecture and consequences of failure.

The initial decisions cover scope, ownership, acceptance criteria, recovery and AI authority. The documentation of these decisions provides both business and technical teams a common basis for resolving exceptions and assessing cutover readiness.

Actionable Information, Not Just Data

Master data becomes “actionable” when people and systems can identify it reliably, understand what it represents, and use approved values within the appropriate business processes. When migrating data from one source to another, the migration also includes making decisions regarding the meaning of the migrated information and who will have the authority to determine whether such information should be used, in addition to simply transferring the data.

As an illustration, there are potentially multiple records describing the same supplier company with differing payment terms for the same contract associated with each record. Simply loading all of those records into a new database does not provide any clarity as to which payment terms the accounts payable workflow should utilize. In this example, the target design includes a set of rules that have been formally approved by a designated authority, specifying how the values should be selected, and a formal path for resolving conflicts.

This is merely an illustrative example and not a documented result of any actual project.

Migration Risks and Intended Outcomes

Three main risks need to be addressed during discovery. First, inconsistencies existing in the source system may be duplicated in the target system. Second, central repositories may contain unresolved identity or value conflicts. Third, there may be no clear definition of write authority between the two systems, which may result in them overwriting each other’s changes. These potential pitfalls can be identified through profiling, rule review and integration testing.

Expected benefits must be measured against an agreed baseline and measurement period. Common measurements would include duplicate record rates, time spent resolving exceptions, failed downstream transactions and onboarding time for new records. In addition, if AI technologies are used in the affected workflows, relevant measurements include retrieval accuracy and unauthorized-action attempts. Expected improvements remain targets until post-migration results confirm them.

The Four Phases

An evidence gate is the formal checkpoint to either accept, hold or revise the next phase. Any unresolved critical exceptions remain open until their causes and agreed disposition have been documented.

Phase I Mobilize

Establish Scope and Outcome

The charter outlines which domains, business processes, and consumers are included in the migration scope. It also states the business reason for the migration, baseline measures, intended results, constraints, and acceptance owners. Document AI use cases separately so optional automation does not obscure mandatory migration requirements.

Identify Source Systems & Their Consumers

The inventory lists applications, files, interfaces, identifiers and manual correction processes. It also identifies reports, retrieval indexes and AI agents that depend on the data. Each dependency is recorded with its owner, update path and expected behavior during the transition.

Determine Decision Authority

If conflicting values exist, then a named decision owner should be designated along with a documented resolution rule. The governance plan identifies who approves definitions, accepts exceptions, authorizes AI actions, and makes the cutover decision. Escalation times reflect the business impact of an unresolved issue.

Phase I evidence includes:

• An approved charter
• A source-to-consumer map
• Decision authorities assigned

Any missing dependencies or unclear critical attributes remain recorded in the issue register.

Decision Ownership and Records

The decision ledger is used as a repository for each material decision, which includes the issue, owner, approved choice, rationale, evidence, effective date and downstream impact. For material AI-driven decisions, the decision ledger will include additional fields such as model or AI agent version, proposed actions, validation results and approval records.

In addition, the plan establishes who has the right to stop a migration wave and what constitutes sufficient evidence to resume that migration wave, thus making escalation an actionable tool in both rehearsal and cutover.

Phase II Design

Data Quality and Business Impact

Profiling establishes the current condition of each domain before targets are set. Measures cover completeness, uniqueness, consistency, timeliness, validity and accuracy. Thresholds depend on how each attribute is used and what happens when it is wrong.

For AI consumers, assessment also covers source provenance, freshness, meaning and access scope. A technically valid field may still be unsuitable for a particular retrieval or automated action.

Mapping Specifications

Each mapping specification should identify the source and target fields, business definition, authoritative source, transformation rules, missing-value treatment, relationship validation rules and exception-handling process. The lineage tracks the final output back to its original data as well as the specific rule version. Where applicable, sensitive fields as well as permitted AI uses are noted.

The review process includes answering three questions:

• Will the mapping preserve meaning?
• Will the mapping be able to run within our volume and timing expectations?
• Are all downstream users and systems going to be able to properly understand the results of the mapping?

Approved examples and edge cases should provide enough documentation to allow reviewers to determine answers to these three questions.

Matching and Survivorship extended

Matching allows you to identify potential duplicate records.

Merging combines two or more records after the matches have been approved.

Survivorship determines which attribute values are kept in the merged record. These decisions are made based on the attributes’ defined source authority, validity, and recency. Simply being the most recent data is not sufficient because newer values may not be valid.

There are many different methods that can be used to create candidate pairs (exact, probabilistic, or even an AI method).

Thresholds exist to automate acceptance or send ambiguous candidates to a reviewer for further evaluation.

False positives (i.e. incorrect matches) and false negatives (i.e. missed matches) are evaluated against a set of reviewed examples.

Documented default values distinguish populated fields from information that was available in the source.

Evidence submitted during Phase II includes approved mappings, quality thresholds, representative examples of matched records, and a versioned document outlining the survivorship strategy. AI-generated suggestions are assessed against the approved mappings, quality thresholds, survivorship rules and the established approval process.

Phase III Prove

A representative pilot will cover both typical records and also hard-to-handle ones. Cases of interest could include very high volumes, uncertain identities, multilingual attributes, broken hierarchies and sensitive fields. The pilot will reflect the intended scope of migration and will include AI retrieval paths and agent tool use where applicable.

The rehearsal tests a load similar to what would be seen during production and includes exceptions, quarantine, reruns and recovery. Running the same test again with corrections made will help determine if the process is repeatable; an initial successful load does not provide enough information regarding its ability to be repeated.

Reconciliation and Acceptance

Reconciliation is concerned with four key areas – structure, counts, meaning and operations. Structurally, we check whether the schema and format have been correctly aligned; count-wise, we verify why certain items were added, removed, merged or quarantined. Semantically, we ensure that the approved surviving values are retained along with their corresponding lineage and relationships. We then perform operational tests to validate searches, workflows, interfaces and applicable AI journeys.

In addition to providing a clear record of differences between source and target, record-matching quality and relationship checks, the acceptance pack will include business user acceptance testing results, exception disposition reports, performance and security test results as well as recovery evidence. For AI-enabled flows, the acceptance pack will also include retrieval tests, output reviews and tool-call traces.

Critical rule pass rate = (critical rules passed / critical rules tested) × 100. In addition to identifying the percentage of successful critical rule passes, the report will also identify required rules that were not tested. The report will display results per domain. Individual critical failures will be shown separately instead of being masked by the domain average.

GenAI and Agent Controls

GenAI can help propose mappings, document rules and explain recorded lineage. Agents coordinate bounded tasks such as profiling, reconciliation and support triage. These use cases should be tested against your organization’s workloads to assess their usefulness and reliability.

Sources and Permissions

Approved sources, freshness requirements, permitted use, and sensitive data are identified in the control record. Each agent has an identifiable service identity and is provided with only the required permissions for its task. Tools and actions allowed for the agent are specified on an allowlist. Any retrieved text and/or supplier files are considered data and therefore cannot grant permission to perform additional activities nor modify workflow rules.

Approval and Recovery

The control model in this playbook places approval for high-impact merges, writes and irreversible actions outside the model. Logs link the proposal, validation, approver, and executed activity. Privacy and retention restrictions limit prompt and output logging.

Testing includes prohibited actions, missing approvals, and attempts to exceed scope. Stop controls disable the relevant automated pathway. Recovery procedures address completed actions and resulting downstream effects. Approval records, tested permissions, and stop-and-recovery test results form the release evidence.

Privacy and Compliance Review

Data migration may change how personal data is stored, shared, retained and used in automated processes. The privacy review captures all of the above details and identifies which regulations apply to the organization and processing activity.

The privacy review covers purpose, data minimization, access, individual rights workflows, transfers, retention and deletion. Security testing includes masking, encryption, logging and incident response. When there are new ways of accessing or processing data through AI retrieval and action paths, those will also be captured.

Before a process is released, legal and privacy owners will review the applicable obligations and verify that all required approvals have been completed. This operational checklist does not establish legal compliance.

The RAID Register

The RAID register tracks risks, assumptions, issues and dependencies. Decisions made will be tied into the decision ledger. All entries contain an owner, review trigger, response, due date, residual exposure and closure evidence. As rehearsal and cutover approach, the review frequency will increase.

Some examples of RAID register entries would be:

• An issue with false merges which require steward review.
• A business assumption that source identifiers will remain consistent throughout the migration process.
• An unresolved parent-child relationship.
• A dependency on an interface with downstream systems.

Closure records will provide the corrective evidence or authorized risk acceptance and will retain any remaining actions.

Executive Glossary

Golden Record: An organization’s approved, consolidated description of a business entity, such as a customer, product or supplier.

Survivorship: The rules used to determine which attribute data from different sources will be selected.

Lineage: The process of tracing data back to its original sources and documenting the transformations performed on that data.

Grounding: Providing relevant source information as context to support an AI-generated response.

Agentic AI: Artificial intelligence that performs multiple steps and uses tools to reach a specific objective.

Deterministic Approval: Approval required under predetermined conditions, enforced by workflow logic outside the model itself.

Tool Allowlist: The tools and actions an agent is permitted to use.

Quarantine Records: Records held pending review or correction before being processed further.

Rollback: The process of restoring an agreed recoverable state.

Kill Switch: A control that disables a particular pathway of automated action.

Readiness Assessment

This readiness assessment covers six areas: ownership, mapping, data quality, testing, rollback and AI controls. The scale will be as follows:

• Unknown = 0
• Documented = 1
• Approved = 2
• Tested = 3
• Proven = 4 (against agreed acceptance criteria)

Each score must be linked to evidence. This is an internal assessment for the project and not a third-party industry certification. Cutover approval depends on the agreed acceptance criteria and supporting evidence, rather than the total score alone.

With all six areas assessed, the highest possible total score is 24. If AI is outside the migration scope, mark the AI controls as “not applicable”; the maximum score then becomes 20.

In this assessment, unresolved critical failures are recorded separately from the total score. A zero in ownership, critical-domain quality, rollback or applicable AI controls indicates an evidence gap for the cutover decision.

The First 90 Days

Days 0-30: Develop the charter, baseline metrics, source inventory, and identify responsible owners for each system and data domain. Identify dependencies and determine the proposed uses of AI.

Days 31-60: Prioritize and profile the key data domains, approve source-to-target mappings and quality thresholds, define retrieval permissions, and identify where human approval is required.

Days 61-90: Conduct a pilot with a representative sample of data, review match and workflow results, test stop controls and measure recovery time. Use these results to refine the migration plan prior to starting additional waves.

The above represents an indicative migration planning timeline. There is no guarantee that all migrations will be completed within 90 days. This will depend on the scope of the migration, unresolved issues and evidence provided at each gate.

Migration Readiness Support

Minds Task Technologies assists organizations with developing their MDM strategy, data modeling, quality and matching rules, migration validation and governance for GenAI and agent workflows.