A new CRM or ERP may be configured correctly, yet after import users find three copies of one customer, products without units, negative stock and open orders that were completed long ago. Trust disappears and teams return to their old spreadsheets.
Data migration is a separate implementation stage with ownership, cleansing rules, trial loads and reconciliation. Its purpose is to create a reliable operational starting point, not to move the entire digital archive.
Move what is needed; archive the rest
| Data group | Usually migrate | Often retain in read-only archive |
|---|---|---|
| Customers and suppliers | Active records, legal details, contacts and owners | Duplicates and records with no confirmed value |
| Items | Active products, units, categories and barcodes | Closed items with no stock or movement |
| Inventory | Quantity by warehouse and agreed valuation at cut-off | Old intermediate count files |
| Open transactions | Unfulfilled orders, reservations, debts and advances | Completed documents available in the legacy system |
| History | The period needed for current work and analysis | Older detail kept for reference |
The decision depends on legal and management needs. Archiving is not deletion: old data remains accessible for enquiry without complicating the new operational database.
Inventory every source
The same customer may exist in CRM, accounting, a salesperson's file and the online shop. For each source record its owner, age, format, volume, keys and known quality issues.
| Source | Check | Risk |
|---|---|---|
| Legacy CRM | Stable ID, customer owner and deal state | Duplicates created manually |
| Accounting package | Legal details, balances, units and valuation | Different master-data logic |
| Online shop | Email, telephone, SKU, orders and returns | Guest and repeated accounts |
| Spreadsheets | Author, update date, formulas and hidden sheets | No consistent format or control |
Define keys and duplicate rules
A person's name or company name is not a reliable key. Spellings vary, organisations have branches and several contacts may share one telephone. Matching should consider customer type, tax identifier, normalised telephone, email and the relationship between a contact and an organisation.
Merge only obvious duplicates automatically. Send uncertain pairs for review rather than destroying the separate histories of two genuine customers.
Build a field-mapping specification
For every target field state its source, transformation, mandatory rule, default and error action.
| Target field | Source | Transformation | Control |
|---|---|---|---|
| Telephone | Several text columns | One international format | Invalid values go to an exception report |
| SKU | Legacy item code | Remove service spaces without losing leading zeros | Unique among active items |
| Unit | Text abbreviation | Map to an approved unit list | Unknown unit blocks the row |
| Order status | Legacy code | Explicit map to new workflow states | No silent default to “new” |
| Owner | Salesperson name | Map to an active user | Report former employees separately |
Opening balances require one cut-off
Balances cannot be migrated “as of now” while movements continue in the old system. Define a cut-off date and time, the last documents included and how later operations will be handled.
Reconcile stock quantity, reservations, valuation, receivables, payables, advances and cash separately. A zero grand total does not prove accuracy: one customer's credit can cancel another customer's debt.
Run a full trial migration
- Use a complete data copy, not ten hand-picked clean rows.
- Load it into a test environment through the same process planned for go-live.
- Count input, created, merged, skipped and rejected records.
- Reconcile control totals and sample customer → order → payment chains.
- Correct the source rule or mapping, clear the test result and repeat.
Manually correcting hundreds of records after every test hides a defective process. Migration should be repeatable and produce the same result.
Migration acceptance criteria
- every record count is explained as imported, merged, skipped or rejected;
- inventory and balance control totals agree at cut-off;
- there are no unknown units, warehouses, currencies or owners;
- open documents retain links and outstanding quantities;
- business users verify real records from their own work;
- legacy IDs are retained for tracing and reconciliation.
Conclusion
Successful migration combines source inventory, deliberate history selection, cleansing, mapping, trial loads and final reconciliation at one point in time. The new system should not become an expensive copy of old disorder.
After a verified migration, the team can plan a pilot, training and cut-over without betting the entire operation on one launch day. Explore the Business Reactor core.
