Why SKUs don't always transfer cleanly
In an ideal migration, every SKU on the old platform maps 1:1 to the same SKU on the new one and nothing changes. In practice, platforms often have different rules for what a SKU can contain, different handling of variant-level vs. product-level SKUs, or a history of duplicate/reused SKUs on the old system that need to be resolved rather than copied forward as-is. A straight database export can carry these inconsistencies over instead of fixing them.
Where SKU mapping connects to other systems
Your SKU is often the join key between your store and everything around it - supplier feeds, a warehouse or fulfillment system, accounting software, marketplace listings. If a SKU changes format or value during a migration without updating every connected system, those integrations start failing to match products even though the store itself looks fine. Mapping needs to happen with those downstream systems in mind, not just inside the new platform.
What we check before migrating SKUs
We audit the existing SKU set for duplicates, inconsistent formatting, and orphaned SKUs (referenced by an order or feed but not an active product) before deciding whether to preserve them as-is or normalize them on the new platform. Preserving existing SKUs is usually preferable when downstream systems depend on them; normalizing makes sense when the old SKU scheme itself was the problem.
Frequently asked questions
Should I keep my exact same SKUs on the new platform?
Usually yes, if any supplier feed, fulfillment system, or marketplace listing depends on them - changing SKUs breaks those integrations unless they're updated at the same time. We evaluate this case by case rather than defaulting to either option.
What happens to duplicate SKUs during a migration?
They need to be resolved before or during the migration, not carried forward - most platforms don't allow true duplicate SKUs, and letting an automated import guess how to deduplicate them risks merging or dropping the wrong product.
Does SKU mapping affect my order history?
It can, if historical orders reference SKUs that change - we account for this so past order records still resolve to the correct product after the move, rather than only mapping the live catalog.
Is SKU mapping automated or manual?
It's a mix - straightforward 1:1 matches can be automated and verified quickly, but ambiguous cases (duplicates, inconsistent formats, missing SKUs) need a human decision rather than a best-guess algorithm.