Migrate from commercetools to Saleor

Migrate from commercetools to Saleor: what the work involves

Moving from commercetools to Saleor is a data, integration and rebuild project that ends with a parallel run, not a copy-paste. The commercetools side holds product types, attributes, channels, standalone prices, customers, orders and discount rules, and Saleor models several of these differently, so each one needs a mapping decision before any import starts. Plan for both backends to run side by side until order flows, refunds and promotions have been verified end to end on Saleor. In most cases an internal platform or commerce engineering team leads the work, with an implementation partner covering the data mapping, the GraphQL import scripts and the rebuilt checkout logic. Effort and risk depend mainly on three things: how complex the catalog is (product types, variants and attribute depth), how many custom extensions and API subscriptions the commercetools setup relies on, and the daily order volume that the parallel run must handle. Ask the partner to size each of these in the written scope rather than accepting a single estimate for the whole migration. Plan against Saleor 3.23.42, released on October 16, 2026, according to the Saleor GitHub releases page. Pin the version in your staging environment from the start, and confirm with your team which Saleor features your storefront and integrations will call, since API behavior and extension points should be checked against that release before cutover. Confirm current hosting requirements in the Saleor Docker Compose setup documentation before sizing infrastructure for the parallel run.

Which commercetools capabilities map to Saleor, and where the gaps are

This table maps the main commercetools capabilities to their closest Saleor equivalents and rates each as clean, needs rework or gap. Read it as a scoping checklist: anything marked needs rework or gap should be costed before you commit to a migration plan. Confirm every feature you rely on, especially custom fields, Custom Objects and cart discount logic, against both platforms before you scope the work.

Capability	Saleor equivalent	Rating	What to confirm
Product types and attributes	Product types with attributes, assigned per product type	Needs rework	Map commercetools product types and custom fields to Saleor attributes and check value types
Categories	Hierarchical categories	Clean	Confirm depth, slugs and any category-level custom fields
Channels and standalone prices	Per-channel pricing and currencies within channels	Needs rework	Restructure standalone prices into channel-specific listings before import
Multi-currency pricing	Per-channel currencies	Clean	Confirm each currency and rounding rule per market
Stock and warehouses	Multi-warehouse stock, per channel	Needs rework	Map inventory channels to warehouses and allocation rules
Promotions and discounts	Sales, vouchers, cart rules and gift cards	Needs rework	Rebuild cart discount logic as Saleor promotion rules and test stacking
Customers	Customer accounts and addresses via the API	Needs rework	Confirm export fields, password handling and consent data
Orders and returns	Orders, fulfillment and returns	Needs rework	Decide whether historical orders are imported or only referenced
Payments	Multi-gateway payment support and split payments	Needs rework	Confirm each payment provider integration and token migration path
Extensions and subscriptions	Apps, webhooks and metadata	Gap	Subscriptions and custom API extensions need new design and build work

Which data exports and integrations you must move, and by which path

A commercetools move is less a single data dump than six parallel workstreams, each with its own export route and its own import rules in Saleor. Confirm each export path in the commercetools documentation before you plan the import, because the route you use determines what arrives in Saleor intact.

Catalog structure and attributes

Products, variants, product types, attributes, and categories form the core of the move. Export them through the Merchant Center or the HTTP API, then confirm in the commercetools docs which fields each export includes. In Saleor, map product types and attributes to Saleor product types and attributes through the GraphQL API, and check that category trees and variant attributes keep their hierarchy and their values after import. Record every attribute your storefront reads, since a missed attribute becomes a broken product page.

Product images and files

Product images and digital assets usually do not travel in a catalog export, so plan a separate handling step. Confirm in the commercetools documentation how image URLs appear in your exports and whether those URLs stay public after cutover. Download or re-host the files in storage you control, then attach them to Saleor products through the GraphQL API. Keep the original image URLs in product metadata so you can trace each file back to its source.

Pricing, price lists and channels

commercetools standalone prices, price lists and channel-specific prices must map onto Saleor channels, which carry their own currency and pricing. Export prices with their currency, country, customer group and validity dates, then decide which of these Saleor can represent directly and which need a rule in your storefront. Test that each channel returns the expected price for a sample of SKUs in every market before you switch traffic.

Customers, orders and open carts

Customer records and order history carry personal data, so confirm the export scope and the retention rules that apply to each set. Open carts are the easiest data to lose and the hardest to rebuild, so decide early whether they migrate or whether shoppers start again. Import customers through the GraphQL API with their addresses, and import historical orders as reference records rather than as live fulfillment. Check how your order numbering continues in Saleor so that customer service can find old orders.

Inventory and warehouses

Stock levels must map to Saleor warehouses, which support multi-warehouse fulfillment and stock per channel. Export inventory entries from the commercetools documentation path you confirm for your account, and map each supply channel to one Saleor warehouse. Reconcile stock counts on the cutover day, because a stock mismatch sells items you do not hold. Freeze inventory changes during the final sync window if your operations allow it.

Payment, tax, ERP and storefront integrations

Payment gateways, tax services, ERP, order management, search, and storefront API clients are not data exports, and they do not move with the catalog. Inventory every extension and subscription that calls commercetools, and rebuild each one against Saleor webhooks, apps, or the GraphQL API. Storefront clients must switch their endpoints and token flows, so schedule that work in the same release plan as the data import. Confirm each integration with its vendor before you decommission the commercetools side.

How to map commercetools price lists and product types onto Saleor channels

Saleor handles pricing, currencies, stock and products per channel, and it tracks inventory across multiple warehouses. commercetools price lists and their country or channel scoping therefore have to be re-expressed as Saleor channels, channel-specific prices and warehouse assignments. The mapping is not a one-to-one copy, so the team must settle it on paper before any data moves. Start by deciding whether each channel will represent one market, one currency or one market and currency pair. A channel in Saleor carries its own currency and its own product availability, so a market that shares a currency with another may still need its own channel if it has different assortment, tax or shipping rules. Pull the list of commercetools price scopes and stores, then match each one to a proposed channel and record the currency for each.

Next, map product types and attributes. A commercetools product type defines the attributes that its products carry, and the same idea maps to Saleor product types and attributes, but Saleor separates attributes used for variant selection from those used for descriptive content, so each attribute needs a role before import. Custom fields on commercetools resources usually have no direct Saleor equivalent. The usual approach is to store them in metadata on the matching object, either public or private metadata depending on whether the storefront reads them. Confirm with your storefront and integration owners which custom fields are read by a live page or back-office process, because those fields need a documented home before the first load. Decide the naming convention for metadata keys now, since changing it later means rewriting every imported record.

Sign off the mapping document before any bulk load. It should list every channel, currency, product type, attribute, metadata key and warehouse, with an owner for each decision and a record of which commercetools source field feeds it. Have finance check the price conversions and tax settings per channel, and have operations confirm warehouse assignments. Load a small sample first, using the GraphQL API against a non-production Saleor instance, then compare results against the commercetools source. Any change to the mapping after a bulk load means repeating the load, so treat the signed document as the contract for the migration. Ask your implementation partner to show how the mapping will be versioned and who may approve changes.

The migration sequence: inventory, pilot, parallel run, cutover and decommission

This sequence moves commercetools data and logic into Saleor in controlled stages, so the live store keeps trading until Saleor order flows have been verified against real results.

Inventory data, integrations and promotions
Your commercial and technical team lists every commercetools resource in use: product types, attributes, categories, channels, standalone prices, customer groups, tax and shipping settings, discounts, and every app, webhook, and third-party system that reads or writes to the API. Each item gets an owner and a target Saleor equivalent, such as a channel, a product type, a promotion, or an app. Output: a signed-off mapping sheet and an integration register. Done when every live promotion and integration has a named replacement or an explicit retirement decision.
Pilot import into a non-production Saleor
Deploy a non-production Saleor instance with Docker Compose. The stack needs the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, and the Docker Compose setup asks for at least 5 GB of memory for Docker, so confirm the host meets that before you start. Export a representative subset of commercetools data, then import it through Saleor's GraphQL API and check channel pricing, stock per warehouse, and attribute values against the source. Output: a pilot log listing each mismatch, its cause, and the fix. Done when a sample of products, prices, and customers reads back correctly from the Saleor API.
Run both backends in parallel
Keep commercetools as the production system of record while the storefront or a test environment sends the same scenarios to both backends. Place test orders covering each channel, currency, discount type, shipping method, and payment path, including returns and partial fulfillment where you use them. Reconcile totals, tax, discounts, stock movements, and order statuses between the two systems for every test order. Output: a reconciliation report with zero unexplained differences for the agreed scenario set. Done when the team can explain every remaining gap and the business owner signs off on the results.
Cut over with a rollback plan
Agree the cutover window, the final delta export, and the freeze on catalog and price changes in advance. Import the final delta into Saleor, repoint storefront and integration API calls, and confirm live orders flow end to end. Write the rollback plan before the switch: the conditions that trigger it, who decides, how orders placed on Saleor during a rollback are reconciled, and how the storefront is pointed back to commercetools. Output: a cutover runbook and a rollback record. Done when the first live orders reconcile in both finance and fulfillment systems.
Decommission commercetools after reconciliation
Keep the commercetools project read-only for the period your finance, tax, and audit obligations require, and confirm that retention period with your legal and finance teams. Export a final archive of orders, customers, and configuration for records. Revoke API clients, remove integrations, and cancel the subscription only after the archive is verified and the agreed reconciliation period has closed. Output: a verified archive, an access revocation record, and written confirmation from the vendor of the contract end date. Done when no system depends on commercetools and the archive can be restored for audit.

What drives migration cost and duration, and how to keep each driver down

This table lists the main drivers of effort and spend when moving commercetools data and logic into Saleor, with one-time and recurring components. No fee or duration is supplied for this move, so use the drivers to scope a written quote and to decide where to cut effort. Read each row as a question to answer in your own catalog and integration inventory before you ask for pricing.

Driver	Why it changes cost or effort	How to keep it down
Catalog size and attribute complexity	Each product type, attribute and variant combination needs a mapping decision and an import test. Large catalogs with many custom attributes take longer to map and validate.	Trim unused attributes before export, consolidate near-duplicate product types, and map a representative sample first.
Channels and currencies	Saleor models pricing and stock per channel, so each commercetools market, currency and price list needs a channel design and standalone price import.	Agree the channel model in the mapping document early and avoid creating channels for markets that are not live.
Custom extensions and integrations	Connect, API extensions and custom Merchant Center logic must be rebuilt as Saleor webhooks and apps. This is usually the largest one-time item.	Inventory every extension and integration, retire the ones no longer used, and rebuild only the behavior the business still needs.
Promotion rules	Discounts in commercetools must be re-created with Saleor's promotion engine across sales, vouchers, cart rules and gift cards, and then tested for stacking behavior.	Export a list of active promotions, drop expired ones, and write each rule as a test case before building it.
Order history and open orders	Historical orders may be archived rather than migrated, while open orders, returns and payment states need a planned handover at cutover.	Decide which order history is needed for service and finance, and freeze new open-order work during the cutover window.
Payment gateway count	Each gateway needs its own configuration, webhook handling, test transactions and reconciliation checks in Saleor's multi-gateway setup.	Reduce the number of active gateways before migration and confirm which ones are supported in your region.
Environments and infrastructure	Running Saleor needs the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers. Staging and production each need this stack, and the Docker Compose setup asks for at least 5 GB of memory for Docker (Saleor Docker Compose docs).	Size staging to mirror production only where it matters for testing, and standardize deployment through environment variables.
Internal staffing and recurring operations	One-time work covers mapping, import, rebuild and testing. Recurring work covers hosting, Saleor upgrades, security patches and on-call support, which your own team or a retained partner must cover.	Name owners for each area before the project starts and ask any partner for a support model separate from the build scope.

What usually goes wrong in a commercetools to Saleor migration

Most failed commerce migrations break at the same few seams: how discounts are rebuilt, how channel and warehouse scope is set, how in-flight orders are handled, and how customer accounts move. Each card below names one of these risks, the prevention step, and the check that shows the step worked.

Promotions reproduced inexactly

commercetools cart discounts, discount codes and their stacking rules do not map one to one onto Saleor's promotion engine, which covers sales, vouchers, cart rules and gift cards. Rebuild each active promotion as a Saleor promotion and write down its stacking and eligibility rules before import. The check is a set of recorded test carts, priced in both systems with identical contents, where every line, discount and total must match to the minor currency unit.

Prices and stock scoped wrongly

commercetools standalone prices are keyed by customer group, channel and currency, and inventory is tracked per channel. Saleor applies per-channel pricing, currencies and stock across warehouses, so a price or stock level attached to the wrong channel or warehouse will sell at the wrong amount or show false availability. Map every price list and inventory entry to an explicit Saleor channel and warehouse in a written table. The check is a per-market sample of SKUs where the storefront price and available quantity match the source system.

Orders and carts in flight at cutover

Carts that hold items, pending payments and orders awaiting fulfillment will not carry over cleanly by simply exporting data. Pick a cutover window, freeze new carts on the old backend, and let open payments settle before the final delta import. Keep commercetools live for returns and fulfillment questions on orders placed before the switch. The check is a reconciliation report comparing order counts, payment states and open fulfillments in both systems on the day after cutover.

Customer identity and password gaps

Customer records can be exported, but password hashes are generally not available in a usable form from commercetools exports, so returning customers may not be able to sign in on Saleor. Confirm with commercetools what credential data your project can export, then decide between a password reset flow, a staged account claim or an identity provider in front of both systems. The check is a test login for a sample of migrated accounts, including one that must reset its password, and confirmation that addresses and marketing consent fields arrived intact.

Extensions tied to commercetools hosting

Custom logic that runs inside commercetools, such as API Extensions, subscriptions and custom Composable Commerce integrations, has no direct equivalent in Saleor. Saleor extends through webhooks, apps and metadata rather than in-process plugins, so each extension needs an explicit Saleor app or webhook handler, with its own hosting and secrets. Inventory every extension and subscription before design starts. The check is an integration test per extension that fires the Saleor webhook and confirms the same downstream record is produced as before.

Underestimating the operating work

Running Saleor means operating the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, not just a storefront backend. Budget for upgrades, backups, monitoring of background jobs and capacity for peak sales events, since commercetools handled that infrastructure for you. Ask who will own on-call duties and patching before design begins. The check is a runbook covering restore of PostgreSQL, a failed Celery worker and a Saleor upgrade in staging, each timed and signed off by the team that will operate it.

How the migration differs by catalog size and starting point

A single-market store with one currency, one storefront and a catalog that uses a small set of product types usually has the shortest path. The mapping is mostly one-to-one: a handful of product types, a default channel, one set of prices and standard stock levels. Most of the effort goes into moving products, variants, categories and customers cleanly, then confirming that checkout and order events behave the same way in Saleor.

Product types: Map each commercetools product type to a Saleor product type and confirm which attributes are variant-level and which are product-level.
Channel setup: One Saleor channel is often enough, but confirm the currency, tax and shipping configuration matches what commercetools does today.
Test scope: Testing can focus on the storefront checkout path, order webhooks and refunds, with a smaller set of regression cases.
Parallel run: Keep commercetools live for a short overlap, enough to reconcile orders placed on both systems.

Before choosing this path, confirm with your team that the catalog and promotions are genuinely simple, because a store that looks simple often has hidden custom attributes or price rules.

Questions buyers ask before moving from commercetools to Saleor

What does a migration from commercetools to Saleor cost?

The cost is the sum of separate components: the planning and mapping work, the export and import scripts, the rebuild of discounts and checkout logic, the integrations and storefront API changes, testing, a parallel-running period, and the infrastructure you run afterward. Saleor's core is BSD-3-Clause licensed, so there is no license fee for the software itself, but hosting, PostgreSQL, Valkey or Redis, Celery workers and engineering time recur every month. Your commercetools subscription and add-ons are one-time savings only after you cut over and end the contract. The main cost drivers are catalog size and attribute complexity, the number of channels and markets, how many custom integrations depend on commercetools APIs, and how many promotion rules must be rebuilt. Ask any quote to itemize these components separately, with the one-time work and the recurring run costs shown apart.

How long does a commercetools to Saleor migration take?

The timeline depends on scope rather than on a standard duration, so treat any fixed number as something to confirm in writing. The biggest factors are how many product types, attributes, channels, price lists and warehouses you map, how much order history must come across, how many integrations must be rebuilt, and whether checkout logic lives in commercetools extensions or in your storefront. Running both backends until order flows are verified adds a validation period that many teams underestimate. A fixed-scope engagement sets deliverables and timelines in writing before work starts, which makes the schedule easier to compare across proposals.

What does our team need to provide during the migration?

Plan for four named roles on your side. Catalog owners confirm product types, attributes, categories and which data is live. Integration owners identify every system that calls the commercetools HTTP API or receives its webhooks, including order management, ERP and search. Finance needs to reconcile prices, tax settings, currencies, orders and refunds between the two systems before cutover. Someone with sign-off authority must approve the written mapping of product types, attributes, channels and standalone prices to Saleor's model, because errors in that mapping surface later as wrong prices or missing stock. Time for these reviews should be written into the scope so that delays are visible early.

Can our internal team migrate from commercetools to Saleor without outside help?

An internal team with GraphQL, Python or Django experience and PostgreSQL operations skills can handle parts of the work, and the Saleor project documents a Docker Compose setup to start with. The harder parts are usually the ones with the least documentation in your own code: mapping commercetools custom fields and standalone prices, rebuilding discounts so they behave the same way at checkout, and verifying that orders, refunds and inventory agree during parallel running. Ask whether the team has done a comparable cutover, who will operate the platform after go-live, and how many people can be pulled from current product work. Outside help is most useful when it is scoped to specific deliverables, such as the mapping document, the import tooling or the verification plan.

Can Saleor replace commercetools channels, promotions and multi-warehouse fulfillment?

Saleor covers these areas at the platform level. Its GraphQL API supports per-channel pricing, currencies, stock and products, and it works with multiple warehouses. Its promotion engine includes sales, vouchers, cart rules and gift cards. It also provides split payments, returns, multi-gateway payment support and multi-warehouse fulfillment. Mapping still needs care: commercetools channels, price lists and discount logic do not map one to one, so each rule must be rebuilt and tested against the same carts. Confirm each feature you depend on against the current Saleor documentation and your own test cases, and check any commercetools extensions you rely on, since Saleor extends through webhooks, apps and metadata rather than in-process plugins.

What should we ask for in a DeployOpen quote?

Ask for a written scope that lists each deliverable: the data export and mapping document, the import tooling, the discount and checkout rebuild, the integration changes, the parallel-running plan and the verification criteria. Ask for the timeline and the milestones at which your team signs off. Request the one-time work and the recurring costs as separate lines, including hosting and operations if DeployOpen will run the platform. Ask which of your systems are in scope and which are excluded, what the rollback plan is, and what happens if the mapping review uncovers more product types than estimated. DeployOpen does not publish a price list, so the quote follows from the written scope.

Does DeployOpen certify that the migrated store is compliant?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. If your payment handling, data residency or privacy obligations require an assessment, independent auditors and certification bodies perform it. Ask your quote to name the evidence DeployOpen will prepare, such as configuration records, access settings and test results, so your assessor has what it needs.

How DeployOpen scopes, runs and supports the Saleor migration

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a commercetools to Saleor move, we start from a written scope that names the data, channels, discounts and order flows in play before any import runs.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which commercetools resources move, including products, prices, customers and orders.
It also records which discounts, checkout extensions and integrations must be rebuilt on Saleor webhooks and apps.

How we build

We map product types, attributes, channels and standalone prices to Saleor equivalents and document each decision.
We script imports through Saleor's GraphQL API and test them against staging data before any production run.
We deploy the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers in your environment, with configuration held in environment variables.

How we hand over

We run both backends in parallel until order flows, refunds and promotions are verified against the written scope.
Deliverables include mapping documentation, import scripts, runbooks and a record of reconciliation checks.
We hand over administration, backup and upgrade procedures so your team can operate Saleor without us.

How we support

Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
Retainers can cover Saleor version upgrades, reviews of new webhook apps and periodic backup restore tests.
Ask us to confirm response arrangements, service levels and retainer terms in writing before signing.

Migrate from commercetools to Saleor