The practical answer
Migration quality is largely determined before data import begins. New software cannot reliably interpret ambiguous item codes, duplicate customers or unexplained stock discrepancies.
A realistic business scenario
Two customer records describe the same builder; three product identifiers represent one fitting. If imported unchanged, sales reporting and stock control start with confusion.
Establish master-data ownership
Assign accountable people to customer, product, supplier and inventory records. Decide which source is authoritative.
Clean and standardise
Remove duplicate accounts carefully, normalise units, verify product identifiers and resolve inactive records using agreed retention rules.
Reconcile balances and commitments
Count important inventory, identify open orders, returns, outstanding invoices and credits. Decide which historic transactions need to migrate.
Test a sample import
Run pilot imports, compare totals and manually check representative records. Record transformation rules and obtain sign-off before full migration.
Buyer’s checklist
- Identify duplicate customers and SKUs
- Standardise units and price lists
- Reconcile stock and open orders
- Document field mapping
- Test imports and sign-offs
Common mistakes to avoid
- Deleting history without retention review
- Importing every obsolete field
- Using unapproved last-minute spreadsheet changes
Frequently asked questions
Should all historic orders be migrated?
Not always. Agree operational and statutory needs before deciding.
Who owns data migration accuracy?
The project needs named business owners alongside the technical implementation team.
What to do next
The right next step is to assess the workflow using real customer, stock and financial scenarios. Compare providers against the same requirements and seek written confirmation of product-specific capabilities. Use a data-readiness checklist before implementation.
