Migrate from BigCommerce to Saleor

Migrate from BigCommerce to Saleor: what the move involves

Teams usually start this move because a BigCommerce renewal, a pricing change, a data residency requirement or lock-in has forced a review of the platform. The key point is that the move is a catalog, data and storefront rebuild, not a file copy. Saleor has no import path that lifts a BigCommerce store across unchanged, so each product, variant, category, customer record and piece of content must be extracted, reshaped and loaded into Saleor's own model, and the storefront must be built again on top of it. Plan the work in that order, and treat the old store as the source of truth until the new one has been checked against it.

The work is normally done by an internal platform or commerce team with an implementation partner who handles the data mapping, the Saleor deployment and the storefront build. Extraction runs through the BigCommerce Catalog API, which covers products, categories, brands, variants, images, custom fields and metafields, so the mapping decisions are the main source of effort. Confirm early which BigCommerce custom fields and metafields carry business meaning, and decide whether each one becomes a Saleor attribute, metadata or an external system field. Ask any partner to show how they will handle variants, option sets and images before scoping starts, and confirm the BigCommerce API rate limits that apply to your plan, since they shape how long the extraction takes.

Saleor is headless and exposes everything through a GraphQL API, so there is no BigCommerce theme to port. The Saleor Dashboard handles back-office work, but the customer-facing site is new code that your team or partner must write and host, and it has to cover URLs, redirects, search, cart and checkout integration. Running Saleor also means operating the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, which becomes a recurring cost after launch. Before committing, confirm the hosting model with your partner and compare it with Saleor's own deployment documentation.

Which BigCommerce capabilities map to Saleor, and what needs rework

This table maps the main BigCommerce capabilities to their Saleor equivalents and labels each one as clean, needs rework or gap. Read the rows as a planning checklist: clean rows carry over with configuration, rework rows need code or data changes, and gap rows need a decision before cutover. Confirm each row against your own store and the Saleor version you plan to deploy.

Capability	Saleor equivalent and status	What to confirm or build
Products and categories	Clean. Products, categories and product types are modeled in the GraphQL API.	Map BigCommerce product types and category trees to Saleor categories and product types, then load a sample set and check slugs.
Variants	Clean. Product variants carry their own SKU, attributes, pricing and stock.	Confirm that each BigCommerce option set maps to variant attributes without splitting or merging SKUs.
Custom fields and metafields	Needs rework. Saleor uses attributes and metadata, which differ from BigCommerce custom fields.	Decide which fields become searchable attributes and which stay as metadata, then write the mapping before import.
Bulk pricing rules	Needs rework. Quantity-based discounts are not a direct one-to-one match.	Rebuild tiered pricing with the promotion engine or in the storefront, and test totals against BigCommerce output.
Multi-currency	Clean. Channels carry per-channel currencies and pricing.	Create one channel per currency or market and confirm prices are loaded for each channel.
Multi-warehouse stock	Clean. Stock is tracked per warehouse and per channel.	Map each BigCommerce inventory location to a Saleor warehouse and assign it to the right channels.
Customers	Needs rework. Accounts and addresses can be imported, but password hashes and login flows depend on your identity setup.	Confirm how customers will authenticate after cutover and whether a password reset step is required.
Orders	Needs rework. Historical orders are usually imported as reference data, not as live, editable orders.	Decide how much order history to bring over and where older orders remain searchable for support.
Promotions, vouchers and gift cards	Clean. Saleor includes sales, vouchers, cart rules and gift cards.	Recreate active BigCommerce coupons and check stacking rules against your checkout tests.
Returns	Clean. Saleor includes a returns flow tied to fulfillments.	Confirm the return reasons and refund steps your team needs and test them with your payment gateway.
Payments	Needs rework. Saleor supports split payments and multiple gateways through apps.	Confirm an app exists for each gateway you use, and plan PCI DSS scope for the checkout you build.
Search and storefront	Gap. Saleor is headless. BigCommerce themes, Stencil or Catalyst code and app-specific features must be rebuilt or matched with Saleor apps.	Budget a storefront build, check search options separately, and list each BigCommerce app with its Saleor replacement.

What the Catalog API extracts and what you rebuild

The Catalog API covers the product data you can pull programmatically, while customers, orders and integrations follow separate paths and need separate rebuild work in Saleor. Plan each group as its own workstream so that none of them is left to the cutover weekend.

Products, categories and brands

The Catalog API manages products, categories and brands, so these can be extracted in a repeatable script rather than a manual export. Map BigCommerce categories to Saleor categories and brands to attributes or collections, and decide early which hierarchy the new storefront will expose. Check that category paths match the URLs you need to keep for SEO. Confirm current endpoints and page sizes in the BigCommerce documentation before you write the extractor.

Variants, images and bulk pricing

Variants, product images and bulk pricing rules are all reachable through the Catalog API, but they map to different Saleor objects. Variants become Saleor product variants with their own SKUs and stock, and bulk pricing rules need a decision about whether Saleor promotions, channel prices or your own pricing service will express them. Images are referenced by URL, so download and re-host them before decommissioning the BigCommerce store. Verify each rule type against your own catalog.

Custom fields and metafields

Custom fields and metafields carry merchant-specific data such as materials, compliance codes or fitment details. In Saleor, these usually become product or variant attributes, or stay in metadata when they only serve an integration. Build an inventory of every custom field in use and assign each one a destination before extraction starts. Fields without a clear owner tend to be dropped during cutover, so agree that list with merchandising.

Plan rate limits for large catalogs

Catalog extraction runs against BigCommerce API rate limits that depend on your plan, so a large catalog can take a long time to pull if you do not design for it. Batch requests, store every response, and make the script resumable so a failed run restarts from the last page. Run a full test extraction on a copy of the catalog well before the cutover date. Ask BigCommerce for the current limits for your plan in writing.

Customers and orders as separate exports

Customers and orders do not come through the Catalog API, so plan them as separate exports and imports into Saleor. Customer records need a clear rule for passwords, which cannot be exported in readable form, so customers may need a reset flow on the new store. Order history is usually imported for reference rather than for live fulfillment. The export guide covers the CSV paths and their limits.

Integrations rebuilt as webhooks and apps

ERP, PIM, payment, tax, shipping and email integrations that ran as BigCommerce apps must be rebuilt in Saleor as webhooks, apps or metadata. Saleor does not run in-process plugins, so each integration needs an owner, an event trigger and a retry design. Use metadata to hold external IDs that connect Saleor records to your ERP or PIM. List every connected app on the BigCommerce side and confirm that a Saleor equivalent or custom app exists for each one.

The migration sequence from inventory to decommission

This sequence moves a BigCommerce catalog, customers and orders into Saleor in stages, so each step produces a checked artifact before the store goes live. The final step retires BigCommerce only after the retention period and a sign-off on the archived exports.

Inventory data, apps and integrations
List every product, variant, category, brand, bulk pricing rule, custom field, metafield, customer segment, order history, redirect and installed app, along with each external system that reads or writes store data, such as the ERP, payment gateway, tax service and shipping carriers. Record which BigCommerce apps supply a function that Saleor will need to cover through its apps, webhooks, metadata or a payment gateway integration. The output is an inventory register with an owner and a replacement decision for each item. Ask your team or partner to confirm the list against the BigCommerce admin and the actual API responses, not only against memory of the storefront.
Write the catalog mapping specification
Map each BigCommerce catalog object to a Saleor product type, attribute, variant, channel listing or metadata key. Decide how BigCommerce variant option sets, custom fields and metafields become Saleor attributes, which values become channel-specific prices and currencies, and where stock is tracked per warehouse. Document the Catalog API calls used to extract each object type and the rate limits that apply to your plan. The output is a signed mapping specification that engineers and merchandisers both review before any data is loaded.
Load a sample catalog into a pilot channel
Stand up a self-hosted Saleor instance using the Docker Compose setup, which needs the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers, then configure one pilot channel with its currency, tax settings and warehouse. Load a representative sample of products, including the hardest variants, bulk pricing cases and images imported from their public URLs. Check that prices, stock and attributes read back correctly through the GraphQL API. The output is a pilot report listing each mapping rule that held, each that failed and the fix applied.
Run a parallel period with synced catalog and orders
Keep the BigCommerce store live and run Saleor alongside it, with scheduled catalog syncs and order and customer exports or API pulls flowing into the Saleor environment. Compare order counts, totals, tax, discounts, gift card balances and stock levels between the two systems on a fixed cadence. Test the payment gateway, split payment handling, returns and fulfillment flows in Saleor using non-production credentials. The output is a set of reconciliation reports and a list of open defects with owners. Your team, or your implementation partner, should confirm which differences are accepted and which block cutover.
Prepare the cutover runbook and redirects
Write a runbook with the exact order of operations: freeze catalog edits, run the final delta sync, switch the storefront and API endpoints, update DNS records, activate the redirect map from old BigCommerce URLs to new Saleor storefront URLs, and verify webhooks and integrations. Include a rollback path with named decision makers and the conditions that trigger it. Confirm with your SEO lead that the redirect map covers category, product, brand and page URLs. The output is an approved cutover runbook that has been rehearsed against the pilot environment.
Execute cutover and final delta sync
On the agreed cutover date, freeze BigCommerce edits, run the final catalog, customer and order delta extraction, load it into Saleor, and repoint DNS and the storefront to the new environment. Check orders placed during the transition, payment captures, webhook deliveries and redirect responses against the runbook checklist. Keep BigCommerce in read-only operation as a fallback until the checks pass. The output is a cutover log with timestamps and sign-off from the business owner and the technical lead.
Decommission BigCommerce after retention
After the agreed retention period, export and archive final order, customer, product and redirect data from BigCommerce in formats your records and compliance teams accept, then confirm that no integrations still call the BigCommerce APIs. Cancel the subscription only after the archive is verified and stored under your retention policy. Shopify notes that a store's product images are not in its CSV export, so check whether BigCommerce image files were stored separately before you rely on the export set. The output is an archive index, a closed-out integration inventory and a written decommission record.

How the move differs by catalog size and starting point

A store that sells in one currency to one country, with a modest set of products and straightforward variant options such as size and colour, is the simplest starting point for Saleor. The catalog maps fairly directly: BigCommerce products become Saleor products, options become variant attributes, and images are re-attached from their source URLs. Saleor still needs one channel, so the work concentrates on product types, categories and a clean export through the Catalog API.

Product types: Group products that share the same variant axes into a small number of product types, so each one maps to a predictable set of Saleor attributes.
One channel: Configure a single channel with its currency, shipping zones and warehouse, which keeps pricing and stock simple to verify.
Image handling: Re-import images from their public URLs and check file names and alt text against the old store.
Storefront scope: Expect a storefront rebuild that covers product listing, cart and checkout, but few custom data views.
Redirects: Plan URL mapping for categories and products so search rankings carry over.

Before you start, ask the vendor or your own team to confirm whether the Catalog API rate limits on your plan allow a full extraction within the window you need.

What drives the cost and duration of a Saleor migration

This table lists the main cost and effort drivers for moving a BigCommerce store to self-hosted Saleor, showing who is paid for each item and whether it is one-time or recurring. Use it to see which parts of your catalog and integrations will move the quote, and what to ask for in a fixed-scope proposal.

Driver	Why it changes cost or effort	What to request in a quote
Catalog size and variant depth	Products with many variants, options and images take longer to extract through the Catalog API, map to Saleor product types and validate after import.	Product count, variant count per product, image count, and the extraction and validation steps included.
Metafields and custom fields	Each BigCommerce custom field or metafield needs a matching Saleor attribute or metadata key, and some will need custom handling in the storefront or integrations.	An inventory of custom fields and metafields with the target Saleor attribute or metadata field for each.
Channels and currencies	Saleor channels carry their own currency, pricing and stock settings, so each selling region or currency adds configuration and testing work.	Number of channels, currencies, warehouses and the pricing rules each channel uses.
BigCommerce apps to replace	Each app that handled payments, shipping, reviews, search or tax must be replaced by a Saleor app, webhook integration or third-party service, which is usually custom work.	A list of installed BigCommerce apps and the replacement approach agreed for each.
Storefront scope	A new storefront is built against the Saleor GraphQL API, so page count, checkout flow, account features and SEO redirect work set the size of the build.	Page templates, checkout steps, account features and the URL redirect plan.
Payment and search services	Multi-gateway payments and search indexing are configured in Saleor and connected to external providers, each with its own setup, testing and contracts.	Named payment gateways, search provider and the webhook or app work for each.
Hosting setup	The Docker Compose setup needs at least 5 GB of memory for Docker and runs the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers, so infrastructure sizing and configuration are part of the build.	Target environment, sizing for each component, backup and monitoring setup, and environment variable management.
Upgrades to new Saleor releases	Saleor releases such as 3.23.42 (released October 16, 2026, per the Saleor GitHub releases page) need testing against your apps and storefront, so upgrades recur over the life of the store.	Whether upgrade testing, release review and a support retainer are included, and how often they are scheduled.

What usually goes wrong and how to prevent it

Most BigCommerce to Saleor migrations fail in the handoff between data and storefront, not in the data itself. The cards below cover the failure points that repeatedly cost merchants traffic, orders and trust, each paired with a check you can run before cutover.

Missing product images

Images rarely come across with the product data. Shopify's own export documentation notes that product images are not included in the CSV and advises keeping the original store live until a new store has imported images from their public URLs. Apply the same logic to BigCommerce: pull image URLs through the Catalog API, download and re-upload them to Saleor, and keep the BigCommerce store live until a sample of products shows every image. Verify image counts per product before cutover.

SEO URL loss without redirects

BigCommerce product, category and brand URLs are indexed and linked from outside sites. A Saleor storefront that generates different slugs, or a catalog import that drops old paths, sends those links to 404 pages. Build a mapping table of every old URL to its new Saleor slug before launch, then configure permanent redirects at the storefront or CDN layer. Crawl the old site and confirm every indexed URL returns a 301 to a live page.

Metafield and attribute mismatch

BigCommerce custom fields and metafields do not map one to one onto Saleor attributes. Saleor separates product type attributes, variant attributes and page attributes, and each has its own data type and validation. Inventory every custom field in the Catalog API, decide which become product attributes, which become variant attributes and which move to metadata, and agree the data types before importing. Test a sample import of one complex product type end to end.

Currency rounding across channels

Saleor prices are set per channel, so a store that sells in several currencies needs each channel's price list maintained separately. Converting BigCommerce prices with a single exchange rate and rounding each value independently can produce prices that differ from the original displayed amounts, and it can break tax-inclusive totals at checkout. Export the rounded values per currency, compare them against the live BigCommerce storefront, and confirm the rounding rule with finance. Reconcile a sample basket in every channel before go-live.

Customer password handling

Passwords are not portable in plain text, and the hashing scheme on the BigCommerce side is not something to assume can be carried into Saleor. Ask BigCommerce support and your Saleor integrator how customer credentials can be moved, and plan for a forced password reset or account activation email if they cannot. Confirm how customer records, addresses and consent flags are imported so marketing permissions are not lost. Do not import password hashes until the transfer method is confirmed in writing.

Underestimating the storefront rebuild

Saleor is a headless backend, so the storefront, checkout pages, account pages, search and every BigCommerce app integration must be built or replaced. Teams often budget for the data move and treat the storefront as a theme change. List every page template, checkout step, app function and third-party script in the current store, then assign each one to a Saleor API, a storefront component or a retired feature. Agree that inventory as part of the written scope before estimating timelines.

Running BigCommerce and Saleor in parallel without double entry

The rule that prevents double entry is that each object type has exactly one writer at any moment. Before cutover, BigCommerce remains the single writer for products, prices, stock and orders, while Saleor receives the catalog as a read-only target so the team can test channels, currencies and attributes. When a data type moves, its write path switches to Saleor and BigCommerce becomes read-only for that type, so a merchandiser cannot change the same price in both admins. Record the decision in a written matrix that lists products, variants, channel prices, warehouse stock, customers and orders, with the owner of each at every stage. Stock needs the earliest decision: confirm which system decrements inventory before the Saleor storefront accepts any order, and confirm with your payment and storefront vendors how order events are routed while both platforms are live.

Delta syncs should run on a fixed schedule that matches how often merchandising edits the catalog. Use the modified-date filters in the Catalog API for each resource you pull, after confirming that the filter is supported for that endpoint, so each run fetches only changed records. Log every run's timestamp and object counts so a failed run can be repeated safely. Store the BigCommerce product ID in the matching Saleor object's metadata so each upsert finds the same record and does not create a duplicate. Freeze catalog changes in a defined window before cutover: announce the start time, stop edits in BigCommerce, run a final delta, compare counts and a sample of prices and variants, and lift the freeze only after the comparison passes. Confirm the rate limits that apply to your BigCommerce plan, because the final full pull depends on them.

The hosting choice decides who carries the operational load of the parallel period. On Saleor Cloud, Saleor operates the managed service, and your team concentrates on configuration, apps and the storefront. Self-hosting with Docker places the API, the Dashboard, PostgreSQL, Valkey or Redis, and the Celery workers under your control, along with their upgrades, backups, secrets and monitoring. The Docker Compose setup asks for at least 5 GB of memory for Docker, which is a minimum for getting started, so size production separately for sync jobs and peak traffic. Make this decision before you finalize the sync design, because the schedule, failover and credential handling all depend on who runs the workers and who is on call for them.

Questions buyers ask before moving from BigCommerce to Saleor

How much does it cost to move from BigCommerce to self-hosted Saleor?

No single figure applies, because the cost depends on the catalog size, the number of integrations, and how much storefront work you need. Saleor itself is BSD-3-Clause licensed, so there is no license fee to pay for the core platform. The costs you will pay are one-time: the data extraction and mapping, the storefront build, the integrations with payment, tax, shipping and your ERP, and testing. The recurring costs are the infrastructure to run the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, plus hosting, monitoring, backups, upgrades and any support retainer. Ask any partner for a quote that splits these into separate line items, and compare that with your current BigCommerce plan fees and app subscriptions over the same period.

How long does a BigCommerce to Saleor migration take?

The duration depends on the scope, so confirm it in writing before work starts instead of relying on a general estimate. The biggest variables are the number of products and variants, how many custom fields and metafields need mapping to Saleor attributes, how many channels and currencies you launch with, and how much of the storefront must be rebuilt. Fixed-scope engagements agree deliverables and timelines in writing before work begins, which is the right way to compare proposals. Ask for a phased plan with a parallel-run period, because keeping BigCommerce live until the new store is verified reduces the risk of losing orders during cutover.

What does the internal team need to provide during the migration?

Your team needs to own the business decisions and the systems knowledge that no external party can supply. Expect to name a product owner who can decide on catalog structure, channel and currency rules, and tax and shipping logic. Your engineers should provide access to the BigCommerce store through API credentials, the list of installed apps and the integrations that depend on them, and the ERP, payment, and fulfillment endpoints. Finance and operations staff will need to validate prices, stock levels and order history after the first test import. Ask the implementation partner to list these inputs in the scope document so you can plan staff time before the project starts.

Can our own team migrate from BigCommerce to Saleor without a partner?

Yes, a capable in-house team can do it, but the work requires skills across several areas at once. The team needs to read the Catalog API, write extraction scripts that stay within the plan rate limits, and map variants, custom fields and metafields to Saleor attributes. It also needs experience with the GraphQL API, the channel model for multi-currency pricing, Python, Django and PostgreSQL operations, and frontend development for a headless storefront. Ask yourself whether those skills are available for the full timeline, including the cutover and the first months of operation. A partner can take on the parts you lack, or act as an independent reviewer of your own plan.

How does the BSD-3-Clause license of Saleor affect our costs?

The BSD-3-Clause license allows you to use, modify and deploy Saleor without paying a license fee to the project. That removes the per-store or per-plan subscription charge you pay BigCommerce, but it does not remove the cost of running the software. Your costs move to infrastructure, staff time, integrations and support. Read the license file in the repository to confirm the terms that apply to your use, and ask your legal or procurement team to review any commercial Saleor offering separately, such as Saleor Cloud managed hosting, which is priced differently from the self-hosted route.

What happens to our SEO URLs and rankings after the move?

Your rankings depend on whether each old BigCommerce product, category and content URL has a matching live URL or a permanent redirect on the new store. Plan a complete URL map before the storefront is rebuilt, and set up 301 redirects for every changed path so search engines and existing links continue to reach the right page. Keep the BigCommerce store running until the redirects and the new pages have been tested. Also carry over page titles, meta descriptions, canonical tags, structured data, image alt text and the sitemap. Ask your partner to show the redirect map and a crawl report from the staging site as part of the acceptance criteria.

What should we confirm with BigCommerce and Saleor before signing?

Confirm the export and API limits with BigCommerce before you commit, because they shape the extraction plan. Check the rate limits that apply to your plan, the Catalog API coverage for your products, variants, images, custom fields and metafields, and any data your contract restricts you from exporting. Ask for a written list of what you can take out and in what format. For Saleor, confirm the version you will deploy and its current release, the Docker Compose requirements such as the at least 5 GB of memory for Docker, the supported hosting path, and the support options. Also confirm which payment, tax and shipping apps are available in Saleor for your markets before you rely on them.

Does DeployOpen handle the full Saleor migration and what is in scope?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks. For a Saleor migration, that can cover the catalog extraction, attribute mapping, channel setup, storefront work, deployment, backups, security testing and the handover documentation. Most engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. Ongoing support and upgrades are available as retainers.

Official sources to check before you plan the migration

Before you size the project, read the official Saleor material and the BigCommerce Catalog products API documentation side by side. The Saleor repository on GitHub is the reference for the current feature set, including channels, warehouses, the promotion engine and the GraphQL schema that your import scripts will call. The Saleor releases page lists the version history, so you can pick the release you plan to deploy and read its change notes for breaking changes to the API, the Dashboard or the environment variables. Pin that version in your plan rather than assuming the latest one is the one your team will run in production.

The Saleor Docker Compose documentation is the place to confirm what a self-hosted install needs: the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, plus the memory the Docker setup asks for. Ask your platform team to check those requirements against the hosting you intend to use, and to confirm which settings come from environment variables in your deployment. The BigCommerce Catalog products API documentation defines the endpoints, fields and pagination behavior you will use to extract products, variants, images, custom fields and metafields. Read it alongside the rate limit rules for your store's plan, because those limits set how long the extraction runs. Confirm the current rate limits, endpoint behavior and Saleor version directly with the vendors at the time you plan, since these change between releases and plan tiers. Record the dates and versions you checked in your project documentation so that the mapping decisions can be reviewed later. Where a behavior matters to cost or schedule, such as bulk limits or webhook delivery, ask for the written answer from the vendor and keep it with the scope document.

How DeployOpen scopes, runs and supports the Saleor migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a BigCommerce to Saleor move, that means agreeing the catalog extraction, data mapping, channel setup and storefront scope in writing before any migration work starts.

How we scope

Written scope lists which BigCommerce catalog, customer and order data move to Saleor and which do not.
Scope records how variants, custom fields and metafields map to Saleor attributes and channels.
Timelines, deliverables and acceptance tests are agreed in writing before the engagement begins.

How we build

Catalog extraction runs through the BigCommerce Catalog API, with request volumes planned against your plan's rate limits.
Saleor is deployed with the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers in your environment.
Channels, currencies, warehouses and the storefront rebuild are configured and tested against your store's requirements.

How we hand over

Documentation covers the data mapping, environment variables, deployment steps and how to run imports again.
Test results show which products, images, customers and redirects were checked before cutover.
Handover includes the runbook for backups, upgrades and rollback, so your team can operate the platform.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Upgrades to new Saleor releases are scoped and tested before they reach production.
Ask any implementation partner to confirm support hours, response terms and who holds production access.

Migrate from BigCommerce to Saleor