How to export your data from BigCommerce before the contract ends
If you must get catalog and store data out of BigCommerce before a renewal, a pricing change or a move to a self-hosted platform, start with the product export. Product data can be exported from Products, Export using the built-in Bulk Edit and Default templates or a custom template created under Settings, Export Templates. For catalogs above 1,000 products, save the export to your store's WebDAV folder and download it from there, and use the Catalog API when you need images, variants, custom fields or metafields in a structured form. Customer and order exports are a different matter: confirm in your own admin, and with BigCommerce support if needed, which customer and order files your plan and template set produce, and what fields they include, before you rely on them.
Treat the CSV as the format to use. BigCommerce recommends CSV for product exports because other file types cannot be imported back into a store, and it sorts CSV exports by product ID, which helps when you check row counts against your catalog. Run a test export, reimport it into a sandbox or the destination platform's staging environment, and compare counts for products, variants and categories. Note which fields are missing from the file, such as image binaries, custom field values or bulk pricing rules, and plan a separate extraction for each. Ask your current agency or developer to document the templates they used so the export can be repeated near the end date.
The export is only one part of an exit. Product images, SEO URLs, redirects, app data, payment tokens, order history used for returns, tax settings and the storefront theme all need their own plan. Confirm with your processor how stored payment credentials will be transferred or re-collected, and check whether your contract sets a data retention or deletion obligation after termination. Ask the vendor in writing which export formats and API access remain available during the notice period and after the account closes. A written exit inventory of what is exportable, what needs a workaround and who owns each item will shorten the migration and reduce the risk of losing data you still need.
What you can export from BigCommerce and how
This table compares what BigCommerce lets you pull out of a store, the export route for each data type and the format to use. Read it as a checklist: the product export has built-in and custom templates, while the Catalog API covers objects the admin export does not handle cleanly. The main takeaway is to keep CSV as the working format and to confirm current customer and order export options in your own admin before you plan the extraction.
| Data or object | Export route | Format and notes |
|---|---|---|
| Products (admin export) | Products, Export, using the built-in Bulk Edit or Default template, or a custom template under Settings, Export Templates | CSV is the recommended format. CSV exports are sorted by product ID. |
| Products (XML option) | Same export screen, with XML selected | XML is supported, but BigCommerce recommends CSV because other file types cannot be imported back into a store. |
| Large product exports | Save the export to the store's WebDAV folder for later download | BigCommerce recommends this route for exports of more than 1,000 products at a time. |
| Catalog objects via API | Catalog API for products, categories, brands, bulk pricing rules, variants, images, custom fields and metafields | Programmatic extraction. Plan your calls within the rate limits of your plan and confirm the current limits in BigCommerce docs. |
| Customers | Confirm current customer export options in the admin and the BigCommerce Help Center | Keep the export in CSV so it can be re-imported if needed. Check which fields are included before you rely on the file. |
| Orders | Confirm current order export options in the admin and the BigCommerce Help Center | Keep order history in CSV alongside products. Verify which order and line item fields the export returns. |
| Product images | Download from the image URLs returned by the Catalog API or product data | Images are a separate step. Keep the original store live until your new store has imported images from their URLs. |
Which export route fits your catalog size and data type
This route suits a store owner or merchandising lead who can run exports from the BigCommerce admin under Products, Export. Built-in templates such as Bulk Edit and Default cover most catalog fields, and a custom template created under Settings, Export Templates lets you limit columns to what the new platform needs. The store team needs admin access with product export rights and a decision on which template to use before starting.
- Output format: Choose CSV. BigCommerce supports CSV and XML, but recommends CSV because other file types cannot be imported back into a store.
- Sort order: CSV exports are sorted by product ID, so compare row counts against the live catalog rather than assuming a particular order.
- Template choice: Confirm whether the Bulk Edit or Default template includes variants, custom fields and images references that your target platform will need.
- Customers and orders: Product exports do not replace customer or order exports, which need their own files.
- Image handling: Export image URLs and confirm the files stay reachable until the new store has imported them.
Check the file row by row against a sample of live products, including variants, prices, SKUs, categories and any custom fields, before treating the export as final.
This route suits a store team with a larger catalog that cannot be exported comfortably in one admin download. BigCommerce recommends saving exports of more than 1,000 products at a time to the store's WebDAV folder, then downloading the file later. The store team needs an admin user who can run the export, access to the WebDAV folder with credentials, and enough time for the file to generate before download.
- Where the file goes: Select the WebDAV folder as the export destination so the file is stored on the store rather than in the browser session.
- Download step: Confirm who holds WebDAV access and that the download is recorded in your migration log.
- Template consistency: Use the same custom template for every export run so column names match across files.
- Versioning: Keep each export dated and separate so a later re-export can be compared against the first run.
- Access control: Limit WebDAV credentials to the migration team and remove them after cutover.
Before relying on the file, open it in a spreadsheet tool that handles large CSVs without truncation, and check that the product count matches the admin count.
This route suits a developer or integration engineer who needs data the export templates do not cover, such as categories, brands, bulk pricing rules, variants, images, custom fields or metafields. The BigCommerce Catalog API manages these objects and gives a programmatic path for extraction. It is subject to the rate limits that apply to your store plan, so extraction jobs need pagination, retries and a schedule that keeps within those limits.
- Who runs it: An engineer with API credentials scoped to read the catalog objects you need.
- What it produces: JSON responses that you transform into the target platform's import format, typically kept in version control with the job code.
- Rate limits: Check the limits for your plan before the first full run, and build backoff into the script.
- Related objects: Extract categories and brands before products so references can be resolved on import.
- Scope of credentials: Use read-only scopes for extraction and rotate the token after the migration.
Compare record counts from the API with the admin counts for each object type, and keep a sample of raw responses to prove what was extracted.
This route covers the customer and order data that product exports leave out. Customer and order records carry personal data, so the store team should agree on retention, access and transfer rules with the data owner before any file leaves the store. The exact file formats and fields should be confirmed in the BigCommerce admin and help documentation for your store, since they vary by setup.
- Who runs it: A store administrator with customer and order export rights, working with the privacy or compliance lead.
- What it produces: Separate files for customers and orders, which must be mapped to the target platform's customer and order models.
- Personal data handling: Store exports in an encrypted location with restricted access, and record who received them.
- Linking records: Confirm that customer identifiers in order files match the customer export so order history can be attached on import.
- Retention: Decide how long the raw export is kept after cutover and document the deletion date.
Check a sample of customers and orders against the admin, including addresses, tax fields and order status, before the final import.
What does not come out of a BigCommerce export and how to cover the gap
A BigCommerce export covers catalog, customer and order records, but it leaves behind data that sits outside the documented templates, store configuration and payment data held by the processor. Each gap below needs a named owner, a workaround and a question to put to BigCommerce before the old store is switched off.
Data outside the export templates
Built-in and custom export templates cover the fields the template includes, so anything the template omits is not in the file. Check each product field, metafield and custom field your storefront reads against the template columns before you rely on it. Fields that are missing from the template can usually be pulled through the Catalog API and written into a separate file. Confirm with BigCommerce which fields a given template returns, and whether order and customer exports include the attributes your fulfillment and support teams use. Bold the gap list so the team signs off each field.
Data only the Catalog API reaches
Bulk pricing rules, variants, images, brands, categories and custom fields are managed through the Catalog API, so a catalog extraction for a new platform usually means writing a script that pages through those endpoints. Plan for request limits, retries and a checkpoint file so a long run can resume after an error. Image binaries are not carried in a CSV, so record the public image URLs and confirm with BigCommerce how those URLs will be served after the store is closed.
Store configuration and theme
Themes, installed apps, checkout settings, tax rules, shipping zones and email templates are configured in the admin rather than exported as product or customer data. Document each setting before migration and treat it as a rebuild item for the new platform. Apps are the hardest item, because each one carries logic and sometimes stored data that has to be replaced by a module, plugin or custom code. Ask BigCommerce which of these settings, if any, can be exported as a backup and in what format.
Payment and card data
Stored card details and payment tokens are held by the payment processor, not by the store, and they are not part of a CSV export. Moving saved cards to a new platform usually depends on the processor agreeing to transfer tokens, which is a separate process from the store export. Without that agreement, customers must re-enter payment details. Ask BigCommerce and your processor in writing whether tokens can move, what the transfer requires, and which records you keep for tax and dispute purposes.
Historical orders and customer accounts
Order exports list transactions, but customer password hashes are not provided in a usable form, so customers may need to reset their passwords on the new store. Check whether your customer export includes the account fields and tags you need, and whether order history must be linked to customer accounts. Ask BigCommerce how long order records remain accessible after cancellation, and keep a read-only copy of the old store until finance and tax reconciliation are complete.
The export sequence and how to verify each file
This sequence moves the BigCommerce catalog, customers and orders out in a fixed order, with a check at each stage so the team can prove the export is complete before anything is switched off.
Freeze the catalog and record a baseline
Before any export runs, the store owner pauses product edits for the duration of the extraction and records the current product count, variant count, category count and customer count from the admin. Someone on the merchant team signs off the baseline sheet and keeps it with the export files. The step is done when every export can be compared against one dated set of numbers rather than against a store that keeps changing during the work.
Run built-in and custom template exports
The merchant runs product exports from Products and Export using a built-in template such as Bulk Edit or Default, or a custom template created under Settings and Export Templates. Use CSV rather than XML, because BigCommerce recommends CSV and notes that other file types cannot be imported back into a store. Each CSV is saved with a name that records the template and the export date. The step is done when every file opens cleanly and its first column is product ID, since exports are sorted by that field.
Save large exports to WebDAV and download them
Where a product export covers more than 1,000 products, BigCommerce recommends saving the export to the store's WebDAV folder and downloading it from there once it is ready. The person running the export confirms the file appears in WebDAV and downloads it to the secure working location used for the project. The step is done when the downloaded file size matches the size shown in WebDAV and the row count matches the product count in the baseline sheet.
Extract remaining objects through the Catalog API
Objects that the built-in exports do not cover, such as variants with their own option data, images with public URLs, categories, brands, bulk pricing rules, custom fields and metafields, are pulled through the Catalog API. The developer writes the extraction against the documented endpoints and respects the rate limits for the store's plan, storing each response as a raw file before any transformation. The step is done when each object type has a raw JSON dump whose record count matches the baseline sheet, with any request errors logged and retried.
Export customers and orders as the admin allows
The merchant exports customers and orders using the export options the admin provides for the store, and records any gap where the admin does not offer a field or date range needed by the new platform. Where the admin export is incomplete, the team notes which records must come from the API instead and confirms that with the BigCommerce documentation or the store's plan. The step is done when customer and order files exist, each has a recorded row count, and the list of gaps is written down for the migration team.
Verify counts, IDs, SKUs and images
The team compares each file against the live store and the baseline sheet: row counts, product and variant IDs, SKUs, category and brand links, and image references. A sample of products is checked by opening the live storefront page and the matching record in the export, and image URLs are tested in a browser to confirm they still resolve. The step is done when every mismatch is either fixed by re-running the export or documented as an accepted exception with an owner.
Check encoding and sign off before closing the store
Files are opened in a text editor that shows encoding, and accented characters, currency symbols and line breaks in descriptions are checked against the live store. The archived export set, the baseline sheet and the verification log are stored together in the project repository, and the migration lead signs off in writing. The store is kept live until the signed set is accepted, because deleting or closing the store removes the source for any export that still needs correcting.
When the Catalog API is the better path and how rate limits shape it
The Catalog API is the better path when you need more than a flat product file: it manages products, categories, brands, bulk pricing rules, variants, images, custom fields and metafields, so it can carry a full catalog out programmatically. Use it when the admin export templates cannot express your data, for example when variant structure, bulk pricing or metafields must be preserved for a rebuild, or when you need the extraction to be repeatable and rerun close to cutover. A CSV export is faster for a one-off product list, but it will not give you the full object graph.
Plan the extraction around the rate limits set by your store's plan. Every request counts against a limit, so a large catalog means many paginated calls spread over time, not one burst. Build pagination into the script from the start, read the current limit and response headers on each call, and back off with retries when the API signals throttling. Log each page and the last ID written so an interrupted run can resume without duplicating or skipping records. Confirm the current limits, endpoint paths, pagination parameters and field names in the BigCommerce developer documentation before you write code, because these change and your plan decides the ceiling.
Run the whole pipeline against a test store first. Use the test run to measure how long a full pass takes at your plan's limits, to check that images and custom fields come back with the references your target platform needs, and to compare record counts with the admin. Keep the live store untouched during the dry run. Ask your implementation partner, or whoever owns the script, to document the rate-limit handling, the retry policy and the reconciliation steps, so the final extraction is a rerun of a tested process rather than a first attempt.
What teams ask before they export BigCommerce data themselves
How long does a BigCommerce data export take?
The duration depends mostly on catalog size, the number of product images and variants, and whether exports run in one batch or several. Built-in CSV exports from the admin are quick for small catalogs, but larger catalogs go through the WebDAV folder for later download, which adds waiting and handling time. Customer and order volumes add to the total. Ask your team to run a test export on a copy or a low-traffic period and time each file type, then extrapolate from your own store rather than from a generic figure.
Can a store team export BigCommerce data without a developer?
Yes for the basic files. A store administrator can create export templates under Settings and export products from Products using the built-in or custom templates, and CSV is the recommended format. A developer becomes necessary when the catalog exceeds 1,000 products and needs the WebDAV route, when images must be matched to new URLs, or when variants, custom fields, metafields, bulk pricing rules or category structures must be pulled through the Catalog API. Confirm internally which of those apply before deciding who runs the work.
What does a consultant do that the BigCommerce admin cannot?
The admin produces files, but it does not map them to a new platform. A consultant defines the target data model, checks that exported fields such as variant options, bulk pricing and custom fields land in the right places, scripts repeatable extraction, validates counts and totals against the live store, and documents the steps for a rerun. Under a fixed-scope agreement, DeployOpen would set those deliverables and acceptance checks in writing before work starts, and would not issue any audit or certification for the result.
How much effort does the Catalog API work involve?
Effort rises with the number of object types and the complexity of their relationships. Products, categories, brands, variants, images, custom fields, metafields and bulk pricing rules each need their own requests, and the Catalog API is the programmatic path for them. Plan rate limits set how fast extraction can run, so large stores need throttling, retry logic and resumable jobs. Ask for the rate limit tier of your plan, the number of records per object type, and a written list of the fields that must be preserved before estimating.
What access must the team provide before an export engagement starts?
Typically the team provides administrator access to the BigCommerce store, API credentials with read scope for the objects in scope, and a test or staging store where scripts can be run without affecting customers. Access should be limited to what extraction needs and revoked at handover. Documenting who holds each credential, and rotating it afterward, reduces risk. Confirm these requirements with your security team and the platform's own documentation before granting access.
What should we do about customer and order data during the export?
Treat it as personal and financial data with its own handling rules. Customer exports can carry details, tags and supported metafields, and order exports include addresses and transaction history, so define who can download them, where files are stored, how long they are kept and how they are deleted. Agree on a retention rule and an encrypted transfer path before exporting. Check with your privacy and compliance leads whether any payment data is in scope, because it must not be copied casually into project folders.
Should we keep the BigCommerce store live during the export?
Yes, in most cases. Keeping the source store live lets you re-run extraction for changes made after the first pass, verify data against it, and fall back if something goes wrong. Plan a final delta export close to cutover, and record which orders and customers were created after the last run. The cost of keeping the subscription running during this period is a recurring item you can quantify from your current plan terms.
What to plan before the BigCommerce renewal or termination date
Exporting is the easy part to underestimate. The items below set the dates, access and retention decisions that have to be in place before the store is switched off. Each one depends on your own contract and on BigCommerce's current terms, so confirm every item rather than assuming it.
Notice and renewal dates
Find the exact notice window, renewal date and any auto-renewal clause in your BigCommerce agreement and order form. Work backward from the last date you can give notice, not from the date you want the store closed. Confirm with your account contact whether data access continues after cancellation, for how long, and in what format. If the contract is silent, ask for the answer in writing before you schedule the cutover.
Time for test and full exports
Run a test export of products, customers and orders well before the deadline, then time a full export of the real catalog. The product export uses built-in or custom templates from Products and Export, and catalogs over 1,000 products need the WebDAV route, which adds a download step. Record file sizes, row counts and any fields that are missing, so the full run has a known duration and a fallback plan.
Live period for images and URLs
Product CSVs do not carry image files, so images must be fetched from their public URLs by the new platform. Keep the BigCommerce store live until those images are imported and every product page resolves. Also plan for SEO URLs and redirects from old paths to new ones, and for a parallel run window. Confirm how long your storefront domain and image URLs remain reachable after you cancel.
Owner of API credentials
Name one person to own the API accounts and tokens used for Catalog API extraction, and list every app that holds access. Each token should have only the scopes the export needs. Decide who revokes access once the export is complete, and confirm that revocation is recorded. Unrevoked tokens and installed apps can keep reading store data after the team has moved on.
Retention of exported files
Decide where export files, API dumps and images are stored, who can open them and how long they are kept. Customer and order files contain personal data, so the storage location should be inside your own controlled environment with access logging. Set a deletion date for working copies that matches your internal retention policy and any legal hold. Confirm with your privacy or legal team before the files are copied anywhere else.
Target platform readiness
Confirm the new platform can receive the data before you rely on it. For Medusa, that means a PostgreSQL database, a Redis database and the server and worker instances running, with migrations applied and the /health endpoint passing. Test import of a sample catalog and a sample of customers and orders into a non-production environment. Only switch the cutover date after those imports have been checked field by field.
How DeployOpen scopes and delivers a BigCommerce data exit
DeployOpen approaches a BigCommerce data exit as a fixed-scope engagement inside the client's own infrastructure. We agree in writing which products, customers, orders and catalog fields move, then build, test, document and hand over the extraction and import work.
How we scope
- Inventory which catalog, customer and order data the store holds, including custom fields, metafields and images.
- Decide with you whether CSV templates, WebDAV exports or Catalog API extraction fit each data set.
- Record the agreed scope, deliverables and timeline in writing before any extraction work begins.
How we build
- Build repeatable export and transformation scripts that map BigCommerce fields to the target platform's data model.
- Test extracted files against a copy of the store to confirm counts, IDs, variants and product images match.
- Check Catalog API calls against your plan's rate limits so extraction runs complete without interruption.
How we hand over
- Document each export method, field mapping, known gaps and the steps to repeat an extraction.
- Deliver reconciliation reports that show record counts and any items that could not be migrated.
- Walk your team through the handover so they can rerun exports and verify results without us.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Retainers can cover changes to the target platform after launch, including upgrades and new integrations.
- Ask for a quote built from the written scope, so cost follows the data sets, integrations and environment you confirm.
