Which fits a commercetools team considering Saleor
A commercetools team usually starts this evaluation for a specific reason: a subscription renewal, a data residency rule that the current region setup does not satisfy, concern about lock-in, or a wish to own the commerce backend and its data. Those triggers point in different directions, so the first question is which one is driving the decision. commercetools fits teams that want managed operations and vendor-run scaling, with the platform team focused on storefronts and business logic. Saleor fits teams that want BSD-3-Clause code they run in their own cloud accounts, with the operational responsibility that comes with it.
Three factors decide the outcome. The first is data control: if a regulator or internal policy requires that customer and order data stay in infrastructure you select and operate, self-hosting Saleor addresses that directly, while a SaaS region choice may not. Confirm the exact requirement with your compliance lead before comparing regions. The second is in-house platform engineering capacity. Running Saleor means operating the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, plus upgrades, backups and monitoring, and that work is recurring. The third is how much of commercetools' feature set your business actually uses. If your catalog, channel, promotion and fulfillment needs map cleanly onto Saleor's channels, warehouses and promotion engine, the migration case is strong. If you depend on capabilities you have not yet checked against Saleor, list them first and verify each one in a proof of concept before committing.
Which option fits which buyer situation
This table maps common buyer situations to the option that usually fits better, with the condition that changes the answer. Read each row as a starting point: the reason depends on your team size, data rules and existing skills, so check the conditions against your own environment before deciding.
| Buyer situation | Better fit | Reason and condition |
|---|---|---|
| Multi-market channel pricing with a small platform team | Saleor, if the team can run it | Saleor's channels hold per-channel pricing, currencies, stock and products, which maps to market-by-market setups. A small team can carry this only if someone owns Django, PostgreSQL and worker upkeep. |
| Strict data residency that requires self-hosting | Saleor, self-hosted | If national rules or internal policy require customer and order data in infrastructure you choose, a self-hosted Saleor deployment keeps that control. Confirm the hosting region and sub-processors with your legal and compliance teams. |
| Managed operations with limited DevOps capacity | commercetools, or Saleor Cloud | If no one on the team can operate databases, queues and upgrades, a managed service suits better. Saleor Cloud is an option to compare against commercetools, but confirm its service terms and support levels directly with the vendor. |
| Team already working in GraphQL | Saleor | Saleor exposes its full surface through GraphQL, so frontend and integration engineers who already use it can reuse existing skills. The fit weakens if your storefront depends on REST patterns or on commercetools-specific query shapes. |
| Heavy promotions, vouchers and gift cards | Saleor, after a rules review | Saleor includes a promotion engine with sales, vouchers, cart rules and gift cards. Map each commercetools discount type to Saleor's rules before deciding, because edge cases in stacking and eligibility often need custom work. |
| Multi-warehouse fulfillment with split payments | Saleor | Saleor supports multi-warehouse fulfillment, split payments, returns and multi-gateway payment support. Confirm that your payment provider and fulfillment partners integrate through Saleor's apps and webhooks. |
| Heavy reliance on custom in-process logic | Neither without a proof of concept | Saleor extends through webhooks, apps and metadata rather than in-process plugins, which changes how custom logic is built and deployed. Run a proof of concept on your most complex flow before committing. |
How Saleor channels handle multi-market pricing and stock
A retailer selling into several countries usually needs one channel per market, because each channel carries its own currency, price set and view of stock. Saleor exposes per-channel pricing, currencies, stock and products through its GraphQL API, so regional pricing becomes data your team maintains in the platform. This setup is simplest when markets share one catalog and differ mainly in currency, tax and shipping rules.
- Channel per market or currency: Create a channel for each storefront that sells under its own currency and tax configuration. Confirm the tax and rounding rules with finance before creating the first channel.
- Prices set per channel: Each variant holds a price in every channel where it is listed, so regional price changes are made channel by channel.
- Warehouse assignment: Decide which warehouses serve which channel and whether stock is shared across markets or held separately.
- Channel-scoped promotions: Confirm which sales, vouchers and cart rules can be limited to one channel in the version you deploy.
- Shipping and tax zones: Map each channel to its delivery regions and tax rules, since these drive the checkout total.
Check each market's currency, tax and fulfillment rules against a written channel map before you load prices. The Saleor repository documents the current channel model.
A merchant selling into one country often starts with a single consumer channel. Trade customers usually need different prices, minimum order quantities or payment terms, which pushes the design toward a second channel or a pricing layer built on top of the channel model. Confirm early which of those trade rules Saleor covers natively and which need an app or extension. This setup is simplest when trade customers buy a small, fixed set of products at one published wholesale price.
- Separate wholesale channel: Add a second channel when trade prices, order minimums or checkout rules differ from retail.
- Shared stock, separate prices: Both channels can draw on the same warehouses while holding different price sets, so inventory is counted once.
- Account-specific pricing: Negotiated prices per customer or account usually need an app or a custom extension. Prototype this against the API before committing the design.
- Payment and approval flows: Split payments and multi-gateway support may cover deposit or invoice flows, but confirm the gateway you need is supported.
- Customer segmentation: Decide how trade accounts are separated from retail accounts in the data model so reporting stays clean.
Before you build, ask the trade team to write down every rule a wholesale order must follow, then check which ones the channel model handles and which need custom code.
Some merchants define products once and list them in several storefronts, changing only availability, price and stock by channel. Saleor's product, attribute and variant model is built for this pattern, so one product record can appear in many channels. The main risk is not in the data model itself but in how each channel's listing, price and warehouse assignment are kept consistent. This setup is simplest when the catalog is identical across markets and only prices and availability differ.
- One product record: Product types, attributes and variants are maintained once and reused across channels.
- Per-channel listing: A product must be published in each channel where it should appear, so check visibility for every storefront separately.
- Stock allocation: Warehouses assigned to several channels can oversell if the same stock is promised twice, so confirm how allocation behaves under your order volume.
- Localized content: Translations and market-specific descriptions are a separate workload, and the choice of content tool affects it.
- Change control: Set a rule for who may change a shared product and whether that change reaches every channel at once.
Test the stock behavior for a shared warehouse with a staging dataset before go-live, and confirm the current channel and allocation settings in the Saleor documentation for your release.
Extending Saleor through apps, webhooks and metadata
Saleor does not run custom code inside its core process. Every extension sits outside it and connects through the GraphQL API, events or stored data, so each choice you make carries deployment and failure work. The four mechanisms below cover different needs, and most commercetools projects will use more than one.
Webhooks for event-driven integration
Webhooks send Saleor events, such as order creation or product updates, to an endpoint you run. Your receiver handles the event and calls other systems, such as an ERP, a tax service or a fulfillment partner. Commercetools subscriptions cover a similar role, so check which events you need, how retries behave when your endpoint is down, and whether your receiver can process the same event twice without duplicate orders.
Apps for bundled functionality
Apps package a backend service and its configuration as a unit that Saleor Dashboard users can install and operate. They suit features such as a payment connector or a search sync that needs its own storage and screens. Before you adopt an app, confirm who maintains it, which Saleor versions it supports, and where its service runs, because an app is another component your team must upgrade and monitor.
Metadata for custom attributes
Metadata stores extra key-value data on objects such as products, orders and checkouts, without a schema change to Saleor. It fits attributes a storefront or integration needs, such as a supplier code or a loyalty flag. Keep private metadata for internal values and public metadata for storefront use. Commercetools custom fields need a type definition, so plan a naming convention and a review step, because metadata is easy to add and hard to clean up later.
API extensions for custom queries
API extensions add custom GraphQL operations or fields that your storefront and back-office tools call through the same API. They let you expose a combined view, such as stock across warehouses with a regional rule applied, without making clients stitch together several queries. Treat each extension as code you own, with versioning, tests and performance checks, since a slow custom query affects every client that calls it.
Separate services and failure handling
Because Saleor avoids in-process plugins, logic that commercetools teams often place in extensions moves into services with their own deployments, queues and on-call duties. Decide ahead of time how each service behaves when a webhook is late, when a receiver returns an error, or when an external system is down. Ask your implementation partner for a written list of failure modes and recovery steps before you cut over checkout or order flows.
Who controls hosting, data location and rate limits
Hosting control is the first decision this comparison forces. commercetools runs Composable Commerce in hosted regions on Google Cloud and AWS, so the provider sets the infrastructure, patching and region options, and you choose among the regions it offers. Saleor can run in two ways: as Saleor Cloud managed hosting, which keeps the hosting relationship close to the commercetools model, or self-hosted with Docker in infrastructure you select. Before you shortlist either, confirm with each vendor which regions and sub-processors apply to your contract and which data categories, including customer records and orders, sit in that region.
Self-hosting moves data location and infrastructure control to your organization. You decide which cloud account, data center or private network holds the PostgreSQL database, the API, the Dashboard, the Celery workers and the cache, and you can keep all of them inside a jurisdiction or an air-gapped segment. That control also transfers the compliance evidence. Access reviews, backup restore tests, change records and logging for the Saleor stack become your responsibility, and an auditor, not DeployOpen, issues any report. DeployOpen can prepare the controls and collect the evidence your assessor will ask for, but the attestation itself comes from the independent auditor you engage.
Rate limits work differently in the two models. commercetools' production rate limits are a SaaS term you should confirm in writing with the vendor, including how they apply to bulk imports, API bursts and your planned storefront traffic. A self-hosted Saleor deployment has no vendor-imposed ceiling, so its throughput depends on the sizing your team chooses: API and worker instance counts, database resources, cache capacity and how many Celery workers run in parallel. Load test those components against your expected peak order volume, including a full catalog import, before you commit to a migration date, and budget the hosting capacity for that peak as a recurring cost.
Hosting models, identity and compliance implications
Moving from a commercetools SaaS to a self-hosted Saleor changes who controls where data sits, who administers the platform, and who answers for logs, backups and licensing. Each card below covers one of these decisions and the condition under which it becomes a compliance question.
Data location and residency
commercetools chooses from a set of hosted regions on Google Cloud and AWS, so residency is a region selection you confirm in its contract. With Saleor, the database, object storage and Celery workers sit wherever you deploy them. If a national rule or sovereign-cloud requirement applies, map every component that stores customer, payment or order data, including backups and logs, and confirm each one lands in an approved location.
Hosting model options
Saleor is offered as Saleor Cloud managed hosting or self-hosted with Docker. Choosing self-hosting moves patching, scaling and availability from the vendor to your platform team. Ask whether a managed Saleor Cloud option meets your residency rules before committing to a self-managed build, because it can reduce operating load while keeping some control.
Identity and admin access
Dashboard administrators, API tokens and app credentials become your responsibility. Define who can change prices, channels and promotions, how staff authenticate, and how service tokens are rotated and revoked. Confirm how your identity provider integrates with Saleor staff accounts, since this is a configuration decision you own rather than a default you inherit.
Audit logging and evidence
In a SaaS, the vendor operates much of the logging and retention layer. Self-hosted Saleor leaves you to decide what the API, Dashboard and worker logs record, where they go, and how long they are kept. Auditors will ask for evidence of who changed prices or refunded orders, so confirm which events are traceable from logs and which need your own event store.
Backup and disaster recovery ownership
Saleor depends on PostgreSQL and a cache or queue layer, so backups and restore tests for both are yours to design, schedule and prove. Define recovery objectives with the business before go-live, and rehearse a full restore into a separate environment. Ask commercetools for its own recovery terms in writing so you can compare them against what your team will run.
Licensing terms
Saleor is BSD-3-Clause licensed, which permits commercial use, modification and redistribution with notice. Your costs shift to infrastructure and engineering rather than a license fee. Have legal review the BSD-3-Clause notice requirements and any third-party apps, extensions or hosted services you add, since those carry their own terms.
What a move from commercetools to Saleor involves
The sequence turns commercetools product types, channels, prices and checkout behavior into a Saleor configuration that is verified order by order before the old backend is retired.
Inventory product types, channels and prices
Your team lists every commercetools product type, attribute, channel, price list, currency, tax setting and store-level stock location, and records which storefronts and integrations read each one. The output is a written inventory that names every resource and its consumers, reviewed by merchandising, finance and engineering. The step is done when someone outside the project can read the inventory and identify what each storefront depends on.
Export catalog, customers and orders
Export products, categories, customers and historical orders from the Merchant Center or the HTTP API, following the export guidance for each resource type. Engineers check record counts and sample records against the live system, since file size limits and export limits can split or truncate data. The step is done when counts match and a reviewer has spot-checked records from each resource type.
Map attributes and channels to Saleor
Map commercetools product types and custom fields to Saleor product types, attributes and channels, and map each price list to per-channel pricing in the currencies you sell. Stock levels are mapped to Saleor warehouses so that each channel draws from the right locations. The output is a mapping document that business owners sign off, and it is done when every commercetools price and stock value has a named Saleor destination.
Import data through the GraphQL API
Write import scripts that call Saleor's GraphQL API to create channels, warehouses, product types, products, variants and prices in dependency order, running first against a staging instance. Failed records are logged and re-run after correction. The step is done when staging imports complete with no unexplained failures and a comparison report shows matching product, price and stock totals.
Rebuild promotions and checkout logic
Recreate commercetools discounts as Saleor promotions, vouchers, cart rules, sales or gift cards, and test each rule against the cart totals that commercetools produced for the same baskets. Tax, shipping and payment steps are rebuilt alongside them and tested with split payments and returns where you use them. The step is done when a set of reference carts produces identical totals in both systems, or each difference is documented and approved.
Rework integrations and extensions
Replace commercetools subscriptions, API extensions and custom application logic with Saleor webhooks, apps and metadata, since Saleor does not run in-process plugins. Connect payment gateways, ERP, warehouse, tax and fulfillment systems to the new endpoints and update storefront GraphQL calls. The step is done when each integration has a test in staging and a named owner who has signed off its behavior.
Run both backends until orders verify
Operate commercetools and Saleor in parallel on a controlled set of traffic or markets, comparing orders, payments, stock movements and fulfillment events between them. Discrepancies are traced to mapping, promotion or integration causes and fixed before more traffic moves. The step is done when order flows have been verified across each channel and payment method you run, and the cutover decision is recorded in writing.
Operate Saleor and retire commercetools
After cutover, your team takes on hosting, PostgreSQL, Valkey or Redis, Celery workers, upgrades, backups and monitoring for Saleor, and keeps the export archive for records you must retain. Ongoing cost is set by the infrastructure and staff you choose, and the subscription ends only after the retention plan is confirmed. The step is done when runbooks exist for upgrades and incidents and the commercetools contract terms for data return have been checked.
Questions buyers ask before switching from commercetools to Saleor
How much does switching from commercetools to Saleor cost?
No single number applies, because the cost is the sum of separate components: the commercetools subscription and add-ons you stop paying for, the migration project, the rebuilt integrations and discounts, the infrastructure that runs Saleor, and the engineers who operate it. The one-time items are the migration, data mapping, storefront changes and parallel running. The recurring items are hosting, database and cache services, worker capacity, upgrades and support. Saleor itself is BSD-3-Clause licensed, so there is no license fee for the core, but a managed option such as Saleor Cloud is a separate purchase. Ask any implementation partner for a quote built from a written scope, and ask commercetools for your current contract terms, since it does not publish its prices.
How long does a commercetools to Saleor migration take?
The pace is set by the amount and complexity of what you migrate, not by the platform alone. The main drivers are the number of product types and attributes to map, how many channels, price lists and warehouses you run, how many discounts and checkout rules you must rebuild, how many custom integrations depend on commercetools APIs, and whether you run both backends until order flows are verified. Saleor is configured through its GraphQL API and apps, so teams that already use GraphQL often move faster. Your timeline should come from a written scope with named milestones. Treat any duration you hear before that scope exists as a guess.
Can our in-house team migrate to Saleor without outside help?
A capable in-house team can do it, provided it has the skills the work demands. Those include Python and Django familiarity for Saleor's internals, GraphQL for data import and storefront calls, PostgreSQL administration, and experience with Docker and environment-based configuration. The hard parts are usually not the core install but the data mapping, rebuilding promotion logic, and confirming order, payment and tax flows match what you had. Consider whether those skills are available for the full project and after launch. If they are not, an outside team can be scoped for specific pieces, such as planning, implementation, hardening or testing, while your team keeps ownership.
What roles and skills do we need to run Saleor after launch?
Running Saleor needs more than an application team. Saleor's Docker Compose setup runs the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, and it asks for at least 5 GB of memory for Docker, according to the Saleor Docker Compose docs. You will need people who own the infrastructure and backups, people who handle upgrades and release testing, and people who support the storefront and integrations. Plan for on-call coverage, monitoring of workers and queues, and a tested restore procedure. Before you commit, ask your team to size these roles against your order volume and recovery targets.
Is Saleor Cloud an option if we do not want to host Saleor ourselves?
Yes. Saleor is offered as Saleor Cloud managed hosting or self-hosted with Docker, according to the Saleor GitHub repository. Choosing Saleor Cloud changes who operates the servers and databases, but you still own your data model, integrations and storefront. Compare it with self-hosting on three points: where your customer and order data is held, which operational tasks the vendor covers, and what the subscription costs at your volume. Confirm the hosting regions and data handling terms directly with Saleor before you decide.
How does Saleor's licensing differ from commercetools?
commercetools Composable Commerce is a commercial SaaS subscription, and its terms govern your use of the hosted service. Saleor's source code is BSD-3-Clause licensed, which permits you to run, modify and distribute the software, subject to the license conditions. Licensing of the code does not cover every cost, however. You still pay for hosting, staff, integration work and any managed service you choose. Have counsel review the BSD-3-Clause terms and any Saleor Cloud agreement, and check how your own extensions and apps will be licensed.
Which parts of commercetools behavior should we verify in Saleor first?
Start with the features your revenue depends on. Check that Saleor's per-channel pricing, currencies and stock across multiple warehouses match how you sell today. Test the promotion engine with sales, vouchers, cart rules and gift cards against your real campaigns. Confirm split payments, returns and multi-gateway payment handling in a staging environment with your payment providers. Because Saleor extends through webhooks, apps and metadata rather than in-process plugins, review every custom extension you have on commercetools and decide how it will be rebuilt.
When a fixed-scope engagement makes sense
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted Saleor inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. For a team that has decided to run Saleor, the work usually splits into a defined body of work: deploying the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, configuring channels, warehouses and promotions, building the apps and webhooks that replace commercetools extensions, and documenting how the system is operated afterward. Most engagements of this kind are fixed-scope, so the channels to be configured, the integrations to rebuild and the environments to deliver are agreed in writing before any work starts.
A quote follows from that written scope. DeployOpen does not publish a price list, so the number you receive depends on what you ask us to deliver, how many markets, warehouses and integrations are involved, and which environments you need. To compare fairly, ask every vendor to state the deliverables, the environments, who performs the data migration checks, and what is excluded. Ask for the same breakdown from your internal team so that the in-house cost of building and running Saleor can be set against it.
Ongoing work is handled separately. Retainers cover upgrades, which matter because Saleor publishes new releases regularly, and continuous security testing of the storefront and API. Confirm with us, in the written scope, which of these you will need after go-live, how often upgrades will be applied to your environment and who signs off on them. Keeping that decision explicit at the start avoids leaving a self-hosted commerce platform without an owner once the migration project closes.
How DeployOpen helps evaluate, implement or migrate Saleor
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For commercetools vs Saleor, the work usually starts with a written scope that compares your channels, promotions and fulfillment needs against what you would run yourself.
How we scope
- Map your current commercetools channels, price lists, stock locations and promotions to Saleor channels, warehouses and discount types.
- List the apps, webhooks and external systems that Saleor would need to replace or reconnect, with each integration named.
- Agree the scope, deliverables and timeline in writing before work starts, since most engagements are fixed-scope.
How we build
- Deploy the Saleor API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers in your environment, configured through environment variables.
- Build the channel, currency and warehouse configuration, then test price and stock behavior per market against your written requirements.
- Test the GraphQL integrations, checkout flow and promotion rules, and run security testing on the application and its APIs.
How we hand over
- Document the deployment, configuration, environment variables, backup routines and the operating runbook for your own team.
- Prepare the controls and evidence your compliance assessors will ask for, while noting that independent auditors issue any reports.
- Walk your engineers through the app and webhook extension model so they can maintain it after handover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover.
- Plan Saleor version upgrades and patching against your own change process, with each upgrade tested before production.
- Keep backup and restore procedures current, and confirm recovery steps with your team on a schedule agreed in the retainer.
