A migration acceptance dataset is a small, deliberate set of records that can prove a store still works after import. Random products often miss the difficult cases: variants, sale prices, unavailable stock, coupons, past orders and accounts with unusual histories.
How to make the decision
Create a table with source ID, stable business key, record type, expected destination value, test owner and result. Choose at least one ordinary product and each exceptional shape the store uses: multi-variant item, sale item, backorder, downloadable item, tax exception and archived order. Capture expected relationships, not just row counts. Export the source records at a known time so a later edit is not mistaken for an import error. After the trial, compare both exact values and what the customer sees on the page. Keep test data out of live customer communications.
Worked example
Synthetic dataset has 12 products, four customers and six orders. Product P-07 has three sizes and a sale price; the import creates three variants but applies the sale to only two. A count-only check passes because the rows exist. The acceptance test fails because the expected price matrix differs. The team corrects the mapping and reruns P-07 plus two normal products to catch a broad fix causing a new defect.
What to verify
- Does each record have a stable source key?
- Are expected values saved before import?
- Are relationships tested as well as counts?
- Is personally identifiable data minimized in shared test files?
Limits and ownership
The acceptance sample proves only the covered cases. Pair it with full-catalog reconciliation and a customer journey test before launch.
What to hand over
Keep the dataset under version control with no unnecessary personal data. If a field changes after the source snapshot, record a new expected value and why it changed. The same rows should be reusable for a second rehearsal, so a reviewer can distinguish a fixed defect from a different test sample.
Common question
How large should the dataset be?
Large enough to cover each distinct data shape and failure mode; volume testing is a separate exercise.
Next useful step
Use Testing Customer Account Transfers During a Store Migration for the adjacent decision. For an implementation review, see Megvi’s ecommerce website development service and bring the source records, proposed checks and open exceptions.
Source checked 28 October 2026: WooCommerce: product CSV importer and schema. Check current platform settings before changing a live store or report.
The worked example is illustrative and is not presented as a Megvi client outcome.