Guide · Export

Export

Every export is written so that it can be edited in a spreadsheet and imported straight back. The column names are exactly the ones the importer reads, which is the whole point: an export is the easiest way to get a correct file to start from.

Pick an entity, then a scope

Choose the type from the grid — or the New export menu — and the dialog asks for a scope. "All" means the whole set; the others narrow it before anything is read, so a filtered export is genuinely smaller rather than trimmed afterwards.

CSV or Excel

In the spreadsheet every value is text, deliberately. A SKU like 0012345 stays as it is instead of becoming 12345 — which is what Excel does the moment it decides a cell is a number, and would make a re-import address a different product.

It runs in the background

• Starting an export queues it. The row appears immediately as Pending, becomes Processing…, then Completed or Failed.
• You can leave the page. The file is built server-side; come back later and download it from Export history.
• One export per entity at a time. While one is running, that entity's tile is dimmed and marked running.
• A completed export with zero rows has no file to download — the action column says so instead of offering a dead button. That normally means the scope matched nothing.
• A failed export shows View error with the upstream message. Nothing partial is left behind; start it again.

Files open correctly in Excel

Every file is written with a UTF-8 byte-order mark, so Excel shows accented and non-Latin text properly instead of mangling it. The importer strips that mark again on the way back in, so a round trip is clean.

Files are streamed to disk as they are built rather than assembled in memory, so a large catalog does not depend on how much memory the server has.

Warnings on a completed export

An export can succeed and still have something worth telling you. When it does, the row carries a warning icon:

• Products with no SKU. They export fine, but a file that identifies rows by SKU cannot re-import them — they are matched by name, UPC, MPN or variant id instead.
• Custom fields sharing a name. BigCommerce allows two; a spreadsheet column cannot hold both.
• A metafield read that failed. The rest of the export is intact; only those columns are missing.
• A filtered category export whose parents were not selected. Those rows only re-import into a store that already has the parent categories.
• A page whose type cannot be written back. The Blog Index page is reported by BigCommerce with a type the write side refuses, so its Type cell is left blank deliberately — otherwise re-importing would fail that row every time.
• A customer group with more than one discount rule. A row expresses one, so the export says which groups have more rather than silently losing the rest.
• A store with more than one category tree. Categories do not report which tree they belong to, so the export cannot record it — and says so rather than leaving you to guess.

What a products export brings with it

A product export is not just the product row. It carries variants, images, custom fields, metafields, quantity breaks, modifiers, options and videos, spread across the same continuation-row shape the importer reads:

• one row per product, then one row per real variant;
• lists — extra images, quantity breaks, modifier values — ride on continuation rows that repeat the Product ID and SKU;
• custom fields and metafields become their own columns named after the data, so the header depends on what your catalog actually uses.

BigCommerce's synthetic base variant — the one products without options carry — is skipped, because it is not a variant anyone edits.