When assessing a retail-system supplier, “we have migrated data before” and “we support bulk imports” are insufficient. The supplier must understand the brand’s data, document conversion rules, expose discrepancies using real records and enable business teams to review the results.
Begin with a representative sample, then progress to a full or near-full-volume rehearsal. Deliverables should include scope, mappings, discrepancy reports, exception procedures and evidence supporting cutover—not just an imported database.
Check whether the supplier can define the migration scope
A credible plan distinguishes operational data, reference data and archives, and identifies each source, treatment and acceptance owner. A promise to “migrate everything” before assessing source quality makes cost, timing and usability difficult to judge.
Give suppliers a concise inventory and ask how PDQ display packs, complete boxes and individual units will map; how opened stock becomes opening inventory; how duplicate members are resolved; whether uncollected pre-orders migrate; and how history remains accessible. Answers must connect fields to business actions, rather than repeat a product feature list.
Specify responsibilities. The brand coordinates usable exports and definitions from its legacy supplier. The new supplier provides templates, transformations, imports and technical validation within scope. Product, supply-chain, loyalty, retail operations and finance teams approve rules and results. Suppliers cannot decide the business meaning of historical data for the brand.
Use the brand’s own exceptions in a proof of concept
A demonstration database with clean codes, consistent units and no duplicate members proves only that the importer runs. Provide de-identified samples representing likely project failures.
- Products: multiple codes per item, duplicate barcodes, PDQ-to-unit conversions and discontinued items with stock.
- Inventory: unopened boxes, opened loose units, multiple locations and transfers in transit.
- Members: shared phone numbers, cross-channel identities, different coupon states and limited-event eligibility.
- Orders: uncollected pre-orders, paid but unshipped orders and returns or exchanges in progress.
The first POC is intended to reveal problems; it need not pass every sample immediately. The supplier should locate errors in source data, mapping, conversion, configuration or interfaces, and document corrections. Changing results without preserving rule changes leaves the same failure waiting for the final migration.
Require deliverables that business teams can review
| Deliverable | Question answered | Acceptance focus |
|---|---|---|
| Scope inventory | What migrates, remains searchable, is archived or is retired? | Explicit decisions and owners |
| Dictionary and mapping | How do fields, units and states convert? | Clear business meaning and exception treatment |
| Import log | Which records succeeded, failed or were skipped? | Identifiable causes and traceable resolution |
| Discrepancy report | Why do quantities, values or states differ? | Critical issues closed; other issues assigned deadlines and owners |
| Business test scripts | Can migrated records support real operations? | Prerequisites, steps, expected and actual outcomes |
| Cutover and rollback plan | When does entry freeze, how do changes transfer, and what triggers rollback? | Actions, decision-makers and recovery methods |
Version mappings and transformation scripts. Record each change’s reason, affected data, test results and effective version. The final full or near-full-volume rehearsal must use the same rules as production cutover.
Progress from samples to volume rehearsals and business tests
Use the first trial to inspect fields, mappings and rules. Expand the dataset to test throughput, exception volumes and reconciliation. Before cutover, rehearse the complete extraction, transformation, import, reconciliation and issue-resolution sequence at approximately production volume, including its duration.
Fix and retest critical differences before progressing. Record the quantities, values, owners and deadlines for other differences and obtain business approval. At final rehearsal sign-off, products, inventory, loyalty entitlements and open orders should have no unexplained differences; business and finance owners approve the result.
Test failure paths too: missing files, duplicate imports, interrupted interfaces, partial failures and time overruns. The supplier must explain how processing pauses, resumes, reruns or rolls back without processing successful records twice.
A successful import is not evidence of operational readiness. Execute scripts using migrated data:
- Break a PDQ into individual units and sell them; test loose-unit counts, store transfers and sales returned from unattended devices.
- Redeem points and coupons; test merged identities, limited eligibility and the boundary with stored value.
- Collect pre-orders and link returns to original orders; test stock reservations, refunds through original payment routes and entitlement treatment after cancellation.
Each script needs prerequisites, steps and expected versus actual results. Identify the source, conversion, configuration or interface responsible for any difference. An unexplained result corrected manually is not a basis for bulk rollout.
Check traceability: can stores and customer service find original identifiers, can business users explain changed definitions, and can the project team locate failed records in logs? Those capabilities support dispute handling after launch.
Put the evidence into supplier scoring and cutover gates
Do not reduce migration to a yes/no feature. Score scope definition, collectible-toy data knowledge, sample migration, mapping and version control, discrepancy reporting, business tests, volume rehearsal and rollback separately. Require evidence or demonstrations for each.
Classify product requirements as standard functionality, configuration, integration, custom development or unsupported. Import tools are a system capability; source cleansing, business decisions, external-interface changes and historical-query environments may have different owners. Explicit scope and deliverables reduce disputes about what the quotation includes.
The PEKON Smart Retail System covers products, store POS, orders, inventory and stock counts. PEKON CRM supports identities, tiers, points and coupons. Use the collectible-toy retail solution to prepare samples for PDQ packaging, opened stock, member preferences and unattended devices.
Migration capability ultimately means understandable rules, results that pass both aggregate and record-level review, and a cutover executed with rehearsed rules. Include the scope, mapping, discrepancy reports, business scripts and volume-rehearsal results in supplier scoring. Projects without those deliverables should not enter cutover review.
The collectible-toy system-migration acceptance checklist brings PDQ and individual-unit stock, loyalty entitlements, open orders and supplier deliverables into one review framework. Project owners can organise internal review around these four areas and discuss system boundaries, source quality and cutover timing with PEKON.
Frequently asked questions
Does an import template demonstrate migration capability?
No. It describes target fields, not the ability to interpret legacy data, handle exceptions, map records and reconcile business results. Review trial results, logs, discrepancy reports and rehearsal plans.
How much data should a POC use?
Start with representative, high-risk cases. Expand after corrections and retesting. At least one rehearsal should approach production volume before cutover.
Which exceptions best test collectible-toy migration?
PDQ-to-unit conversion, duplicate barcodes, loose stock, multiple locations, duplicate members, coupon states, limited eligibility, uncollected pre-orders and active returns reveal issues a simple product demonstration misses.
Must all discrepancies be zero before continuing?
Critical issues must be corrected and retested. Other differences need documented impact, ownership, deadlines and business approval. Final acceptance must not retain unexplained critical-data differences.
What evidence should be requested before signing?
Request sample scope, templates, mappings, trial results, import logs, discrepancy reports, business scripts, exception procedures and a cutover rehearsal plan that business and IT teams can jointly review.