What product data should you prepare before an ecommerce migration?
Direct answer. Prepare six inputs before quoting a catalogue migration: a product export, variant rules, stable identifiers, reachable images, URL mapping and acceptance tests. Count products and variants explicitly; a row count alone can conceal very different amounts of work.
Commissioning work now? Compare the Shopify and WooCommerce migration scope, or send the project details for a scope check.
Agree what a product means in the quote
A product can have several variants, images and destination records. Before comparing migration prices, give the supplier a representative sample and the platform export rather than only saying “we have a hundred products”. Identify any bundles, subscriptions, personalized fields or app-managed data that needs separate treatment.
Example catalogue: one shirt offered in three sizes and two colours has six purchasable combinations. That is an illustrative count, not a platform limit. Decide whether your scope counts the parent product, variants or rows, and how duplicate or discontinued items are handled. The definition belongs in the quote.
Build a mapping sheet before the full import
Use stable identifiers to connect old records, new records and images. Record the title, SKU, options, prices, inventory treatment and old URL for the sample. Keep original exports unchanged and work on a copy. A supplier should explain what happens when a destination record already exists before an import is allowed to overwrite it.
Shopify’s current CSV documentation describes product imports, required columns and dependencies between variant fields. Use the destination platform’s current sample and documentation, rather than renaming headings in an old spreadsheet until it appears to work. Ask the implementer to report records skipped or transformed.
| Input | Example decision to record | Acceptance evidence |
|---|---|---|
| Product and variant count | What the quoted unit includes | Source-to-destination totals explained |
| Identifiers | SKU and parent/variant mapping | No unintended duplicates or overwrites |
| Images | Which image belongs to which item | Correct gallery and variant images |
| Descriptions | Cleanup versus copywriting | Sample formatting and links checked |
| Public URLs | Old URL to relevant new URL | Representative redirect tests |
| Exclusions | Historic orders and app data | Named separate scope or explicit exclusion |
Treat images and descriptions as real migration work
Confirm who supplies product photographs, whether image locations can be accessed by the import process and how multiple images attach to a product or variant. A folder of unnamed files is not yet a catalogue map. Identify missing images and unclear usage rights before the launch deadline.
Descriptions can contain old styling, embedded widgets or links that no longer make sense on the destination. Inspect a small mix of simple and complex items. Product photography, copywriting, translation and manual cleanup are different tasks from transferring an agreed clean export, so name them in the exclusions or quote them separately.
Include discovery and checkout in the acceptance test
Test the product inside its category or collection, search for it, select its options and follow the agreed checkout journey. Confirm prices, images, stock behaviour and the resulting order information. Use the business’s permitted test method and explain any real charge in advance; a migration test should not create unexplained orders.
Where public URLs change, maintain a mapping to the relevant new destination and test representative redirects. Google’s migration guidance supports planning those mappings and monitoring the move. Avoid treating every removed item as a reason to redirect to the homepage, and do not promise that a redirect file alone guarantees unchanged rankings.
Separate catalogue data from historic customer operations
A product migration is not automatically a migration of orders, invoices, customer passwords, gift cards, reviews, subscriptions or connected apps. Specify each required data type and how it can be exported and represented in the new platform. Never invent replacement customer data to make a demo look complete.
The current ZoopCoder store-migration scope caps the included product work and separately excludes order history, past invoices and customer purchase records. It also separates plan or hosting costs and domain cutover. Read those live limits before checkout, then request a tailored quote for records or integrations outside them.
Use a pilot to settle the unknowns
A practical pilot contains one simple product, one item with variants, one with several images and one awkward existing record. These are suggested test categories, not a fixed platform requirement. Compare the source and destination, document transformations and obtain approval before the full catalogue is processed.
Your handover should include the mapping, exceptions, backup/export locations and a short explanation of any manual steps left for staff. We publish this guide as a migration service provider. It is intended to make scope and acceptance evidence clearer, not to imply that all stores or third-party apps support identical transfers.
Questions before you commission the work
Is a product CSV enough to migrate an entire store?
No. The file may cover product data, while themes, customers, historical orders, apps, URLs and operational settings require separate scope.
Why should products and variants be counted separately?
Different products can require very different record, image and option work. Define the quoted unit and inspect representative examples.
Should the full catalogue be imported before testing?
A small representative pilot is a useful way to settle mapping and overwrite rules before processing the full agreed dataset.
Sources and scope
Primary documents checked 3 November 2026. The commissioning tables and sample briefs are editorial suggestions, not platform requirements or measured client outcomes. Live service pages govern the current price and included work.