# Data Migration Strategy: [Programme or target system name]

> Strategy and design for moving business data from one or more legacy
> systems into a new target application (ERP, CRM, core banking, policy
> administration or a similar packaged or custom system). It covers the
> migration object inventory, source profiling, data quality and
> cleansing, mapping and transformation rules, the migration approach
> (big bang, phased or trickle), architecture and tooling, load sequence,
> historical data and archiving, mock loads, the reconciliation design,
> cutover data steps, fallback, security of migration data, roles and
> risks. Structure aligned with the Data Integration and
> Interoperability, Data Quality and Reference and Master Data knowledge
> areas of DAMA-DMBOK 2nd Edition Revised (March 2024) and with the data
> migration stages used in packaged-application delivery methods (SAP
> Activate phases, Microsoft Dynamics 365 Success by Design). Replace
> every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write one strategy per programme. Each mock load and the production
  load then gets its own reconciliation report, written with the Data
  Migration Reconciliation Report (`project/data-migration-reconciliation`).
- Start this document in the design phase, before build of the target
  configuration is finished. Data rules change the target design (for
  example mandatory fields and number ranges), so late migration design
  is the most common cause of go-live slippage.
- Fill sections 2, 3 and 6 first: the object list, the profiling
  results and the approach decide almost everything else.
- This document is about business data in a new application. For a
  technical platform move of a database or service (same schema,
  replication, dual writes), use the Migration Plan (`dev/migration-plan`).
  For a portfolio of applications moving to cloud, use the Migration
  Wave Plan (`project/migration-wave-plan`).
- Related documents: Cutover Plan (`project/cutover-plan`), Database
  Design Document (`architecture/database-design`), Data Requirements
  Specification (`requirements/data-requirements`), Master Data
  Management Design (`architecture/master-data-management-design`),
  Data Dictionary (`architecture/data-dictionary`), DPIA
  (`compliance/dpia`), Go-Live Readiness Review
  (`project/go-live-readiness-review`).
-->

## Document control

<!-- Guidance: Identify the programme, the source and target systems and the accountable data migration lead. A change of approach (section 6) or of the in-scope object list is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [DMS-001] |
| Programme | [Programme name] |
| Target system | [Product, version, tenant or client] |
| Source systems | [Source 1], [Source 2], [Spreadsheets or manual sources] |
| Planned go-live | YYYY-MM-DD |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@data-migration-lead] |
| Approvers/reviewers | [@solution-architect], [@business-data-owner], [@finance-controller], [@security-officer], [@dpo] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Related documents | [Cutover plan], [Target data model], [Reconciliation reports MCK-01 to MCK-03] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Programme sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Business data owners | [@name] | [Decision] | YYYY-MM-DD |
| Finance controller | [@name] | [Decision] | YYYY-MM-DD |
| Solution architect | [@name] | [Decision] | YYYY-MM-DD |
| Security and privacy | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft: object inventory and approach |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Profiling results and cleansing rules added after source extract |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved after mock load 1; tolerances agreed with finance |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Introduction and scope](#1-introduction-and-scope)
2. [Migration object inventory](#2-migration-object-inventory)
3. [Source landscape and data profiling](#3-source-landscape-and-data-profiling)
4. [Data quality and cleansing](#4-data-quality-and-cleansing)
5. [Mapping and transformation](#5-mapping-and-transformation)
6. [Migration approach](#6-migration-approach)
7. [Architecture and tooling](#7-architecture-and-tooling)
8. [Load sequence and dependencies](#8-load-sequence-and-dependencies)
9. [Historical data, archiving and retention](#9-historical-data-archiving-and-retention)
10. [Mock loads and rehearsals](#10-mock-loads-and-rehearsals)
11. [Reconciliation design](#11-reconciliation-design)
12. [Cutover data steps](#12-cutover-data-steps)
13. [Fallback and rollback](#13-fallback-and-rollback)
14. [Security and privacy of migration data](#14-security-and-privacy-of-migration-data)
15. [Roles and governance](#15-roles-and-governance)
16. [Risks, assumptions and traceability](#16-risks-assumptions-and-traceability)
17. [Glossary and references](#17-glossary-and-references)

## 1. Introduction and scope

<!-- Guidance: State why data moves, what "done" means and the principles that settle disputes. Questions to answer: which business processes must work on day one with migrated data, and which data can stay behind in an archive? Pitfall: "migrate everything" as a scope statement. -->

### 1.1 Purpose

This strategy defines how [Programme] will extract, cleanse, transform,
load and prove the business data that [Target system] needs at go-live.
It is the reference for the migration team, the business data owners
who sign off each object, the cutover manager and the auditors who will
later ask how opening balances were established.

### 1.2 Objectives and success criteria

| ID | Objective | Measure | Target |
|---|---|---|---|
| DMO-001 *(Example)* | Complete data for day-one processes | Unaccounted records per object at production load | 0 |
| DMO-002 *(Example)* | Correct financial opening position | Unexplained variance in control totals (section 11) | USD 0.00 |
| DMO-003 *(Example)* | Fit within the cutover window | End-to-end load duration in the last mock | 20 h or less inside a 48 h window |
| DMO-004 *(Example)* | Clean master data | Duplicate rate in customer and vendor master after load | Below 0.5% |
| DMO-005 *(Example)* | No loss of records needed for legal retention | Records not migrated but required by retention schedule that are archived and retrievable | 100% |
| [DMO-NNN] | [Objective] | [Measure] | [Target] |

### 1.3 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Customer, vendor and material master, open receivables and payables, general ledger balances, open sales orders, price conditions | Closed transactions older than 24 months (archived, section 9) |
| *Example:* Data from the legacy ERP and two regional spreadsheets | Data owned by systems that remain in service and integrate with the target |
| [Item] | [Item] |

### 1.4 Principles

| ID | Principle | Consequence |
|---|---|---|
| DMP-001 *(Example)* | Cleanse at the source wherever possible | Cleansing in the transformation layer is the exception and is logged per rule |
| DMP-002 *(Example)* | Business owns the data, IT owns the mechanism | Every object has a named business data owner who signs its reconciliation |
| DMP-003 *(Example)* | Load through the application's supported interfaces | Business validations of the target run on migrated data; direct table writes need an approved exception |
| DMP-004 *(Example)* | Every record is accounted for | Extracted equals excluded plus loaded plus rejected, for every object and every load |
| DMP-005 *(Example)* | Rules are code, versioned and repeatable | Each mock reruns the full pipeline from a fresh extract; no manual fixes in the target |
| [DMP-NNN] | [Principle] | [Consequence] |

## 2. Migration object inventory

<!-- Guidance: List every migration object: a business entity loaded as a unit, with its own rules, sequence and sign-off. Classify it, size it and give it an owner. Pitfall: forgetting configuration-like data that users maintain (price lists, approval limits, bank details) because nobody thinks of it as "data". -->

Object types used in this document:

- **Configuration data**: settings delivered by the build team as
  part of the target configuration (company codes, tax codes, units of
  measure). Not migrated by this strategy, but a prerequisite for it.
- **Reference data**: controlled code lists shared across objects
  (country codes, payment terms, industry codes). Value-mapped.
- **Master data**: long-lived business entities (customers, vendors,
  materials, employees, assets).
- **Open transactional data**: items still in progress on the cutover
  date (open invoices, open orders, open balances).
- **Historical data**: closed transactions kept for reporting,
  analysis or legal reasons.

| Object ID | Object | Type | Source | Source volume | In-scope rule | In-scope volume | Load method | Business owner |
|---|---|---|---|---|---|---|---|---|
| MO-001 *(Example)* | Customer master | Master | Legacy ERP | 52,400 | Active, or any transaction in the last 24 months | 48,210 | Target bulk load API | [@sales-ops-lead] |
| MO-002 *(Example)* | Vendor master | Master | Legacy ERP, AP spreadsheet | 9,850 | Active, or open item, or payment in the last 24 months | 7,320 | Target bulk load API | [@procurement-lead] |
| MO-003 *(Example)* | Material master | Master | Legacy ERP | 31,600 | Not flagged for deletion, and stock, open order or sale in the last 36 months | 27,940 | Migration tool staging tables | [@supply-chain-lead] |
| MO-004 *(Example)* | Open receivable items | Open transactional | Legacy ERP | 18,455 | Open on cutover date | 18,455 | Target journal interface | [@ar-lead] |
| MO-005 *(Example)* | Open sales orders | Open transactional | Legacy ERP | 3,120 | Not flagged for deletion | 3,035 | Target order API | [@order-mgmt-lead] |
| MO-006 *(Example)* | General ledger balances | Open transactional | Legacy ERP | 1,140 accounts | Balance-sheet accounts, plus year-to-date profit and loss by period | 1,140 | Target journal interface | [@finance-controller] |
| MO-007 *(Example)* | Price conditions | Master | Legacy ERP | 64,300 | Valid on or after cutover date | 22,780 | Migration tool staging tables | [@pricing-lead] |
| MO-008 *(Example)* | Open payable items | Open transactional | Legacy ERP, AP spreadsheet | 6,210 | Open on cutover date | 6,210 | Target journal interface | [@ap-lead] |
| [MO-NNN] | [Object] | [Type] | [Source] | [Count] | [Rule] | [Count] | [Method] | [@owner] |

Sizing note: the in-scope volume is the expected record count used in
every reconciliation report. Record the extract date of the numbers; they
change until the final extract.

## 3. Source landscape and data profiling

<!-- Guidance: Describe each source and summarise profiling. Profile real extracts, not documentation, and profile early (before mapping is signed). Questions: how many records fail each basic rule, how many duplicates, which fields are free text that the target needs as codes? Pitfall: profiling a sample from a test copy that is months old. -->

### 3.1 Source systems

| Source ID | System | Technology | Access method | Data owner | Known issues |
|---|---|---|---|---|---|
| SRC-01 *(Example)* | Legacy ERP | Relational database, vendor-specific schema | Read-only replica, extract views | [@it-legacy-lead] | Free-text addresses; customer and vendor share one table |
| SRC-02 *(Example)* | Regional AP spreadsheet | Spreadsheet files | Controlled upload to staging | [@ap-regional-lead] | Manual entry; no unique key |
| [SRC-NN] | [System] | [Technology] | [Method] | [@owner] | [Issues] |

### 3.2 Profiling results

Run column profiling (null rate, distinct count, pattern frequency,
min and max, value distribution) and cross-record profiling (duplicates,
orphans, referential gaps) on a full extract.

| Finding ID | Object | Field or check | Result | Impact on target | Action |
|---|---|---|---|---|---|
| PRF-001 *(Example)* | MO-001 | Tax registration number | 6.8% empty, 2.1% invalid format | Mandatory for invoicing in two countries | Cleansing rules DQ-003 and DQ-005 |
| PRF-002 *(Example)* | MO-001 | Probable duplicates by name, postcode and tax number | 1,915 candidate pairs | Duplicate credit exposure | Match and merge DQ-001 |
| PRF-003 *(Example)* | MO-003 | Unit of measure free text | 214 distinct values for 38 target units | Load failure | Value map MAP-012 |
| PRF-004 *(Example)* | MO-004 | Items without a valid customer | 41 items | Reject at load | Fix customer link at source, DQ-006 |
| [PRF-NNN] | [Object] | [Check] | [Result] | [Impact] | [Action] |

## 4. Data quality and cleansing

<!-- Guidance: Turn profiling into rules with owners and deadlines, measure them every extract and stop cleansing that will not finish in time by agreeing a fallback (default value, exclusion or post-go-live fix). Pitfall: an unlimited cleansing backlog owned by "the business" with no names. -->

### 4.1 Quality dimensions used

Use a small, stable set of dimensions so that every rule can be
classified and reported consistently. This strategy uses
completeness (required values present), validity (values conform to
format and domain), accuracy (values agree with the real-world fact or
an authoritative source), consistency (no contradiction across fields
and systems), uniqueness (one record per real entity) and timeliness
(values current at the cutover date). Define each in your own data
quality policy if it already exists, and reuse that wording.

### 4.2 Cleansing rules

| Rule ID | Object | Dimension | Rule | Where fixed | Owner | Due | Fallback if not fixed |
|---|---|---|---|---|---|---|---|
| DQ-001 *(Example)* | MO-001 | Uniqueness | Merge confirmed duplicates; keep the record with most recent activity as survivor | Source, by data stewards | [@sales-ops-lead] | Before mock 2 | Load both and block the loser for new orders |
| DQ-002 *(Example)* | MO-001, MO-002 | Validity | Postcodes match the national format for the country | Transformation, rule-based | [@migration-dev] | Mock 1 | Reject record to exception list |
| DQ-003 *(Example)* | MO-001 | Completeness | Tax number present for customers in [countries] | Source, by finance | [@ar-lead] | Before mock 3 | Exclude from invoicing until completed; flagged in target |
| DQ-004 *(Example)* | MO-003 | Consistency | Base unit of measure agrees with the unit on open orders | Source | [@supply-chain-lead] | Before mock 2 | Reject open order line |
| DQ-005 *(Example)* | MO-001 | Validity | Tax number matches the national format of the customer's country, with spaces and separators removed | Source for invalid values; transformation for spaces and separators | [@ar-lead] | Before mock 3 | Reject record to exception list; open items of the customer are held |
| DQ-006 *(Example)* | MO-004 | Consistency | Every open receivable item references a customer that is in scope of MO-001 | Source, by accounts receivable | [@ar-lead] | Before mock 2 | Post to a suspense customer with controller approval, listed by value |
| [DQ-NNN] | [Object] | [Dimension] | [Rule] | [Source / Transformation / Target] | [@owner] | [Date] | [Fallback] |

### 4.3 Quality metrics

Report these per object at every extract and every mock load:

| Metric | Definition | Target at final mock *(Example)* |
|---|---|---|
| Rule pass rate | Records passing all rules for the object divided by in-scope records | 99.5% or higher for master data; 100% for financial open items |
| Open cleansing items | Records listed on the cleansing worklist not yet fixed at source | Trending to zero; none on day-one critical fields |
| Duplicate rate | Confirmed duplicate records divided by in-scope records | Below 0.5% |
| Exception records | Records rejected by validation in the last load | Below 0.1% per object |

## 5. Mapping and transformation

<!-- Guidance: Specify field mapping, value mapping and transformation rules precisely enough for a developer to build and a tester to check, and get each mapping signed by the business owner. Pitfall: mapping "by name" when the same label means different things in source and target. -->

### 5.1 Field mapping specification

Keep the full mapping per object in a controlled workbook or the
migration tool. Summarise the rules that need a decision here.

| Map ID | Object | Target field | Source field(s) | Rule type | Rule | Mandatory in target | Signed by |
|---|---|---|---|---|---|---|---|
| MAP-001 *(Example)* | MO-001 | Customer number | Legacy customer ID | Direct with prefix | Keep legacy ID in an external reference field; new number from target range | Yes | [@sales-ops-lead] |
| MAP-002 *(Example)* | MO-001 | Payment terms | Terms code | Value map | Crosswalk table VM-004; unmapped values go to exceptions | Yes | [@ar-lead] |
| MAP-007 *(Example)* | MO-001 | Address lines | Address text 1 to 3 | Parse and split | Address service parses street, house number and city; low-confidence results to review | Yes | [@sales-ops-lead] |
| MAP-012 *(Example)* | MO-003 | Base unit | Unit text | Value map | 214 legacy values mapped to 38 target units, crosswalk VM-012 | Yes | [@supply-chain-lead] |
| MAP-020 *(Example)* | MO-004 | Document date | Invoice date | Direct | Keep original date; posting date set to cutover date | Yes | [@finance-controller] |
| [MAP-NNN] | [Object] | [Field] | [Source] | [Direct / Value map / Derive / Default / Constant] | [Rule] | [Yes / No] | [@owner] |

### 5.2 Value mapping and key management

- Keep every crosswalk (VM-NNN) as a versioned table with an owner,
  an effective date and a rule for unmapped values.
- Store the legacy key in the target (external reference field or a
  key-mapping table) so that reconciliation, audits and support can
  trace each record back to its source.
- Decide number ranges early. Either the target generates new numbers
  and keeps the legacy number as a reference, or legacy numbers are
  reused in a reserved range. Reuse simplifies user transition but
  constrains the target range forever.

### 5.3 Transformation rules that need care

| Topic | Decision to record |
|---|---|
| Currency and rounding | Rounding method and where it is applied, so that totals reconcile to the cent |
| Dates and time zones | Which dates are kept, which are reset to cutover, and how time zones are normalised |
| Organisational remapping | How legacy companies, plants or branches map to the new structure, including splits and merges |
| Status values | How in-progress statuses map to target statuses that may have different steps |
| Free text and attachments | What is kept, truncated or moved to a document store, with length limits |

## 6. Migration approach

<!-- Guidance: Choose and justify the approach. Questions: can the business run two systems for the same process? How long a freeze can it tolerate? Do interfaces allow partial cut-over? Pitfall: choosing phased because it sounds safer without costing the temporary interfaces and dual maintenance it needs. -->

### 6.1 Options

| Approach | Description | Fits when | Main cost or risk |
|---|---|---|---|
| Big bang | All objects for all users move in one cutover window | Processes are tightly integrated; a short freeze is acceptable; one go-live date is required (for example a financial year start) | Large single event; rollback is hard after transactions start |
| Phased by business unit, region or process | Objects move in several cutovers, each for part of the organisation | Units are loosely coupled; capacity to support repeated go-lives exists | Temporary interfaces between old and new systems; master data maintained in two places |
| Trickle (incremental with parallel run) | Initial load followed by continuous delta synchronisation until switch | Downtime must be near zero; change data capture is available on the source | Complex synchronisation and conflict handling; long dual running |

### 6.2 Decision

| Criterion | Weight | Big bang | Phased | Trickle |
|---|---|---|---|---|
| Business tolerance for freeze (48 h available) *(Example)* | 3 | 4 | 4 | 5 |
| Integration between processes *(Example)* | 3 | 5 | 2 | 3 |
| Cost of temporary interfaces *(Example)* | 2 | 5 | 2 | 2 |
| Rollback feasibility *(Example)* | 2 | 3 | 4 | 3 |
| Team capacity for repeated cutovers *(Example)* | 2 | 4 | 2 | 3 |
| Weighted total *(Example)* | | 51 | 34 | 40 |

*Example:* Each weighted total is the sum of weight times score on a
1 to 5 scale. Big bang: 12 + 15 + 10 + 6 + 8 = 51. Phased: 12 + 6 + 4 +
8 + 4 = 34. Trickle: 15 + 9 + 4 + 6 + 6 = 40. The decision is **big
bang** over a 48-hour weekend window, with general ledger history loaded
as period balances in advance. Scores are judgements: record who scored
and why, and test whether the choice survives a change of one weight.

[Record the decision as an ADR, using the Architecture Decision Log
(`architecture/architecture-decision-log`), and paste its ID here.]

## 7. Architecture and tooling

<!-- Guidance: Show the path data takes from source to target and the tools at each step. Questions: where is data staged, where are rules executed, how are errors returned, and who can see staged personal data? Pitfall: spreadsheets as an untracked transformation layer. -->

```mermaid
flowchart LR
  S1[(Legacy ERP<br/>read-only replica)] --> X[Extract jobs]
  S2[Regional spreadsheets] --> U[Controlled upload]
  X --> ST[(Staging: raw zone)]
  U --> ST
  ST --> V[Validate and cleanse rules DQ-nnn]
  V --> T[Transform and map MAP-nnn, VM-nnn]
  V -->|fails| EX[(Exception store)]
  T --> PL[(Staging: load-ready zone)]
  PL --> L[Load via target APIs or migration tool]
  L --> TG[(Target system)]
  L -->|rejected| EX
  TG --> R[Reconciliation extracts]
  ST --> R
  R --> RPT[Reconciliation report]
  EX --> WL[Cleansing worklists for data owners]
```

| Component | Choice | Reason | Alternatives considered |
|---|---|---|---|
| Staging store | *Example:* Dedicated database in the programme's restricted environment | Repeatable runs, SQL-based reconciliation, access control | Target's own staging tables only |
| Transformation | *Example:* ETL tool with rules in version control | Re-runnable, testable, logged | Hand-written scripts per object |
| Load mechanism | *Example:* Target's supported bulk APIs and the vendor's migration tool | Target validations apply; vendor support | Direct database inserts (rejected: bypass business logic) |
| Reconciliation | *Example:* SQL queries on staging plus target extract reports | Independent of the load tool | Load tool's own success counts only (rejected: not independent) |
| Exception handling | *Example:* Exception store with worklists per owner | Rejected records are visible and assigned | Email of error files |

Performance planning: measure throughput per object in mock 1 and compute the critical path of the load sequence. *Example:* the customer master loads at about 6,000 records per hour through the API, so 48,210 records need about 8 hours on one thread; four parallel threads bring that to about 2 hours if the target accepts the concurrency.

## 8. Load sequence and dependencies

<!-- Guidance: Order objects so that every reference exists before it is used, and mark the critical path that sets the cutover duration. Pitfall: discovering in the production load that open orders need price conditions that load later. -->

```mermaid
flowchart TD
  C0[Configuration and reference data in target] --> M1[MO-001 Customer master]
  C0 --> M2[MO-002 Vendor master]
  C0 --> M3[MO-003 Material master]
  M1 --> M7[MO-007 Price conditions]
  M3 --> M7
  M1 --> O4[MO-004 Open receivable items]
  M2 --> O8[MO-008 Open payable items]
  M7 --> O5[MO-005 Open sales orders]
  C0 --> G6[MO-006 General ledger balances]
  O4 --> F[Financial reconciliation and sign-off]
  O8 --> F
  G6 --> F
```

| Step | Object | Depends on | Duration in last mock | On critical path | Pre-loadable before freeze |
|---|---|---|---|---|---|
| 1 *(Example)* | MO-001 Customer master | Configuration | 2.5 h | No (0.5 h float; runs in parallel with MO-003) | Yes, with delta at cutover |
| 2 *(Example)* | MO-003 Material master | Configuration | 3.0 h | Yes | Yes, with delta at cutover |
| 3 *(Example)* | MO-007 Price conditions | MO-001, MO-003 | 1.5 h | Yes | No |
| 4 *(Example)* | MO-005 Open sales orders | MO-007 | 2.0 h | Yes | No |
| 5 *(Example)* | MO-004 Open receivable items | MO-001 | 1.0 h | No | No |
| [n] | [Object] | [Dependencies] | [Hours] | [Yes / No] | [Yes / No] |

*Example:* the critical path is max(2.5, 3.0) + 1.5 + 2.0 = 6.5 hours (material master, price conditions, open orders). Open receivables (1.0 h) also run in parallel after MO-001 and have float.

Pre-loading master data before the freeze and loading only the changes
(delta) during cutover shortens the window but requires change capture
on the source and a delta reconciliation. Decide per object.

## 9. Historical data, archiving and retention

<!-- Guidance: Decide what history moves, what is archived and how archived data is retrieved. Check the retention schedule and legal holds first. Pitfall: migrating ten years of closed transactions because nobody wanted to decide. -->

| Data set | Decision | Reason | Where kept | Retrieval method | Retention until |
|---|---|---|---|---|---|
| *Example:* Closed sales invoices older than 24 months | Archive, not migrated | Not needed for day-one processes | Read-only archive store with search | Query by customer and document number | 10 years after year end (per retention schedule) |
| *Example:* General ledger history, prior two years | Migrate as period balances | Comparative reporting in target | Target | Standard reports | Per schedule |
| *Example:* Legacy system as a whole | Decommission 12 months after go-live | Audit queries answered from archive | Archive | Archive service | Per schedule |
| [Data set] | [Migrate / Archive / Discard] | [Reason] | [Location] | [Method] | [Date] |

Check every decision against the records retention schedule, using the Records Retention Schedule (`compliance/iso-15489-records-schedule`) where one exists, and against any legal hold. Discarding data is a business decision signed by its owner, never a side effect of an in-scope rule.

## 10. Mock loads and rehearsals

<!-- Guidance: Plan a series of full loads into production-like environments, each with entry and exit criteria, and make the last one a timed dress rehearsal of the cutover. Pitfall: mock loads that load a subset or skip reconciliation, so the first full, reconciled load is the production one. -->

| Mock ID | Purpose | Data | Environment | Entry criteria | Exit criteria |
|---|---|---|---|---|---|
| MCK-01 *(Example)* | Prove pipeline end to end; measure throughput | Full extract, all objects | System test | Mapping signed for all objects; configuration complete for master data | All objects loaded; defect list triaged; reconciliation report issued |
| MCK-02 *(Example)* | Data for integration and user acceptance testing | Fresh full extract | Acceptance test | MCK-01 critical defects closed; cleansing DQ-001 and DQ-004 done | Rejection rate below 0.5%; business spot checks passed |
| MCK-03 *(Example)* | Timed dress rehearsal of the cutover data steps | Fresh full extract at the planned cutover time of day | Pre-production, sized like production | Cutover plan v1.0; all tolerances agreed | Duration within window; all objects within tolerance; owners sign |
| MCK-04 *(Example, contingent)* | Rerun after a missed MCK-03 exit | Fresh full extract | Pre-production | MCK-03 report shows which objects failed; fixes deployed; steering group approval | Same as MCK-03 for the objects in scope of the rerun |
| [MCK-NN] | [Purpose] | [Data] | [Environment] | [Criteria] | [Criteria] |

Track the same metrics in each mock (records rejected, unaccounted records, load duration, open defects) so the trend is visible to the steering group. A fourth mock (MCK-04) is run only if MCK-03 misses its exit criteria; budget for it in the plan rather than hoping it is not needed. The steering group may limit MCK-04 to the failed objects and the objects that depend on them (section 8), carrying the other objects' results forward from MCK-03, but the timed rehearsal must then be repeated for any step whose duration changes.

## 11. Reconciliation design

<!-- Guidance: Define how each load is proved complete and correct, independently of the load tool. The results of each run go into a separate reconciliation report. Pitfall: counting records but not reconciling money, or reconciling totals that were computed by the same code that loaded them. -->

### 11.1 Reconciliation levels

| Level | Check | Applies to | Evidence |
|---|---|---|---|
| L1 Record counts | Extracted equals excluded by rule plus loaded plus rejected, with zero unaccounted | Every object | Count queries on staging and target |
| L2 Control totals | Sums of key amounts and quantities agree between source and target, after explained differences | Financial and quantity objects | Totals by company, currency and account |
| L3 Field-level comparison | A sample, or the full population for small objects, compared field by field after applying the mapping | Every object | Comparison output with mismatch list |
| L4 Business validation | Owners check real records and run day-one reports and transactions | Every object | Signed checklist and screenshots |

### 11.2 Tolerances

| Object type | Unaccounted records | Rejected records | Control total variance | Field mismatches in sample |
|---|---|---|---|---|
| Master data *(Example)* | 0 | 0.1% or lower, all listed with an owner | Not applicable | 0 on critical fields; 0.5% or lower of field comparisons on others |
| Open financial items *(Example)* | 0 | 0 at production load; any rejected item listed with value | Unexplained variance USD 0.00 | 0 |
| Open orders *(Example)* | 0 | 0.1% or lower | Order value unexplained variance USD 0.00 | 0 on quantities and prices |
| [Type] | [Tolerance] | [Tolerance] | [Tolerance] | [Tolerance] |

Critical fields are those a day-one process cannot run without. List them per object in the mapping workbook and mark them in the field mapping (section 5.1). *Example:* for MO-001 the critical fields are customer number, tax number, payment terms and credit limit.

For sampled comparisons, a sample of $n$ records with no mismatches
gives an approximate 95% upper bound of $3/n$ on the true mismatch rate
(the rule of three). *Example:* 500 sampled customer records with zero
mismatches bound the mismatch rate below about 0.6%. Use full-population
comparison wherever the volume allows it.

Report each load with the Data Migration Reconciliation Report
(`project/data-migration-reconciliation`).

## 12. Cutover data steps

<!-- Guidance: List the data-related steps of the cutover in order, with timings from the last mock. The full cutover, including technical, people and communication steps, lives in the cutover plan. Pitfall: no defined point after which no more legacy postings are accepted. -->

| Step ID | Step | Start (relative) | Duration | Owner | Go or no-go gate |
|---|---|---|---|---|---|
| CUT-D01 *(Example)* | Legacy posting freeze begins; users locked out of legacy transactions | T-0 h | n/a | [@cutover-manager] | Freeze confirmed by process owners |
| CUT-D02 *(Example)* | Final extract and extract counts recorded | T+0.5 h | 2 h | [@migration-dev] | Counts match legacy reports |
| CUT-D03 *(Example)* | Delta load of master data, then open items and orders | T+2.5 h | 14 h | [@migration-dev] | Each object within tolerance |
| CUT-D04 *(Example)* | Financial reconciliation and controller sign-off | T+16.5 h | 3.5 h | [@finance-controller] | Unexplained variance zero |
| CUT-D05 *(Example)* | Business validation of day-one transactions | T+20 h | 4 h | [@business-data-owners] | All owners sign |
| CUT-D06 *(Example)* | Go decision; legacy set to read-only | T+24 h | n/a | [@programme-sponsor] | Section 13 fallback no longer selected |
| [CUT-DNN] | [Step] | [T+h] | [h] | [@owner] | [Gate] |

Embed these steps in the Cutover Plan (`project/cutover-plan`) and the
go or no-go decision in the Go-Live Readiness Review
(`project/go-live-readiness-review`).

## 13. Fallback and rollback

<!-- Guidance: Define the point of no return, what fallback means before and after it, and how data created in the target after go-live would be handled. Pitfall: a rollback plan that assumes no transactions were posted in the target. -->

| Situation | Fallback | Data impact | Decision owner |
|---|---|---|---|
| *Example:* Load fails tolerance before go decision (before CUT-D06) | Abandon cutover; reopen legacy; target environment reset to pre-load snapshot | None; legacy remains master | [@programme-sponsor] |
| *Example:* Severe issue found within first 2 business days | Fix forward in target; manual workaround for affected process | Corrections posted as adjustments with audit trail | [@programme-sponsor] |
| *Example:* Target unusable after go-live | Reopen legacy for critical processes; re-key target transactions into legacy from the target audit report | Dual keying; reconciliation of postings made in both | [@programme-sponsor] |
| [Situation] | [Fallback] | [Impact] | [@owner] |

Point of no return: [the first external transaction, such as an invoice
issued, a payment run or an electronic filing, created from the target].
Keep a snapshot of the target before load and a full backup of the
legacy database at freeze; both are retained until [date].

## 14. Security and privacy of migration data

<!-- Guidance: Migration copies contain full production data in new places. Control where it goes, who sees it and when it is destroyed. Pitfall: production personal data in test environments with test-level access control. -->

| Control ID | Control | Applies to |
|---|---|---|
| DMS-SEC-001 *(Example)* | Staging stores sit in a restricted environment with the same classification as production | Staging, exception store |
| DMS-SEC-002 *(Example)* | Named access only; access reviewed before each mock and removed after go-live | Migration team, data owners |
| DMS-SEC-003 *(Example)* | Encryption in transit and at rest for extracts, files and staging | All copies |
| DMS-SEC-004 *(Example)* | Personal data masked or minimised in environments where full values are not needed for testing | System test, training |
| DMS-SEC-005 *(Example)* | Exception worklists show only the fields needed to fix the record | Worklists sent to data owners |
| DMS-SEC-006 *(Example)* | Extracts, staging data and worklists securely deleted by [date] after go-live, with a deletion record | All copies |
| [DMS-SEC-NNN] | [Control] | [Scope] |

Where personal data is processed, confirm the lawful basis, transfers and retention with the data protection officer and record the migration as a processing activity where required, using the DPIA (`compliance/dpia`) and the Record of Processing Activities (`compliance/gdpr-ropa`). Under the GDPR, Article 5 (principles, including storage limitation) and Article 32 (security of processing) are the usual reference points; check the current text with your privacy team.

## 15. Roles and governance

<!-- Guidance: Name who decides, who does and who signs. Separate the people who build loads from those who reconcile and accept them. Pitfall: the migration team signing off its own results. -->

| Activity | Data migration lead | Migration developers | Business data owner | Data stewards | Finance controller | Solution architect | Cutover manager |
|---|---|---|---|---|---|---|---|
| Object inventory and scope | A | C | R | C | C | C | I |
| Profiling and cleansing rules | A | R | C | R | C | I | I |
| Mapping sign-off | C | R | A | C | C | C | I |
| Build and run loads | A | R | I | I | I | C | I |
| Reconciliation L1 to L3, financial objects | C | C | C | R | A | I | I |
| Reconciliation L1 to L3, other objects | C | C | A | R | C | I | I |
| Business validation L4 | C | I | A | R | R | I | I |
| Cutover data steps | R | R | C | C | C | I | A |

R: responsible, A: accountable, C: consulted, I: informed.

Governance cadence: weekly data migration stand-up with the defect and
cleansing burn-down; status to the programme steering group at each
mock exit; a data migration go or no-go input to the readiness review.

## 16. Risks, assumptions and traceability

<!-- Guidance: Keep migration risks visible and owned, and trace objects to rules, tests and reconciliation results. Log risks in the programme RAID log as well (`project/raid-log`). Pitfall: risks without dates by which mitigation must have worked. -->

### 16.1 Risks

| Risk ID | Risk | Likelihood | Impact | Mitigation | Owner | Mitigation due |
|---|---|---|---|---|---|---|
| DMR-001 *(Example)* | Cleansing at source not finished before final extract | High | High | Fallback per rule in section 4.2; weekly burn-down to sponsor | [@data-migration-lead] | Before MCK-03 |
| DMR-002 *(Example)* | Load duration exceeds cutover window | Medium | High | Pre-load master data; parallel threads; measured in MCK-03 | [@migration-dev] | MCK-03 |
| DMR-003 *(Example)* | Target configuration changes after mapping sign-off | Medium | Medium | Change control includes a data migration impact check | [@solution-architect] | Ongoing |
| DMR-004 *(Example)* | Source system changes during the programme | Low | Medium | Source change freeze for the extract tables after MCK-02 | [@it-legacy-lead] | MCK-02 |
| [DMR-NNN] | [Risk] | [L] | [I] | [Mitigation] | [@owner] | [Date] |

### 16.2 Assumptions

- *Example:* The target vendor's bulk interfaces support the volumes in
  section 2 at the throughput measured in mock 1.
- *Example:* Business data owners have [number] days per week allocated
  to cleansing and validation until go-live.
- [Assumption]

### 16.3 Traceability

| Object | Cleansing rules | Mapping | Load step | Reconciliation checks | Test cases | Sign-off |
|---|---|---|---|---|---|---|
| MO-001 *(Example)* | DQ-001, DQ-002, DQ-003, DQ-005 | MAP-001, MAP-002, MAP-007 | 1 | L1, L3, L4 | [TC-DM-001 to TC-DM-012] | [@sales-ops-lead], YYYY-MM-DD |
| MO-004 *(Example)* | DQ-006 | MAP-020 | 5 | L1, L2, L3, L4 | [TC-DM-040 to TC-DM-046] | [@ar-lead], [@finance-controller] |
| [MO-NNN] | [Rules] | [Maps] | [Step] | [Checks] | [Tests] | [Owner, date] |

## 17. Glossary and references

<!-- Guidance: Define terms that business and IT use differently, and list sources with the date you checked them. -->

### 17.1 Glossary

| Term | Meaning |
|---|---|
| Migration object | A business entity extracted, transformed, loaded and signed off as one unit |
| Mock load | A full rehearsal load into a non-production environment |
| Crosswalk | A value mapping table from legacy codes to target codes |
| Control total | A sum of an amount or quantity used to prove that a load is complete and correct |
| Unaccounted record | A record that is neither loaded, rejected nor excluded by an agreed rule |
| Delta load | A load of only the records created or changed since a previous extract |
| Point of no return | The moment after which returning to the legacy system costs more than fixing forward |
| Survivor | The record kept when duplicates are merged |

### 17.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| DAMA-DMBOK: Data Management Body of Knowledge, 2nd Edition Revised, DAMA International, dama.org | Revised edition released March 2024; checked 2026-10-23 | Knowledge area structure: data integration and interoperability, data quality, reference and master data, metadata |
| SAP Activate methodology, SAP Roadmap Viewer, go.support.sap.com/roadmapviewer | Phases Discover, Prepare, Explore, Realize, Deploy, Run; check current roadmap | Where migration design, mock loads and production load fall in a packaged ERP project |
| Microsoft Dynamics 365 implementation guide, data migration chapter, and the Success by Design training module, learn.microsoft.com | Checked 2026-10-23 | Distinction between configuration and migrated data; migration strategy workshop |
| Regulation (EU) 2016/679 (GDPR), Articles 5 and 32, eur-lex.europa.eu | Consolidated text | Privacy of migration copies |
| [Internal data quality policy] | [Version] | [Use] |

## Standard and licence note

Structure aligned with the knowledge areas of DAMA-DMBOK 2nd Edition
Revised (DAMA International, March 2024), with the phase names of SAP
Activate and with the data migration topics in the Microsoft Dynamics
365 implementation guidance. DMBOK is a copyrighted body of knowledge:
only knowledge area names are used and no text, definitions, diagrams
or tables are reproduced. SAP, SAP Activate, Microsoft and Dynamics 365
are trademarks of their owners; this template is not affiliated with or
endorsed by them. This template is original text written for this
collection; the quality dimensions, tolerances and numbers are examples,
not normative values. Check the current official versions before use.
Template licence: MIT.