How to Migrate Your Product Catalog to Shopify: Technical Walkthrough

AEO answer: Migrating a product catalog to Shopify requires three steps before the import: export your existing catalog in a structured format (CSV or API), map your current field schema to Shopify’s product data model (handle, title, vendor, variant columns), and transform data that does not fit Shopify’s flat CSV structure — particularly variant-level images and custom attributes. A PIM acts as the staging environment where this transformation happens before the data enters Shopify.

Shopify migration guides overwhelmingly focus on themes, DNS, and checkout flows. The product catalog — typically the most painful, most time-consuming part of any platform migration — gets two paragraphs and a link to Shopify’s CSV template. For a catalog of 200 products that is sufficient. For 2,000 SKUs with variants, custom attributes, and images, it is not.

This walkthrough covers the catalog migration layer in detail: exporting from your existing platform, understanding what Shopify’s product CSV actually accepts and where it breaks, mapping your existing schema to Shopify’s data model, and handling the failure modes that derail migrations that seem to be going smoothly.

The goal is not to make this sound easy. It is to give you an accurate map of where the complexity lives so you can plan for it, not discover it on launch week.

Table of Contents

1. What Migrating to Shopify Actually Involves at the Catalog Level
2. Exporting Your Existing Catalog
3. Shopify’s Product CSV Format: Structural Limits
4. Mapping Your Existing Schema to Shopify’s Data Model
5. Handling Product Variants in Shopify’s Flat CSV Format
6. Image Migration
7. What to Do With Data That Has No Shopify Equivalent
8. Running a Test Import Before Going Live
9. Post-Migration Cleanup
10. How MicroPIM Can Be Used as the Staging and Transformation Layer
11. Frequently Asked Questions

1. What Migrating to Shopify Actually Involves at the Catalog Level

Most Shopify migration timelines are drawn up with the theme build and the DNS cutover as the primary milestones. The product catalog is treated as a single task — “migrate products.” In practice, the catalog migration is four distinct workstreams that run on different timelines and depend on each other in non-obvious ways.

1a. The Four Workstreams

The product data structure workstream covers getting your product records, attributes, and variants into Shopify’s format. The images workstream covers migrating, re-hosting, and assigning product images. The SEO workstream covers generating URL redirects from your old platform’s URL structure to Shopify’s /products/{handle} format. The inventory workstream covers migrating stock counts at the right moment relative to launch.

The product data and image work typically represents 70–80% of total catalog migration effort for a large catalog. The SEO redirect work is a separate operation that can proceed in parallel. Inventory migration must happen as close to launch as possible to avoid snapshot staleness — not weeks ahead of time alongside the product data.

1b. Timing Requirements

Attempting all four workstreams in a single Shopify CSV import will fail. Shopify’s CSV does not carry URL redirects, metafields, or inventory in a way that handles all four workstreams simultaneously. The inventory columns in Shopify’s CSV are written at import time and become stale immediately afterward — a catalog imported three weeks before launch with inventory columns populated will have incorrect stock counts on launch day.

Illustrative data — see cited source for benchmarks.

[DIAGRAM: Shopify migration timeline — horizontal swimlane diagram showing the four workstreams (Product Data, Images, SEO Redirects, Inventory) mapped across a 6-week migration timeline with dependencies and critical path highlighted]

[INTERNAL LINK: → /blog/sku-management-scale — the attribute schema design decisions that determine how cleanly this migration will go]

2. Exporting Your Existing Catalog: Sources and Formats

Your migration starts with getting product data out of wherever it currently lives. Each platform exports differently, and the quality and completeness of what you get out determines the difficulty of what comes next.

[CITE: WooCommerce product export documentation — woocommerce.com/document/product-csv-importer-exporter/ — the specific fields available in WooCommerce’s built-in exporter]

[CITE: Magento 2 import/export documentation — docs.magento.com/user-guide/system/data-import.html — the attribute set export limitation is documented here]

[E-E-A-T NOTE — Experience]: Add a practical note for Magento migrations: “In practice, teams migrating from Magento with multiple attribute sets should run one export per attribute set and merge files into a unified schema before mapping to Shopify — doing it in a single export produces misaligned columns where one attribute set’s columns are blank for all other attribute sets.” This kind of operational detail cannot come from documentation alone — it signals first-hand migration experience.

2a. WooCommerce

WooCommerce’s built-in product CSV exporter covers most standard product fields. Custom fields (product add-ons, plugin-specific metadata) require a dedicated plugin export or a database query. Images export as URLs pointing to the old domain — you will need to update these URLs to the new location before the Shopify import. Variable products export as a parent row and multiple child rows; how this maps to Shopify’s flat multi-row variant structure requires transformation.

2b. Magento

Magento’s catalog import/export tool exports products as CSV, but the attribute set system complicates the process. Different attribute sets produce different column configurations — an apparel product and an electronics product in the same export will have columns that are populated for one category and empty for the other. For large migrations with multiple attribute sets, run one export per attribute set, normalize the column headers to a common schema, then merge into a single file before mapping to Shopify. Configurable products (Magento’s variant product type) export as a parent record and separate simple product children — these must be restructured into Shopify’s flat multi-row variant format.

2c. Custom Platform or ERP

Custom platforms and ERPs typically require a database query or API export. The output format is platform-specific and will vary in completeness. This is where a PIM as a staging layer pays for itself most clearly: ingest the raw export in whatever format it arrives, use the PIM’s field mapping to normalize it, and output Shopify-ready data from a clean, standardized intermediate format.

2d. BigCommerce

BigCommerce’s export format is structurally the closest to Shopify’s — both use a flat CSV with similar column conventions. The migration still requires field renaming and variant restructuring, but the base structure is more compatible than a Magento or WooCommerce export. Custom attributes defined as product specifications in BigCommerce may need to be reconfigured as metafields in Shopify.

[INTERNAL LINK: → /blog/csv-xml-field-mapping — the field mapping process for aligning your export format to Shopify’s required columns]

3. Shopify’s Product CSV Format: What It Accepts, What It Does Not, and Its Structural Limitations

Shopify’s CSV format has specific structural requirements that are not intuitive if you have only worked with other platform CSV exports. The flat row structure, the handle-as-identifier behavior, and the 3-option variant limit are all potential blockers that should be understood before the first import attempt.

[E-E-A-T HOOK — Citation needed]: Every structural claim in this section should be traceable to Shopify’s official documentation. Cite: help.shopify.com/en/manual/products/import-export/using-csv (Shopify product CSV format), shopify.dev/docs/api/admin-graphql (GraphQL Admin API for metafields and post-import operations). Do not rely on reader trust — link to the spec directly.

[E-E-A-T HOOK — Authority]: Note that the 3-option-per-product variant limit is a hard platform constraint enforced by Shopify, not a recommendation. Citing the official source for this limit distinguishes this article from advice columns that treat it as configurable.

3a. The Flat Row Structure

Shopify’s CSV represents hierarchical product/variant data in flat rows. Each row is one variant. Product-level fields (title, vendor, product_type, body_html) are repeated on every variant row for the same product. A product with three variants occupies three rows. The first row carries all product-level fields plus the first variant’s data. Rows two and three carry the variant-differentiating data only — all product-level fields are blank on non-first rows. An import that populates product-level fields on all variant rows will either create duplicate products or generate import errors depending on Shopify’s version.

3b. Key Column Behaviors

The handle field is simultaneously the URL slug for the product page (/products/{handle}) and the record identifier used by Shopify’s import engine. If you import a row with a handle that already exists in the store, Shopify updates the existing product rather than creating a duplicate. If you change a handle, the old URL returns a 404 unless a redirect is in place. Handles must be lowercase, hyphen-separated, and unique within the store.

Variant columns use the pattern Option1 Name, Option1 Value, Option2 Name, Option2 Value, up to a maximum of 3 option dimensions per product. This is a hard platform limit — Shopify enforces it and the CSV format cannot work around it. Products requiring more than 3 option dimensions must either be restructured or listed as separate products.

Images are handled via Image Src (the product’s primary image) and Variant Image (the image shown when a specific variant is selected). The variant image assignment requires correct row ordering — the URL on a given row is assigned to the variant on that same row.

3c. What the CSV Cannot Carry

Shopify’s product CSV has no native columns for metafields. Any custom attribute in your source system that does not map to a standard Shopify field — the named columns in the CSV template — is silently dropped during import. This includes technical specifications, compliance certifications, B2B pricing tiers, product relationships, and custom ERP identifiers. These require the Shopify Admin API after the CSV import.

[INTERNAL LINK: → /blog/shopify-migration-failures — deep dive on each of these structural limitations as failure modes]

4. Mapping Your Existing Product Schema to Shopify’s Data Model: A Field-by-Field Reference

Before mapping, you need to understand the destination. Shopify’s data model divides product information across standard fields (native CSV columns), option/variant fields (the 3-option system), tags (for filterable attributes that don’t fit the option structure), and metafields (for everything else that needs to be stored but has no native CSV column).

4a. The Mapping Challenge

Your source schema almost certainly has more attribute types than Shopify’s native CSV supports. A Magento product with 20 attributes needs explicit decisions about where each attribute lands in Shopify’s structure. The mapping strategy: standard fields first, then options/variants, then tags for filterable attributes that don’t fit the 3-option limit, then plan the metafield population step via API post-import.

4b. Mapping Strategy

Map the high-visibility attributes to standard fields first. Title, vendor (brand), product_type, and body_html (description) are the baseline. Then map your variant dimensions to the 3 option slots — if you have more than 3 variant dimensions, decide which 3 matter most and restructure the rest. Attributes that customers use to filter but are not variant dimensions (material, style, season) can become tags. All remaining custom attributes go to metafields, which means a separate post-import API step.

5. Handling Product Variants in Shopify’s Flat CSV Format

The variant handling in Shopify’s CSV format is the most common source of import errors in migrations from WooCommerce, Magento, and Magento-adjacent systems. The row ordering requirement in particular is not documented clearly in Shopify’s own migration guides, and it is the failure mode that catches everyone the first time.

[E-E-A-T NOTE — Expertise depth, missing specifics]: Section 5c states the 3-option limit but does not state the 100-variant-per-product limit. Both are hard limits. Add: “Shopify also enforces a maximum of 100 variants per product (the product of all option combinations). A product with 4 sizes × 3 colors × 3 materials = 36 variants fits. A product with 5 × 5 × 5 = 125 variants exceeds the limit and must be split.”

[CITE: Shopify product variants — shopify.dev/docs/api/admin-graphql/2024-01/objects/Product#field-product-variants — the official API documentation listing the 3-option / 100-variant limits as enforced constraints]

[QUOTE: Seek a practitioner quote from someone who has executed a Magento-to-Shopify or WooCommerce-to-Shopify migration at scale — e.g., “The row ordering issue cost us a full day in the migration — no error was thrown, but 40% of our color variants were showing the wrong product image. You only catch it by visually checking each variant in the admin.”]

5a. The Row Structure Requirement

In Shopify’s CSV, a product with 3 variants occupies exactly 3 rows. The first row carries all product-level fields AND the first variant’s data. Rows 2 and 3 carry only the variant-differentiating data — all product-level columns (Title, Body, Vendor, Product Type, Tags) are left blank on non-first rows. An import tool that naively exports every field on every row will either create duplicate products (if each row’s handle is unique) or overwrite the previous row’s data repeatedly (if the handle is the same on all rows).

5b. Variant Image Row Ordering

The Variant Image URL must appear on the exact row corresponding to that variant. Shopify reads the Variant Image column positionally: the URL in row 1 of a product’s rows is assigned to the variant whose option values appear in row 1. If the variant rows are in the order S/M/L/XL but the image URLs are ordered XS/S/M/L because the source platform had an additional size, every image assignment will be wrong by one row. There is no error. The import succeeds. The only way to catch this before launch is to visually verify each variant’s image in the Shopify admin after a test import.

5c. The 3-Option Limit

Shopify enforces a maximum of 3 option dimensions per product (for example, Size, Color, and Material). The platform also enforces a maximum of 100 variants per product — the product of all option combinations. A product with 4 colors × 5 sizes × 3 materials = 60 variants falls within the limit. A product with 5 × 5 × 5 = 125 variants exceeds it and must be split. Products requiring more than 3 option dimensions must be restructured before import — either by listing the product multiple times (with different option combinations) or by encoding some options as tags or in the product title.

5d. Converting From Parent-Child Exports

A WooCommerce variable product exports as one parent row and one child row per variation. A Magento configurable product exports as one parent record and separate simple product children. In both cases, the source uses a hierarchical structure that must be converted to Shopify’s flat multi-row format. The parent’s attributes need to be repeated (in Shopify terms, they appear only on the first row; subsequent rows carry variant data). The child rows need to be sorted to match the intended variant image assignment.

[CODE: Example — converting a WooCommerce variable product XML export to Shopify CSV variant rows]

# WooCommerce variable product export structure (simplified):
# Parent: ID=1001, sku=SHIRT-BLUE, name="Classic Polo", type=variable
# Child: ID=1002, parent=1001, sku=SHIRT-BLUE-S, size=S, color=Blue, price=29.99, image=shirt-blue-s.jpg
# Child: ID=1003, parent=1001, sku=SHIRT-BLUE-M, size=M, color=Blue, price=29.99, image=shirt-blue-m.jpg
# Child: ID=1004, parent=1001, sku=SHIRT-BLUE-L, size=L, color=Blue, price=34.99, image=shirt-blue-l.jpg

# Resulting Shopify CSV rows (flat format):
Handle,Title,Body (HTML),Vendor,Product Type,Tags,Option1 Name,Option1 Value,Option2 Name,Option2 Value,Variant SKU,Variant Price,Variant Image,Image Src
classic-polo,"Classic Polo","<p>100% cotton polo shirt</p>","BrandName","Tops","polo,cotton","Size","S","Color","Blue","SHIRT-BLUE-S",29.99,"https://cdn.example.com/shirt-blue-s.jpg","https://cdn.example.com/shirt-blue-s.jpg"
classic-polo,,,,,,,"M",,"Blue","SHIRT-BLUE-M",29.99,"https://cdn.example.com/shirt-blue-m.jpg",
classic-polo,,,,,,,"L",,"Blue","SHIRT-BLUE-L",34.99,"https://cdn.example.com/shirt-blue-l.jpg",

# Note: Product-level fields (Handle, Title, Body, Vendor, etc.) populated ONLY on first row
# Variant Image URL must appear on the SAME ROW as its corresponding variant option values

[INTERNAL LINK: → /blog/variants-multilingual — the three-tier parent-variant-locale data model that a PIM uses to manage variant complexity before export]

6. Image Migration: Hosting, CDN URLs, and Shopify’s Image Import Behavior

Images are where migrations stall. The product data import succeeds but launches with broken images, or images assigned to the wrong products, or images that disappear after the old hosting is decommissioned.

6a. How Shopify Imports Images

Shopify imports images by URL at the time the CSV import runs. The image must be publicly accessible — returning a 200 HTTP status — at the exact moment Shopify’s import process fetches it. Images behind authentication, session-specific signed URLs, or on hosts that block Shopify’s import IP range will fail silently.

6b. Three Image Migration Options

Option A: Keep images on old hosting until post-migration, then re-import or re-host. Simple to execute — no pre-migration image work. The risk: creates a dependency on the old infrastructure staying live and accessible after the DNS cutover. If the old hosting is decommissioned before image re-hosting is complete, Shopify cannot fetch replacement images.

Option B: Migrate images to a CDN or object storage first, update image URLs in the CSV to the new location, then import. Cleaner — Shopify’s import fetches from a permanent host, and the old infrastructure can be decommissioned on its normal schedule. Adds a pre-migration step: export images, upload to new CDN, update URLs in the product data file before the Shopify import.

Option C: Import with old URLs, let Shopify copy the images, then decommission the old host. This is Shopify’s recommended approach — Shopify copies images to its own CDN during import, so post-import the images are hosted by Shopify and the old host can be decommissioned. The failure mode: if old image URLs are behind authentication (common with Magento’s media storage) or return session-specific signed URLs, Shopify cannot copy them during import.

6c. Alt Text

Shopify’s CSV has an Image Alt Text column. Populate it during the migration rather than retroactively — alt text affects both accessibility and SEO, and adding it after launch requires an API-based update for every product image. Most source platform exports do not include image alt text; you will need to generate it during the migration step, typically by constructing it from the product name, category, and image position.

7. What to Do With Data That Has No Shopify Equivalent

Shopify’s native CSV covers the product data that Shopify’s standard admin interface manages. Everything else requires either a workaround or a post-import API operation.

7a. Custom Attributes

Technical specifications, compliance certifications (CE marking, RoHS, safety ratings), care instructions beyond what fits in body_html, and B2B-specific fields have no native Shopify CSV column. The correct approach is metafields, populated via the Shopify Admin API’s GraphQL metafieldsSet mutation after the CSV import. This is a separate scripted step, not part of the CSV import workflow.

7b. Product Relationships

Cross-sell, upsell, accessories, and replacement parts relationships have no native equivalent in Shopify’s data model. Options: store related product handles in a metafield and surface them via a theme section that reads the metafield; use a third-party app that provides a native “related products” data structure; or accept that these relationships will not be migrated and recreate them manually post-launch.

7c. Tiered Pricing

Customer-group pricing and tiered volume pricing are not part of Shopify’s standard CSV or API. Shopify Plus stores can implement custom pricing via Functions. Standard Shopify stores require a third-party B2B or wholesale app. This is a separate platform decision that should be resolved before the migration rather than during it.

7d. Decision Framework

For each attribute without a Shopify equivalent, evaluate: Is it customer-facing? If yes, consider body_html (for descriptive content) or a metafield (for structured data surfaced by the theme). Is it used for filtering? If yes, consider tags. Is it used only for internal operations? Consider a metafield used only by admin, not displayed to customers. Is it a regulatory or compliance field? Document it in a metafield with a defined namespace so it is retrievable for compliance reporting.

8. Running a Test Import Before Going Live: Shopify’s Sandbox and Validation Process

Running a test import on your actual Shopify products is not optional for a catalog of 200+ products. It is the step that reveals every assumption that was wrong about the field mapping, the variant structure, and the image configuration before those errors go live to customers.

[E-E-A-T HOOK — Risk callout]: Running a test import on your live production store — even in draft mode — carries risk if product handles collide with existing records. Use a Shopify Development Store (available free through Shopify Partners at partners.shopify.com) for all test imports. Never treat the first import of 2,000+ SKUs as a test inside a live store.

[E-E-A-T HOOK — Experience]: Add a real migration timeline from a MicroPIM customer: “A [N]-product migration from [platform] required [X] test import cycles before a clean pass — the most common failure was [failure type]. Here is what we learned.” Do not invent; leave as hook if no data is available yet. [INTERNAL LINK: → /study-cases]

8a. Shopify’s Test Environment

Shopify does not have a staging environment attached to production stores. The test environment is a separate Shopify Development Store — available free to anyone with a Shopify Partners account — or a separate paid store kept in password-protected mode. Development stores allow unlimited test imports without risking production data. Use a development store for all test import cycles.

8b. How to Validate a Test Import

Import a representative sample — 5 to 10 products specifically chosen to cover every product type, every variant configuration, and every edge case in your catalog. A product with 3 option dimensions at the maximum. A product with a long description containing HTML. A product with per-variant images. After import, check every field on every product in the Shopify admin — not just the product list view. Pull up individual product pages and expand each variant.

8c. Reading the Error Log

Shopify’s import error log is accessible in the admin after import completes. It lists rows that were skipped or partially imported, with an error description. The error descriptions are not always specific: “Row 47 failed: invalid value for Variant Price” is actionable; “Row 47 failed to import” is not. For ambiguous errors, the fallback is to isolate the failing row, simplify it to its minimum required fields, and re-import to determine which specific column value triggered the error.

8d. Deduplication Before Each Test Run

Delete all test products from the development store between test import cycles. If you re-import without deleting, Shopify will either update the existing products (if handles match) or create duplicates (if handles differ). Both behaviors mask failure modes — an update does not test the “create new product” path, and duplicates inflate the product count and obscure what the next test is actually checking.

9. Post-Migration Cleanup: Duplicate Detection, SEO Redirects, and Metafield Population

The import reaching “100% complete” is the halfway point, not the finish line. Three post-import tasks are required before the migration is done.

[CITE: Shopify URL redirect bulk CSV import guide — help.shopify.com/en/manual/online-store/menus-and-links/url-redirects#import-redirects-from-a-csv-file — the authoritative reference for the redirect import method described in section 9b]

[CITE: Shopify GraphQL Admin API metafields — shopify.dev/docs/api/admin-graphql/2024-01/mutations/metafieldsSet — the official mutation reference for the post-import metafield population step in section 9c]

[E-E-A-T NOTE — Missing failure mode]: Section 9a (duplicate detection) does not mention the most dangerous duplicate scenario: two products with the same title but different handles where one was created from a test import and one from the real import. A product count that exactly matches your source system does not rule out duplicates — a product deleted and re-imported gets a new handle and a new ID, while the old product may still exist if the deletion was not confirmed. Export the full product list and diff against the source system by handle, not just by count.

9a. Duplicate Detection

Export the complete product list from Shopify immediately after import. Sort by title. Identify rows where the same title appears twice with different handles. Compare total product count against the source system export. If the count is higher than expected, investigate before proceeding — the extra products are likely test import artifacts or handle variants created by encoding differences between export runs. Do not launch with duplicate products in the catalog.

9b. SEO Redirects

Every URL that existed on your source platform and has been indexed by Google needs a 301 redirect to its new Shopify equivalent. Shopify’s URL redirect bulk import accepts a CSV with two columns: old URL and new URL. Generate this redirect map by exporting your source platform’s URL list and constructing the corresponding Shopify /products/{handle} paths. Import the redirect CSV before DNS cutover — not after. Redirects installed after launch do not prevent the indexing damage from 404s during the DNS window.

9c. Metafield Population

All custom attributes that could not be carried in the CSV require a post-import API step. The Shopify GraphQL Admin API’s metafieldsSet mutation accepts metafield key, value, namespace, and type. This step can be scripted in any language that can make HTTP requests, or handled via a PIM’s Shopify connector that includes metafield sync as part of the channel publish workflow. This step should be planned before the migration, not improvised after.

10. How MicroPIM Can Be Used as the Staging and Transformation Layer

A PIM solves the structural complexity of the Shopify migration by providing a transformation environment between your source platform and Shopify. The migration work that would otherwise be done in spreadsheets and scripts is done in a system that saves the configuration for ongoing use.

Import your source catalog into MicroPIM in its native format — WooCommerce XML, Magento CSV, BigCommerce CSV, or any structured format. Use MicroPIM’s field mapping interface to align your existing schema to Shopify’s required columns: map source fields to Shopify targets, define transformation rules, set fallback values. Handle variant restructuring within MicroPIM — the parent-variant data model organizes your products into the structure Shopify expects before export, so the flat CSV rows are generated correctly with proper ordering. Export a Shopify-ready CSV directly from MicroPIM, validated against Shopify’s requirements, with correctly ordered variant rows and image URL assignments.

The argument for this approach extends beyond the migration: after the data is in Shopify, MicroPIM becomes the ongoing PIM, with Shopify as a connected publishing channel. Future catalog changes — new products, updated descriptions, price changes — flow from MicroPIM to Shopify without repeating the migration work. The transformation configuration built during the migration is reused indefinitely.

[CTA — after intro (soft): “Planning a Shopify migration? See how MicroPIM handles the field mapping and variant restructuring before your data reaches Shopify.” [INTERNAL LINK: → /how-it-works]]

[CTA — after section 5 (medium): “MicroPIM exports correctly ordered Shopify CSV rows for variant-image assignments automatically. Try it free with your catalog.”]

[CTA — after FAQ (hard): “Use MicroPIM as your Shopify migration staging environment — import from any format, clean and map, export to Shopify-ready CSV. Then keep MicroPIM as your ongoing catalog system.”]

Frequently Asked Questions

Schema note: Mark this section with FAQPage JSON-LD. Each H3 question + answer pair maps to one FAQPage mainEntity item.

How long does a Shopify product catalog migration take?

A clean Shopify catalog migration takes 1–2 weeks for 500 products and 6–10 weeks for 5,000 products with custom attributes. The bottleneck is not the import itself but the data preparation: field mapping, test import cycles, and post-migration cleanup (duplicate detection, SEO redirects, metafield population). Catalog quality at the start is the single biggest factor — well-structured data with consistent attribute naming and complete required fields cuts migration time by 50% or more compared to a legacy catalog with inconsistent data.

What is Shopify’s product CSV handle field?

The handle is the URL slug for the product page (/products/{handle}) and the unique record identifier used by Shopify’s CSV import. If you import a handle that already exists in the store, Shopify updates the existing product rather than creating a duplicate. If you change a handle, the old URL returns a 404 unless you set up a redirect. Handles must be lowercase, hyphen-separated, and unique within the store — Shopify auto-generates handles from product titles if the column is left blank, but auto-generated handles may not match your intended URL structure.

How many product variants does Shopify support per product?

Shopify supports a maximum of 3 option dimensions per product (for example, size, color, and material). Each combination of option values creates one variant. The maximum number of variants per product is 100. Products requiring more than 3 option dimensions must be restructured — either listed as separate products or with some options encoded in tags or the product title rather than as option dimensions.

Do I need to migrate inventory at the same time as product data?

No — and it is best practice to separate them. Import product structure, descriptions, and images first, leaving the Variant Inventory Qty column blank or zeroed. Then run a separate inventory import as close to launch as possible using actual stock counts from your ERP or WMS. Shopify treats product records and inventory levels as separate objects (ProductVariant and InventoryLevel) and they can be updated independently. Migrating inventory weeks ahead of launch guarantees stale stock counts on the day.

What product data cannot be imported via Shopify’s CSV?

Shopify’s product CSV cannot carry: metafields (custom attributes beyond the named columns), product relationship data (cross-sells, upsells, accessories), B2B pricing tiers, file attachments, and some Shopify-specific configuration (sales channel assignments, gift card settings). These require the Shopify Admin API (REST or GraphQL) after the CSV import, or a PIM with a dedicated Shopify connector that handles metafield population as part of the publish workflow.

Can I test a Shopify import without affecting my live store?

Yes. Use a Shopify Development Store (available free with a Shopify Partners account) for all test imports. Development stores do not require a paid subscription. Import your test products, validate the results, and run as many test cycles as needed before touching the production store. Delete test products between runs to avoid a mix of test and production records that would make the final product count comparison unreliable.

Estimated word count: 3,000