Product Data Cleanup Before Migration

Export your full product list and check for exact SKU duplicates first — these are usually a data-entry or import error and are simple to merge once found. Then look for near-duplicates: the same product re-created under a different SKU, often the result of a supplier feed re-import that didn't match against existing records, or a product that was manually recreated instead of edited after a system change.

For each duplicate pair, decide which record is the "real" one — usually the one with more complete data, more order history, or better SEO signals like backlinks or reviews — and merge or redirect the other into it rather than migrating both and sorting it out later on the new platform.

Orphaned media — images and files uploaded to your media library that no product, category, or content page still references — accumulate naturally over years of product updates, seasonal campaigns, and platform changes. They add no value on the new platform and just increase migration time and storage, so it's worth identifying and excluding them.

Be careful with the reverse case too: images that are referenced but broken (a missing file, a dead external URL) are worth catching now, since a broken image on a product page is a small but real trust signal problem that's much easier to fix against your current, familiar data than after the move.

Years of ad hoc additions tend to leave categories and attributes inconsistent: the same concept spelled or capitalized differently across products, categories that overlap or duplicate each other, attributes used for one purpose in one product line and a different purpose in another. This inconsistency usually doesn't cause visible problems on the old platform, where staff have learned to work around it, but it becomes a real liability once it's mapped mechanically to a new platform's data model.

Build (or confirm) a clean, agreed taxonomy before migration — a defined category tree and a defined attribute list with consistent naming — and reconcile your actual data against it. This is also the point where it's worth asking which attributes are still meaningful to customers or internal operations and which exist only because nobody removed them.

Variant structures (size, color, material, and how they combine into specific sellable SKUs) are handled differently across platforms, and inconsistent source data makes this worse. Look for products where variant options don't follow a consistent pattern — some size variants named "S/M/L" and others "Small/Medium/Large" for the same product line, or products where a variant combination exists in your system but has no valid price or stock behind it.

Decide your target variant model before migration, not during it. Knowing in advance whether the new platform handles variant combinations the same way the old one does — and where it doesn't — determines whether your existing variant data can map directly or needs restructuring first.

Not everything in your current catalog deserves a spot on the new platform. Discontinued products with no remaining stock, test or placeholder entries, and legacy fields nobody can explain the original purpose of are all candidates for leaving behind — with a documented decision, not a silent drop. Migrating less, deliberately, is often better than migrating everything and sorting it out afterward on an unfamiliar new system.

For anything you decide not to migrate that still has an indexed URL, make sure it's accounted for in your redirect plan (see the redirect-mapping guide) rather than left to 404 by accident.