Practical guides · Data migration
ERP data migration checklist for a controlled go-live
An ERP data migration checklist keeps go-live under control by moving only the records your business can trust. Name an owner for each data set, agree how old fields map to the new ERP, run trial loads and reconcile the results before anyone approves the change to the new system.
Related reading: the VisionONE ERP overview, the ERP cost guide and the ERP vendor evaluation checklist.
Move the records your business can trust. Plan the owners, mappings, trial loads and reconciliations before approving the change to a new ERP.
Define the source
Agree datasets, ownership and cut-off.
Prove the transfer
Test mappings and account for every row.
Approve the evidence
Reconcile, test and authorise cutover.
- 1
Name owners and define datasets
List entities, systems, record types and the cut-off date. Decide which master data, opening balances, open items and historical records belong in the first release. Keep a read-only source extract with a version and extraction time.
Owner: Project lead and dataset owners
Evidence: Approved scope, source register and record counts.
Complete when: Every dataset has an owner, a destination and an agreed inclusion rule.
- 2
Clean and deduplicate source records
Find duplicate customers, suppliers and items. Resolve missing required values and inconsistent dates, currencies and units. Keep the original IDs and a record of approved merges or exclusions.
Owner: Business data owners
Evidence: Cleanup log and approved exception list.
Complete when: Known duplicates and invalid records are resolved or explicitly handled before loading.
- 3
Map fields, codes and tax data
Document source-to-target fields, required values, formats and transformation rules. Agree account, item, branch, unit and tax-code mappings with the relevant owner. Preserve identifiers as text where leading zeros matter.
Owner: Functional consultant with finance and operations
Evidence: Versioned mapping and sample transformed records.
Complete when: Owners approve the mappings and representative outputs; unsupported values are flagged.
- 4
Run trial loads and handle errors
Load into a test environment in the agreed dependency order. Keep source, accepted and rejected counts for the same extract. Correct the cause of each rejection, then rerun using the agreed method for preventing duplicates.
Owner: Migration lead and technical team
Evidence: Load logs, rejected-row report and rerun results.
Complete when: Every source record is accounted for and repeat loads do not duplicate records.
- 5
Reconcile balances, stock and payroll
Compare source and target at the same cut-off, currency and scope. Match the trial balance and subledgers, stock by item and location, and payroll opening or year-to-date values where in scope. Investigate differences at record level.
Owner: Finance, warehouse and payroll owners
Evidence: Signed reconciliation with explanations for each difference.
Complete when: Control totals and detailed records meet the agreed acceptance criteria.
- 6
Test users, backups and cutover
Ask users to run real scenarios with migrated records. Test permissions, opening balances and exceptions. Confirm a restorable backup, final extraction or delta-load plan, posting freeze, rollback trigger and named decision-maker.
Owner: Business testers, IT and project lead
Evidence: User test results, restore-test evidence and timed cutover plan.
Complete when: Critical defects are resolved and the go/no-go owners accept the cutover evidence.
- 7
Sign off and check after go-live
Record formal approval before release. After cutover, reconcile the final load, review first transactions and monitor exceptions. Retain source extracts, logs and access-controlled archives according to the organisation’s approved policy.
Owner: Business sponsor and accountable dataset owners
Evidence: Sign-off record, final totals and post-go-live issue log.
Complete when: Owners approve the records and support responsibilities; unresolved items have a named owner.
Make the mapping explicit.
Record the transformation before loading data. Include required fields, permitted values, default rules, lookups and the owner who approves the result.
| Source field | Target field | Rule and validation |
|---|---|---|
| CustomerCode: 00124 | customer_code | Keep as text; retain leading zeros and check uniqueness. |
| InvoiceDate: 13/10/2026 | invoice_date | Parse explicitly as day/month/year; export 2026-10-13 if required by the target. |
| Branch: NBO | branch_id | Use the approved branch lookup. Reject unknown codes instead of guessing. |
A matching total is a starting point.
Reconcile control totals and inspect the underlying records. Offsetting errors can produce a matching total while individual customer, supplier or item records are wrong.
Account for every row
Illustrative trial load. A rejected row remains unresolved until it is corrected and successfully reloaded or its exclusion is approved.
- Source records
- 1,000
- Accepted records
- 992
- Rejected records
- 8
992 + 8 = 1,000 accounted for. This does not mean the migration is complete.
Explain every difference
Illustrative receivables comparison at one cut-off in KES. Compare by customer and document to locate the difference.
- Source total
- 120,000
- Target total
- 118,000
- Target minus source
- −2,000
Keep the difference open until investigated and resolved. Do not post an unexplained balancing entry just to make totals match.
Both examples are fictional teaching records, not customer migration results. Set acceptance rules by dataset; keep currencies, units, dates and record scope consistent.
Download the migration checklist
Record the owners, evidence, mappings and reconciliation decisions for your project. Use the worksheet alongside the approved cutover plan and detailed working registers.
Record owners and evidence references. Keep sensitive source data in your approved project repository; use this worksheet for the review record.
1. Name owners and define datasets
2. Clean and deduplicate source records
3. Map fields, codes and tax data
4. Run trial loads and handle errors
5. Reconcile balances, stock and payroll
6. Test users, backups and cutover
7. Sign off and check after go-live
Field mapping register
Add your actual field names, transformations and checks. These blank rows are a starting template; extend the mapping in your project’s working register.
Reconciliation register
Compare one dataset, currency, unit and cut-off at a time. Enter source and target totals with their units, then document differences and the reviewer’s decision.
Financial balances / open items
Stock by item / location / unit
Payroll / other scoped dataset
Each reviewed item needs an owner and an evidence reference.
Formal approval remains separate
This tracker cannot verify records, backups or acceptance. The accountable owners must review the evidence and authorise go-live.
Entries stay in this tab. Download to retain the current entries, then download again after editing offline. No entries are submitted to VisionONE.
Migration questions, answered
Which data should we migrate first?
Agree the scope and dependencies first. Usually configuration and reference data must be ready before related master records and opening transactions are loaded. Confirm the actual sequence against the target system, then rehearse it in the test environment.
How are opening balances verified?
Compare source and target at the same cut-off, entity and currency. Reconcile the trial balance, relevant subledgers and open items, and investigate record-level differences. Finance owners should approve the documented reconciliation before release.
How many trial loads are needed?
There is no fixed number for every project. Repeat until mappings, exceptions, reconciliation and user testing meet the agreed criteria, and rehearse the final cutover sequence. Include the expected trial cycles and responsibilities in the implementation scope.
Who signs off data migration?
Accountable business owners approve their datasets, supported by finance, operations, payroll and IT as applicable. The authorised project sponsor or go-live decision-maker approves release using the consolidated evidence and agreed criteria.
Can historical transactions be migrated?
Sometimes, depending on the source export, target system and agreed scope. Confirm supported history, document relationships, attachments, cost and reporting needs before committing. A controlled read-only archive may be appropriate for history that is not migrated.
Prepared 13 October 2026. This is a planning template; your project team must approve its mappings, retention arrangements and cutover criteria for the actual deployment.