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.

Document control

Approvals

Revision history

Contents

1. Introduction and scope
2. Migration object inventory
3. Source landscape and data profiling
4. Data quality and cleansing
5. Mapping and transformation
6. Migration approach
7. Architecture and tooling
8. Load sequence and dependencies
9. Historical data, archiving and retention
10. Mock loads and rehearsals
11. Reconciliation design
12. Cutover data steps
13. Fallback and rollback
14. Security and privacy of migration data
15. Roles and governance
16. Risks, assumptions and traceability
17. Glossary and references

1. Introduction and scope

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

1.3 Scope

1.4 Principles

2. Migration object inventory

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.

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

3.1 Source systems

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.

4. Data quality and cleansing

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

4.3 Quality metrics

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

5. Mapping and transformation

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.

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

6. Migration approach

6.1 Options

6.2 Decision

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

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

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

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

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

11.1 Reconciliation levels

11.2 Tolerances

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

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

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

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

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

16.1 Risks

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

17. Glossary and references

17.1 Glossary

17.2 References

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.