Variants, options and attributes: what the Converter does

Take Atelier Démo’s Pull Démo sweater: three sizes (S, M, L) and two colours (Ecru, Indigo), so six sellable versions, each with its own price, SKU and stock. Atelier Démo moves it from WooCommerce to Shopify.

Three words for the same idea

A variant is a sellable version: “M, Indigo”. An option is the axis that sets variants apart: “Size”, with the values S, M and L. WooCommerce speaks of attributes: an attribute used for variations plays the role of an option; the others only describe the product, like “Material: wool”. The Converter always goes through the same form: a product, its options, and its variants, each with one value per option.

What the Converter reads

Shopify: the rows of a product share the same Handle, and options are in the Option1 Name to Option3 Value columns. WooCommerce: the variable product is followed by its variation rows, attached by Parent. An attribute becomes an option only if every variation gives it a value; otherwise it stays a descriptive attribute. If the “M, Indigo” variation leaves the colour empty, “Colour” is therefore not an option of the Pull Démo.

Wix: one PRODUCT row, then one VARIANT row per variant; from a colour value, the Converter keeps the name and sets the colour code aside. BigCommerce: Variant rows follow their Product row, and the Converter files the values of the Options column by option name, whatever their order.

What it writes

To Shopify, one row per variant, and an option is written only if every variant has a value for it. If not, the Review step says: “Variant with no option value: repaired as a per-variant title.” If no complete option is left, each variant gets its own title: its SKU or a number.

To WooCommerce, a variable product, then one variation row per variant, attached by the parent’s SKU. A product with variants and no parent SKU gets one, built from its reference or its name: this is the Parent SKU generated box at the Mapping step. Descriptive attributes follow the options; one that carries an option’s name is not written twice, and the Review step says so.

To Wix, one PRODUCT row, one VARIANT row per variant, then the images; options become text choice lists: “Option type (color…) is not carried by Wix.” To BigCommerce, one Variant row per variant under the Product row, with its options as a drop-down list and stock tracked per variant.

Shopify and Wix limit the number of options, values or variants per product. Beyond that, the Review step says how many products are concerned: extra options are not written; variants are all written, and the Review step warns that the platform will refuse those products. Apart from Eloshon Scraper files, whose options read on a page it can combine, the Converter creates no variant.

Variant stock

In the Preview of converted rows box at the Mapping step, the Variant stock list offers three choices. Quantities from the original file keeps your file’s quantities: this is the default for a store export. Quantities removed removes the quantities: every variant stays for sale, except to BigCommerce, which keeps tracking per variant with an empty stock. Quantities kept, selling beyond them (Shopify, WooCommerce) keeps the quantities and accepts orders beyond them, to Shopify and WooCommerce only.

A changed choice is remembered for the target platform and then applies to every file converted to it: check it at each conversion. From a Shopify export, the setting that lets a variant sell beyond its stock is not read today: choose Quantities kept, selling beyond them (Shopify, WooCommerce) if your variants must stay for sale once sold out.