When a store moves to a new ecommerce platform, every product moves with it. For a store with a large catalog, moving that product data is often the biggest part of the job.
This checklist walks through it, from auditing the catalog before the move to going live on the new platform.
What is ecommerce replatforming?
Ecommerce replatforming is moving an online store from one commerce platform to another, for example from a self-hosted platform to a SaaS one. For product data, that means moving your products and variants, attributes and their allowed values, categories and images, along with the SEO fields and URLs attached to each product page.
Even a platform chosen to fit your catalog stores products its own way, with its own rules for variants and attribute types. Mapping your catalog to those rules is where most of the product data work comes from.
When do ecommerce teams replatform?
Teams replatform when the current platform holds the business back, such as slow pages or rising maintenance costs. Product data problems often push the decision too:
- The catalog has outgrown the platform. The platform limits how many variant attributes a product can have, or doesn't support the attribute types the catalog needs. For example, trousers sold by color, waist, length and fit need four variant attributes, and some platforms allow only three per product.
- New channels need product details the catalog doesn't have. Each marketplace and retailer has its own list of required product details, and a new country site needs product content in another language.
- New products take too long to go live. Supplier files come in different formats, and the team cleans them up by hand before products can be published.
- Product pages are missing details. Pages with missing attributes or short descriptions are harder for shoppers to find, in search engines and in AI shopping assistants.
A new platform doesn't fix these on its own, because the product data moves over as it is. They're fixed by cleaning up and filling in the product data, ideally in a PIM, so the fixes carry over to whichever platform you use. Hypotenuse AI is an AI-native PIM that does this, with flexible data models for variants and hierarchies, checks against each channel's requirements, supplier data mapped to your schema and enrichment that fills missing attributes.
What product data should you audit before replatforming?
Audit the catalog before you export anything, so the mapping to the new platform starts from how your data is structured today.
Parent and variant structure
Count how many levels your catalog uses. One catalog might group a jacket style under a collection, with colors under the style and sizes under each color. Another might have a single parent product with every color and size combination as a variant.
Then check where the identifiers sit. Look for:
- Style IDs stored on the wrong level. If the style number sits on variant rows and not on the parent, an import that matches products at the parent level can treat each row as a new product.
- Variants without a parent. A row with a style code but no parent ID won't group onto a shared product page.
- One code used for two products. If an old style code was reused for a newer version of a product, resolve it before the import groups the two together.
- Your largest styles. Platforms still set limits, such as the number of variant attributes a product can have, and the limits differ between platforms. Compare your largest styles against the new platform's limits early, since a style over a limit needs a different structure.
Data that lives outside the catalog
Some information a product page needs is not in the catalog export. Images may sit in a separate system, linked only by SKU. The brand or regional site a product belongs to may be handled through separate exports and never stored as a field.
List these gaps and decide how each one reaches the new platform. For images, a supplementary file keyed on SKU ID works well. For brands and sites, add a dedicated field so the import can route each product to the right place.
Completeness and consistency
Check completeness by category: which required attributes are empty, and which categories have only a handful of attributes. Then list duplicate products and inconsistent values, such as "Stainless steel" and "SS" used for the same material.
Brands or sites set up differently
If you run several brands or regional sites, check whether any are structured differently or still export in an older format. Each one may need its own mapping rules.
How do you map product data to a new commerce platform?
The mapping connects each field in your current data to where it lands on the new platform. Build it as a sheet with one row per attribute, listing the source field, destination field, data type, allowed values, the level it sits on and who owns it.
Work from a full sample export
Ask for a full sample export from the new platform, or its import template filled in with real products, and compare it with the attribute list you were given. The two often disagree. Look for:
- Fields marked as holding several values that only hold one in the file, and the reverse.
- Attributes on the list that don't appear in the export at all.
- The same attribute under a different field name.
Where the two disagree, confirm with the platform team and follow what the platform accepts.
Confirm the file format and structure
Each platform has its own import formats and rules, and some are stricter than others. Check these before building anything:
- File format. Some platforms only accept catalog imports as XML files that match their own schema. If you plan an interim step with spreadsheet files while the integration is built, confirm the platform accepts that format too.
- Parent records. Some platforms build product pages at the parent level, so the import needs a parent record even when content is written for each variant.
- Separate files. Catalog data may be split across files, for example attributes in one file and categories in another.
- Fields to send. Agree a shortlist of the fields the new platform uses, which keeps imports easier to check.
Decide attribute levels and allowed values
For each attribute, decide whether it belongs on the parent or the variant. Material usually sits on the parent, while color and size sit on the variant. Descriptions belong on the level your product pages are built on.
Then check each attribute's type on the new platform. An attribute with a fixed list of values only accepts values from that list, so map every old value to one of them and list the values with no match. A free-text attribute accepts new values, which leaves room to add detail during the move.
Map categories and navigation
Map every old category to its new equivalent and list the categories with no match. Map on a stable category ID where you can, so renaming a category later doesn't break the mapping.
Categories also decide which attributes apply to a product. Check that each new category carries the attributes its filters need. Our guide to ecommerce product taxonomy covers how to structure both.
How do you protect SEO when replatforming an ecommerce site?
Product and category pages have URLs and SEO fields that search engines have already indexed. Move them with the same care as attributes.
- Export every URL and SEO field. Include page titles, meta descriptions, image alt text and canonical URLs for each product and category page.
- Map old URLs to new ones. URL patterns often change between platforms. Some platforms use fixed path prefixes for product and collection pages, so old URLs can't always be kept as they are.
- Use permanent redirects. Google recommends server-side permanent redirects, such as 301s, from each old URL to its new one, kept in place for as long as possible.
- Check how redirects behave. On some platforms, a redirect only works once the old URL no longer loads a page. Test redirects on the new platform before launch.
- Update internal links and canonical tags. Point internal links at the new URLs and give each new page a self-referencing canonical tag. Then submit the new sitemap in Search Console.
How should you test product data before going live?
Start with the products that represent your hardest cases: the style with the most variants, a brand set up differently, variants without a parent and products with localized content. These show whether the mapping holds before the rest of the catalog loads.
- Load the full catalog into a staging environment. Some issues only appear at full volume.
- Reconcile counts. Compare the number of products, variants, images and categories in the source with what arrived. A difference points to records the import skipped or duplicated.
- Review product pages on the storefront. Check variant pickers and filters for a sample from each category, and confirm images are attached to the right color.
- Validate against the platform's rules. Run imports through the platform's own validation and read the error log. Fix issues in the mapping and rerun the import, so each fix carries into the final load.
How do you keep one source of truth during cutover?
Cutover is the window between the final data load and the new store going live. Product data keeps changing through it, as new products arrive and teams update copy.
- Agree where edits happen. Name one system as the source of truth for each type of product data, and tell every team. If a PIM or ERP feeds the storefront, keep edits there.
- Freeze or log changes. Pause catalog edits between the final export and go-live, or log every change made in that window and apply it to the new platform before launch.
- Point upstream feeds at the new platform. Confirm that each system sending product data, such as an ERP or PIM, sends it to the new platform in the new format. Keep the old feeds running until the new ones are confirmed.
- Plan for brands that move later. If brands or sites move in phases, keep the old format running for those still waiting to move.
Should you improve product data during a replatforming?
A replatforming is a good opportunity to improve product data, since every record is already being mapped and checked. The new storefront may also bring filters and page templates that need attributes your current catalog doesn't have.
Keep the scope tied to what the new storefront uses:
- Fill the attributes that drive filters. Start with the attributes behind filters on the new platform, category by category.
- Add attributes to thin categories. Categories with only a few attributes are good candidates for new ones, where the platform's attribute types allow it.
- Standardize values. Map inconsistent values to one standard value before loading, so filters work at launch.
- Rewrite content at the right level. If product pages move from the color level to the style level, descriptions written for each color need combining into one per style.
Across a large catalog, product data enrichment can take on much of this work. Look for tools that fill missing attributes from the web as well as from supplier documents and product images.
Ecommerce replatforming checklist for product data
Before you start
- Parent and variant levels documented, with the identifier used at each level
- Variants without a parent, and codes shared by two products, resolved
- Largest styles compared against the new platform's variant limits
- Data stored outside the catalog listed, such as image links
- Completeness checked by category, with duplicates and inconsistent values listed
- Brands or sites with a different structure or export format identified
Mapping
- Full sample export received from the new platform, and attribute lists checked against it
- File format and schema confirmed, including any interim file-based route
- Mapping sheet built with source field, destination field, data type, allowed values, level and owner
- Parent-level records included where the platform builds pages at the parent level
- Old values mapped to each fixed value list, with unmatched values listed
- Categories mapped on stable IDs, with unmatched categories listed
- Brand or site field added where products need routing
- Old product and category URLs mapped to new URLs, with SEO fields exported
Testing
- Hardest cases tested first, starting with the largest style
- Full catalog loaded into staging
- Product, variant, image and category counts reconciled with the source
- Variant pickers, filters, images and page content reviewed on the storefront
- Import errors fixed in the mapping and the load rerun
- Permanent redirects tested on the new platform
Cutover
- Source of truth named for each type of product data
- Catalog edits frozen or logged between the final export and go-live
- Upstream feeds pointed at the new platform
- Old feeds kept running until the new ones are confirmed
After go-live
- Internal links and canonical tags updated, and the new sitemap submitted
- Redirects monitored for errors and missed URLs
- New products checked for completeness as they arrive on the new platform
- Attributes and values added to thin categories
How does Hypotenuse AI help with replatforming product data?
Hypotenuse AI is an AI-native PIM for enterprise ecommerce teams. It can hold your product data and feed your commerce platform, or sit between an existing PIM and the platform to enrich data before it goes out.
A flexible data model. Define product hierarchies, variants and relationships in a data model that scales with your catalog, and check fields against your rules and each channel's requirements before anything is published.
Integrations. Hypotenuse AI connects to Shopify, Salesforce Commerce Cloud, NetSuite, Salsify and Akeneo, among others.
Gaps filled with sources shown. Missing attributes are filled from sources such as the web and product images. Every enriched value carries a confidence score and shows the reasoning and source behind it, and low-confidence values go to a review queue.
Version history. See what changed and when, and trace every value back to where it came from.
Start with a sample. Teams often start with a spreadsheet import on a sample of products, then switch to the live export once attribute rules and brand voice are set.
FAQs
What is the difference between replatforming and data migration?
Replatforming is the whole move to a new commerce platform, including the storefront and its integrations. Data migration is the part that moves records, such as products and orders, from the old platform to the new one. Product data migration is one part of a replatforming project, with its own owner and plan.
Do you need a PIM when you replatform?
A PIM is optional, and it changes what moves. If product data lives in the commerce platform, the whole catalog has to be exported and reshaped for the new one. If it lives in a PIM, the PIM stays in place and the work becomes mapping and connecting it to the new platform. A future replatforming then starts from the same source. Our catalog management software page covers how catalog management and a PIM fit together.
Can you switch PIMs and commerce platforms at the same time?
Yes, and some teams do. Two data models change at once, so agree which system owns each type of data at every stage and test each connection separately. Moving the PIM first and then connecting it to the new platform makes each change easier to check. For the PIM side, see our PIM migration guide.
What should happen to discontinued products when you replatform?
Decide before the final export. Products that may return, or that still get search traffic, can move to the new platform unpublished or redirect to a close replacement. Google recommends that URLs with no equivalent return a 404 or 410. Keep discontinued records in your PIM or an archive for reporting.
Who should own product data during a replatforming?
Give the product data or merchandising team ownership of the mapping and sign-off on product pages. The ecommerce or development team owns the imports and platform configuration, including redirects. Name one person as the final decision-maker for mapping questions, since many of them sit between the two teams.
.avif)