The ERP data migration mistake that almost sent products to the wrong customers
Quick answer
A data migration can load successfully and still be dangerously wrong. If customer IDs, names, addresses and contacts are not reconciled at field level, a shifted CSV export can put the right order against the wrong delivery details.
One of the most dangerous ERP data migration problems I have seen looked harmless at first. The file loaded. The record counts looked plausible. The Dev environment accepted the customer data.
Then we exported the data back out and reconciled it against the current system. That is when the issue appeared: customer addresses and contact details had shifted by one row.
Customer A had Customer B's address. Customer B had Customer C's contact details. Across thousands of records, the data looked structured, but it was attached to the wrong customer.
If that had reached live, products could have been sent to the wrong addresses at scale. The revenue risk was in the millions. The reputation damage would have been worse.
The export looked like the problem, but the real risk was weak validation
The data came out of a legacy ERP system as a CSV file. Something broke in the export or import process. We never proved exactly whether it was a delimiter, line break, hidden character or export defect.
That is the point: during migration, you rarely get the luxury of a neat root cause before the business needs a decision. What matters is whether your validation process catches the defect before production.
In this case, the Dev load helped. It gave us a safe place to find the issue before customers, finance, warehouse and customer service were exposed to it.
A successful load only proves the target ERP accepted the file. It does not prove the data still means the same thing.
Why record counts were not enough
Record counts are useful, but they would not have protected the business here. The same number of rows can exist before and after migration while every address is attached to the wrong customer.
The dangerous defects are often relationship defects, not quantity defects. You need to know that the right values stayed with the right entity.
For customer data, that means checking more than "we loaded 8,000 customers". It means checking that customer account, customer name, postcode, delivery address, contact, email, phone number, credit terms and status still belong together.
The validation checks that would catch this earlier
The practical answer is a join-back validation against the source data. Take a stable customer key and compare important fields in the target environment back to the original extract or legacy system.
For high-risk customer migration, I would expect checks like:
- Customer ID to customer name lookup.
- Customer ID to postcode and primary delivery address lookup.
- Customer ID to main contact name, email and phone lookup.
- Sample checks for high-value customers and frequently shipped accounts.
- Exception reports where key fields changed unexpectedly.
- Spot checks for records with commas, quotes, line breaks or unusual address formatting.
- Business owner sign-off for customer, supplier and address data before cutover.
This is not glamorous work, but it is exactly the work that stops a migration turning into a customer-service crisis.
What the business would have seen if it reached live
If the shifted address data had gone into production, the first symptoms would probably not have looked like a migration issue. They would have looked like failed deliveries, customer complaints, missing goods, returns, credit notes and confused customer service calls.
Warehouse teams would have picked and despatched correctly according to the ERP. The ERP would have shown the address it believed was correct. The courier would have delivered to the address on the label.
But the product would have gone to the wrong customer.
That is why migration validation has to include business reality, not just technical completion.
What this means for ERP data migration
Data migration risk is often described as cleansing: remove duplicates, fill blanks, standardise codes. That matters, but it is only part of the job.
You also need to protect the relationships between records. Customer to address. Supplier to payment terms. Item to unit of measure. Product to barcode. Open order to customer. Stock balance to location. Finance balance to account.
When those relationships shift, the data can look clean and still be wrong.
How to reduce the risk before cutover
Before a live ERP load, create a small set of migration controls that the business can understand:
- A source-to-target mapping template for key fields.
- A customer and address reconciliation report.
- A ranked issue register for failed or suspicious records.
- A master data ownership matrix so the right person signs off each domain.
- A cutover checklist that includes field-level validation, not only record counts.
If you cannot reconcile the data in Dev, you are not ready to load it into Production.
The takeaway
The closest ERP migration failures are the ones that almost look successful. This one loaded into Dev, but the data relationship was wrong. Customer details had moved down a row and the business would have paid for it through wrong deliveries, lost revenue and damaged trust.
The fix is not more optimism at cutover. It is stronger validation before cutover: join the data back, compare critical fields, involve business owners and make exceptions visible before anyone relies on the new system.
Preparing ERP data for migration?
Digital Adaption helps manufacturing SMEs test migration readiness, reconcile source data and find the defects that record counts miss.
View the readiness review