ERP Migration Data Validation Guide: From Legacy to New System
A practical guide to validating product catalog data at each phase of an ERP migration project — from initial assessment through data cleansing, test imports, parallel runs and go-live.
ImportCheck Team
Product · ImportCheck
Data validation is the most consistently underestimated phase of ERP migration projects. Project plans allocate time for system configuration, user training and go-live support. They routinely underallocate for the discovery that 30–40% of catalog data does not conform to the new ERP's import requirements — and that correcting it takes weeks, not days.
⚠️The most common reason ERP migrations overrun
In post-project reviews of ERP migrations at SMEs, catalog data quality issues are cited as the primary or secondary cause of schedule overrun in the majority of projects. The fix costs three to ten times as much when discovered during go-live as when discovered during initial assessment.
Phase 1: Legacy data assessment
The first phase of data validation happens before any migration work begins. Its purpose is to establish a baseline: how much of your current catalog data is usable in the new ERP without modification?
- 1Extract a full catalog export from the legacy system in the most complete format available
- 2Map legacy field names to new ERP field names — identify fields with no equivalent, fields that need transformation and new mandatory fields with no legacy source
- 3Run the mapped file through the new ERP's validation rules to get a baseline error rate
- 4Categorise errors by type and volume — this becomes your data cleansing workplan
Phase 2: Data cleansing and mapping
Data cleansing at migration scale is a project in its own right. The scope is determined by the Phase 1 assessment. Common cleansing tasks for product catalog migration include:
- Standardising price formats: removing currency symbols, standardising decimal separators, handling prices stored as text
- Rebuilding supplier code references: cross-referencing legacy supplier IDs against new ERP supplier master data
- Reclassifying product categories: mapping legacy category codes to the new ERP classification hierarchy
- Populating new mandatory fields: fields required by the new ERP that had no equivalent in the legacy system
- Deduplicating product references: resolving cases where the same product was entered with different SKUs
ℹ️Cleansing the data vs. fixing the process
Data cleansing fixes historical data. It does not prevent new data from arriving in the same quality. Run parallel with cleansing: establish the format specification and validation gate that will apply to all future catalog imports. Otherwise you will repeat the cleansing exercise at the next migration.
Phase 3: Test imports
Test imports validate that cleansed data actually loads into the new ERP as expected. Run at least three test import cycles before go-live:
| Test cycle | Scope | Success criterion |
|---|---|---|
| Cycle 1 (structural) | 100% of rows, no data corrections | File parses without structural errors; baseline error rate documented |
| Cycle 2 (post-cleansing) | 100% of rows after Phase 2 cleansing | < 5% row error rate; all critical fields validated |
| Cycle 3 (pre-go-live) | Final snapshot with live ERP reference data | < 1% row error rate; no critical field errors |
Phase 4: Go-live validation
Go-live is not the end of data validation — it is the beginning of the ongoing process. The first three to six months after go-live are the highest-risk period: contributors are still adjusting to new templates, ERP reference tables are still being completed and edge cases not covered in testing surface in production.
- Mandate pre-upload validation for all catalog imports in the first six months post go-live
- Review error distribution weekly for the first month — changes in error type indicate new process gaps
- Keep the legacy system readable (not writeable) for at least 90 days post go-live for reference lookups
- Document all post-go-live error corrections and feed them back into the format specification
Phase 5: Establishing the ongoing process
A successful migration is one where the data quality discipline established during the project becomes the permanent operating process. The go-live milestone should coincide with the handover of a documented validation process to the operations team — one that does not require IT involvement to run and that produces a consistent audit trail for every import.
| Phase | Typical duration | Key dependencies |
|---|---|---|
| Legacy data assessment | 1–2 weeks | Access to legacy system export; new ERP import specification |
| Data cleansing | 2–8 weeks | Scope of errors from assessment; availability of reference data |
| Test imports | 1–3 weeks | ERP sandbox environment; cleansed data from Phase 2 |
| Go-live validation (first month) | Ongoing | Validation tool; trained operations team; documented process |
💡The single most impactful step you can take today
If your migration project is already underway, run your current catalog extract through a validation tool against the new ERP's rules today. The error report you get back is your risk register. Every error found now is an error that will not cause a go-live delay in three months.
Ready to stop ERP import errors before they happen?
Upload your catalog file and see exactly which rows will fail — in under 90 seconds. Free 14-day trial, no credit card.
Start free trial