Migrating product data is the part of a platform switch that determines how the store works the day after launch. Design can be adjusted afterwards and integrations can be debugged — but if the product data comes across wrong, you are left with empty attributes, broken variants and categories that can’t find their products, in the middle of a freshly launched store. It is also the part of the project that is most often underestimated, because it looks like an export file and an import button when it is in fact a translation job between two different data models.
This guide covers the three steps that determine the outcome: the field mapping, the variant handling and the category structure — plus the preparation that makes all three easier.
Migrating product data in the right order: clean first
Every product catalogue that has lived a few years carries sediment: discontinued items, test products, duplicates, attributes filled in three different ways depending on who created the product. Moving it straight across to a new platform means paying to move junk.
Do a clean-out before the mapping work begins:
- Archive products that are discontinued and won’t be sold again.
- Merge duplicates and decide which record is the truth.
- Standardise attribute values: “Blue”, “blue” and “BLUE” should become one value, not three.
- Identify which fields are actually used in the store — and which have just tagged along.
The clean-up is also the right moment to think about where the product data should live going forward. If it is maintained today in spreadsheets alongside the platform, that is a sign the store lacks a proper product information flow — more on that further down.
Field mapping: the translation between two data models
The field mapping is the core of the work: a table where every field in the source platform gets an equivalent in the target platform. Names, SKUs, prices, stock levels, descriptions, attributes, images, SEO fields, relations such as accessories and spare parts — everything should have a row.
Three types of fields demand particular attention:
- Fields with no obvious equivalent. Platforms don’t share a data model. A free-text field in the source may need to become a structured attribute in the target, or vice versa. Every such case is a decision — document it.
- Fields with different formats. Prices with and without VAT, measurements in different units, HTML in descriptions that will render differently. This calls for transformation rules, not just mapping.
- The B2B data. Customer-specific prices, tiered pricing, contract catalogues and customer groups are often the most business-critical data and the data that differs most between platforms. If you run both B2B and B2C, it is worth choosing a platform that has both businesses in one core so the data doesn’t have to be duplicated.
Do a test migration with a representative subset — some simple products, some complex, some with edge cases — and let the people who know the catalogue review the result before the whole thing is run. Expect several rounds; that is how it is supposed to go.
Variants: where most migrations go wrong
Variant handling is the point where the platforms’ data models differ the most. Magento builds configurable products out of standalone simple products, WooCommerce has variations under a parent product, Shopify builds variants from a limited number of options. The same shirt in five sizes and three colours is thus represented in three completely different ways — and your migration has to translate between them.
The questions that must be answered before the variants are moved:
- Which attributes drive the variants — and do they exist as structured values in the source, or are they baked into the product names?
- Does each variant have its own SKU, its own price, its own stock level and its own images that need to come along?
- Are there variants that were set up as separate products in the source and should now be merged — or the other way round?
- How should the variant structure appear in the store: one product page with selectors, or separate pages?
Don’t forget the media either. Variant images, size charts, safety data sheets and other files must follow their products, and the images’ file names and alt texts often carry SEO value worth preserving. Decide early whether the images are moved physically or relinked from an existing media store.
Verify the variants especially carefully in the test migration. A catalogue can look complete on the surface while half the sizes lack their connection to the parent products — that is only discovered when a customer can’t select their size.
Categories: move the structure, not just the labels
The category structure is both navigation and SEO. A platform switch is the right moment to review it — but do it deliberately. Every category page that ranks in search is an asset, and if you change the structure, old category URLs must be redirected to their new equivalents with 301 redirects.
Also decide how the products connect to the categories in the target: do the connections come along in the migration, or are they driven by rules based on attributes? Rule-driven categories require clean attribute data — yet another reason to clean first.
The right home for your product data: built-in PIM
The best thing about a well-executed data migration is that it only has to be done once — if the data gets a proper home. HDL Commerce has a built-in PIM: product information is maintained in a structured way in one place, with attributes, variants and categories in the same model the store uses, instead of in spreadsheets and side systems. Feeds from ERP and suppliers connect via 200+ ready-made integrations, and the same product data drives both B2B and B2C because both live in one core.
That changes the calculation for the migration itself too: the mapping work you put in becomes the starting point for a lasting data structure, not a one-off exercise ahead of the next move.
Next steps
Unsure how your product data would survive a move? That is exactly what our free migration analysis answers: we go through your catalogue, your variants, your attributes and your integrations and give you a concrete picture of the mapping work before you make any decision. Book the analysis here — reply within 4 hours (weekdays).
