Data migration is where ERP programs quietly decide their fate. You can configure a beautiful order type and still promise dates on a duplicate item with the wrong lead time. Cleanup is not a technical extract-transform-load task. It is a business project with freeze dates, match rules, and someone who can say no.
Prioritize the domains that break go-live
- Items / materials: duplicates, missing units of measure, phantom BOMs.
- Business partners: customers and vendors with conflicting tax IDs and bank accounts.
- Open transactions: POs, SOs, and invoices that will not close in the legacy system.
- Chart of accounts & cost objects: mappings that make the first close unreadable.
- Employees as users: roles, not leftover superusers from 2014.
Minimum quality rules before load #2
| Domain | Must-have fields | Match key | Steward |
|---|---|---|---|
| Item | UoM, item type, planning method | Normalized SKU + manufacturer part | Supply chain |
| Customer | Bill-to/ship-to, tax, payment terms | Tax ID + normalized name | OTC lead |
| Vendor | Bank, tax, payment method | Tax ID + IBAN/account | Procurement + treasury |
| GL | Account type, recon flag | Legacy account map | Controller |
A cleanup operating rhythm
Stand up a war room twice a week. Publish a duplicate hit list. Merge in the legacy system when possible so history is coherent. Where history must remain, create a surviving record and a map table—never two actives “to be safe.”
Freeze, then exception
Set a date after which new items and vendors follow the new governance, even if still created in the old ERP. Exceptions require the steward’s signature. Without a freeze, you clean a beach during high tide.
Conclusion
Clean master data before migration with explicit match rules, named stewards, and a freeze that leadership will defend. Three rehearsal loads with reconciliation will tell you the truth faster than any data-quality slide. The new ERP will not redeem a messy catalog—it will operationalize it.