Data Migrations
What Is a Data Migration in ArchRepo?
A Data Migration describes how data is moved from a source system to the target solution — the mapping from As-Is data structures to the To-Be data model, alongside the plan for testing, validating, and rolling back the migration if needed.
Data Migrations sit across both the Data and Transition concerns. They are a core part of the cutover plan: without a clearly defined and approved migration, the go-live decision cannot be made with confidence.
Examples of Data Migrations:
- “Legacy customer records migrated from the old CRM to the new platform”
- “Open purchase orders extracted from the ERP and loaded into the new procurement system”
- “Historical invoice data archived from the on-premises finance system to cloud storage”
- “Product catalogue migrated from the legacy catalogue tool into the new PIM system”
Data Migrations are referenced using the prefix DMG- — DMG-1, DMG-2, and so on.
Data Mapping
Each Data Migration has a Data Mapping tab where source-to-target field mappings are recorded. The data mapping captures:
- The source field name, data type, and system of origin
- The target field name and data type in the new solution
- Any transformation, cleansing, or derivation logic applied during migration
Completing the data mapping early — even at a high level — surfaces data quality issues, missing fields, and transformation complexity before development or cutover begins. It also provides the basis for writing pre- and post-migration validation checks.
Migration Lifecycle
Four dedicated fields capture the operational plan for running the migration safely:
| Field | What it captures |
|---|---|
| Testing Strategy | How the migration is tested before go-live — dry runs, data reconciliation queries, record count checks, sampling and spot checks |
| Pre-Migration Checks | The go/no-go gates that must pass before the migration begins — source data quality checks, system availability, dependency readiness |
| Post-Migration Checks | The validation steps run after the migration completes — record counts, reconciliation totals, business sign-off queries, referential integrity checks |
| Rollback Strategy | What to do if the migration fails — how to restore the pre-migration state, which systems need to be reverted, and what the trigger conditions are for invoking rollback |
Documenting these fields makes the migration a plannable, reviewable artefact — not just a technical task. Pre- and post-migration checks become the basis for acceptance criteria; the rollback strategy is evidence that the risk of migration failure has been considered and mitigated.
Approval
Data Migrations support formal approval. Before a migration is executed — particularly in a production environment — it should be reviewed and signed off by the relevant stakeholders: the data owner, the business lead, and the technical team. Use the approval workflow to record that this review has taken place.
Formal approval provides the go-live gate for migration: a migration that has not been approved should not be executed in production.
Data Access
Data Migrations use two distinct relationship types to Data Sets, reflecting the direction of data movement:
| Relationship | What it means |
|---|---|
| Has Read Access | The migration reads from this Data Set (the source) |
| Has Write Access | The migration writes to this Data Set (the target) |
This distinction makes the access pattern explicit and supports security and access control review — ensuring that the migration process has only the access it needs.
Transition Concern
Data Migrations are part of the transition/cutover plan and should be linked to the Transition Requirements that they fulfil. This traceability ensures that every transition requirement has at least one migration (or other transition activity) addressing it.
Fields Reference
See Data Migration Fields for a description of each field and guidance on what to record.