ERP Data Migration Checklist: Mapping, Reconciliation and Sign-Off
Plan ERP data migration with record scope, mapping, exception handling, trial imports, reconciliation and sign-off. Includes a buyer-ready verification register.
ERP data migration should be accepted when the agreed records are complete, correctly mapped and usable in the destination workflow, with unresolved exceptions documented. A successful import job does not establish that opening stock, outstanding items or transaction relationships are correct. Define verification and ownership before moving the final data.
Let’s plan your ERP data migration.
Talk through your requirements with Drema. We’ll help you clarify the scope, explore the trade-offs and plan the next steps for your project.
Decide what moves and what remains accessible
Identify source systems, record owners and the business purpose of each migrated dataset. Separate master data, opening positions, open transactions and historical records. Decide which history needs active migration and which may remain accessible through an agreed archive or previous system.
Have the appropriate owners determine retention and access obligations. Do not treat a migration scope decision as permission to delete records or change their authorised use.
Create a source-to-target mapping register
| Field | What to document |
|---|---|
| Source | System, record type and extraction boundary |
| Destination | Record type and required relationship |
| Identity | Source key, destination key and cross-reference |
| Transformation | Format, unit, date or value conversion |
| Validation | Required fields and accepted value rules |
| Exception | What happens when a record cannot be mapped safely |
| Owner | Person authorised to resolve the rule or data problem |
Do not silently replace missing values with convenient defaults. An unknown credit term or unit conversion is a business question. Record the decision and retain the provenance needed to explain the result.
Clean records without losing traceability
Duplicate customers, inconsistent item units and obsolete identifiers can affect the destination workflow. Assign a data owner to approve cleaning and matching rules. Keep a cross-reference where records are merged or rekeyed.
Use authorised data in an appropriate environment. Early demonstrations can often use synthetic records. Confirm the controls needed for production extracts and temporary copies with the responsible teams.
Verify completeness and correctness separately
An import can contain the expected number of records while mapping values incorrectly. Conversely, a set of correct samples does not establish that all expected records were included.
Plan both checks:
| Check | Question answered |
|---|---|
| Record counts by agreed category | Is the expected population accounted for? |
| Key uniqueness and relationships | Are records identifiable and connected correctly? |
| Relevant operational balances | Do quantities or outstanding positions reconcile? |
| Representative record review | Are mapped values usable and meaningful? |
| Destination workflow test | Can authorised users perform the intended task? |
| Exception register | What remains unresolved, and who will decide it? |
Choose the balances and tolerances with the relevant operational or finance owners. A generic percentage tolerance should not authorise unexplained differences in a material business record.
Use an exception ledger
For every rejected or disputed record, store a source reference, reason, proposed resolution, decision owner and verification result. Keep rejected records visible in completeness reporting; do not remove them from the expected population simply to make a reconciliation pass.
For a fictional example, suppose the scope includes 1,000 item records and the trial import accepts 980. The remaining 20 belong in the exception register. Reporting “980 successful imports” is accurate, but it is not sign-off for the full 1,000-record scope.
The numbers are illustrative and do not describe a real migration. The principle is to account for the included population and resolve or explicitly approve the treatment of every exception.
Repeat the checks for final cutover data
Agree the extraction point, changes after extraction and the final import sequence. A trial migration establishes evidence for that trial; final records still need the agreed verification.
Record the exact dataset or extraction reference used at sign-off. Include the reconciliation outputs, accepted exceptions and responsible approvals. Avoid a generic “migration tested” status with no link to the accepted population.
Plan recovery across systems
Define what staff do if final verification fails. Consider transactions already created or transmitted after the transition begins. Restoring one system may not reverse changes in another.
Have the delivery and business owners agree rollback triggers, responsibilities and communication. Rehearse the relevant steps in the agreed test environment rather than assuming a backup is sufficient proof of recoverability.
See Drema's ERP migration service for a scoping discussion, and connect the migration to the actual ERP workflow being introduced.
Questions buyers ask
Should we migrate all historical transactions?
Decide from operational needs, access and applicable obligations with the responsible reviewers. Compare active migration with an agreed accessible-history arrangement. Do not assume one choice fits every business.
Who fixes source-data problems?
Assign responsibility explicitly. A supplier can build import and validation tooling, while business decisions about ambiguous records need an authorised owner.
Can we sign off from a few screenshots?
Screenshots can support particular checks. Full acceptance should use the agreed completeness, correctness, workflow and exception evidence for the actual migration scope.
Prepare the migration brief
List the source datasets, included records, important balances and record owners. Bring sample structures and known exceptions. Agree how the destination will be verified before accepting an implementation estimate or a cutover date.