How a multi-brand team migrates from Salesforce Commerce Cloud to Saleor
A multi-brand, multi-region B2C team usually moves to headless Saleor when a Commerce Cloud renewal, a data residency requirement or concern about lock-in forces a decision on the platform. The work is typically run by in-house solution and platform architects, with an implementation partner covering the parts that the internal team has not yet done at this scale. Saleor is BSD-3-Clause licensed and can be self-hosted with Docker or taken as Saleor Cloud managed hosting, so the choice of who operates it is separate from the choice of software. Effort and risk are hard to size before the catalog, storefront and integration inventory exists. Ask any partner for a written scope that lists each brand, market, storefront and integration before accepting a timeline, because duration and cost follow from that inventory, not from the platform itself.
Most of the effort sits outside the backend. Saleor replaces the Commerce Cloud catalog, pricing and order services with channels, per-channel currencies, stock and products across warehouses, but each storefront must be rebuilt against the GraphQL API, whether the current front end is SFRA or PWA Kit. Plan the storefront rewrite, checkout flow, search and the middleware that connects to your ERP, payment providers and CRM as separate workstreams with their own owners and acceptance tests. Cartridge logic also needs translation: business rules that lived in cartridges become Saleor apps, webhooks and metadata, so the team should list every custom cartridge and decide, one by one, whether it is retired, rebuilt as an app or moved to an external service.
Run the cost model with the operating side in view. The Saleor Docker Compose setup asks for at least 5 GB of memory and requires the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers, so the infrastructure team must own hosting, backups, patching and monitoring if you self-host. Ask the partner to state, in writing, which of these items are one-time build costs and which recur each year: hosting, licensing for any paid add-ons, support, and the internal staff who maintain the storefronts. Confirm with Saleor which support option fits your environment before the contract is signed.
Which Commerce Cloud capabilities map to Saleor, and which need rework
This table maps the main Commerce Cloud capabilities to their Saleor equivalents and marks each as clean, needs rework or gap. Read the status column first, then the notes, to see where Saleor covers the need through channels, warehouses, the promotion engine or apps, and where your team must build or confirm behavior. Treat every status as a starting point to verify against your own requirements and Saleor's current documentation.
| Capability | Saleor equivalent | Status | Notes for the migration |
|---|---|---|---|
| Sites and locales | Channels, one per storefront or region | Needs rework | Map each SFCC site to a channel and storefront, then confirm how locales and content are handled in your headless frontend. |
| Price books | Per-channel pricing on product variants | Needs rework | Price books do not map one to one. Rebuild pricing per channel and confirm how your current price book hierarchy must be flattened. |
| Currencies | Per-channel currency settings | Clean | Saleor supports per-channel currencies. Confirm rounding and tax rules for each market with your finance team. |
| Catalogs and products | Products, variants, attributes and categories via GraphQL | Needs rework | Catalog structure must be remodeled around Saleor product types and attributes, and exports need transformation before import. |
| Stock and multi-warehouse fulfillment | Warehouses assigned to channels | Clean | Saleor supports multiple warehouses across channels. Confirm how allocation rules map to your current inventory logic. |
| Promotions | Sales, vouchers, cart rules and gift cards | Needs rework | Promotion engine covers common cases. Complex SFCC promotion logic built in cartridges must be restated as Saleor rules and confirmed. |
| Payments | Split payments and multi-gateway support | Needs rework | Saleor supports multiple gateways. Each gateway integration must be rebuilt or reconfigured for your providers. |
| Returns | Returns in the order flow | Needs rework | Confirm return reasons, refund paths and restocking behavior against your current process. |
| Cartridge-specific pipelines | Apps and webhooks | Gap | Cartridge pipelines have no direct equivalent. Each custom step must be rebuilt as an app or webhook handler. |
| SFRA-only storefront logic | Headless storefront against GraphQL | Gap | SFRA templates and controllers are not reused. Storefront logic must be rewritten in your chosen frontend. |
| Customer data | Customer accounts and addresses via API | Needs rework | Customer exports need field mapping and password handling confirmed with your identity approach before import. |
| Personalization and order management | Confirm with Saleor documentation | Gap | Confirm these needs against Saleor's documentation and your requirements, as they may need a separate system. |
Which data exports carry over and which integrations must be rebuilt
Catalog, customer, order and content data move through different export paths, and each needs conversion before it fits Saleor's data model. The integrations around the store, including CRM, ERP, payments, tax, search and order management, do not move at all and must be rebuilt as Saleor webhooks and apps.
Catalog and pricing data
Products, variants, categories and price books leave Commerce Cloud as XML exported from Business Manager, built on Salesforce's own schemas. Saleor needs these mapped to its product types, attributes, channels and per-channel prices, so a price book usually becomes channel-specific pricing rather than a single list. Confirm the export scope, record counts and any file size limits for your instance before planning batches, because they vary by configuration.
Customer and account data
Customer profiles, addresses and login identities need a deliberate decision. Password hashes generally cannot be carried into a new identity system without the source platform's cooperation, so plan for password resets or a migrated identity provider. Confirm with your security team how stored credentials and consent records are exported and retained under your policies.
Order history and statuses
Historical orders are needed for customer service, returns and finance, but they rarely need to be live objects in the new store. Many teams import closed orders as read-only records and keep open orders in the old system until they settle. Map Commerce Cloud order statuses to Saleor's fulfillment and payment states, and confirm which order fields your finance and returns teams actually depend on.
Content and site assets
Content assets, landing pages, URL structures and redirects sit outside the catalog and often get missed. Images and documents must be transferred separately and their URLs remapped in the new storefront. Build a redirect table from old storefront URLs to new routes before cutover so search rankings and bookmarks survive.
CRM, ERP and order management
Commerce Cloud integrations with CRM, ERP and order management run through cartridge code and Salesforce services. In Saleor these connections are rebuilt as apps that subscribe to webhooks for orders, customers and fulfillment events, then sync to the external system through its own API. Document each existing data flow, its frequency and its owner before designing the replacement.
Payments, tax and search
Payment gateways, tax calculation and site search are the integrations most likely to need a new provider contract or certification. Saleor supports multi-gateway payments, so confirm each gateway's Saleor integration and its data residency terms. Tax and search providers may need new configuration, and search indexes will be rebuilt from the new catalog rather than copied.
The migration sequence from inventory to decommission
This sequence moves a Salesforce Commerce Cloud estate to Saleor one brand or region at a time, so each phase produces evidence that the next phase depends on. Each step closes with a named artifact that shows whether the work can move forward.
Inventory sites, cartridges, price books and integrations
Your architects and Commerce Cloud administrators list every site, storefront codebase (SFRA or PWA Kit), cartridge, price book, currency, locale, customer group, promotion and external integration, including payment, tax, order management and CRM connections. Each item is tagged with the brand, region and owner who depends on it. The step is done when the inventory is signed off by merchandising, finance and operations, and every item is marked as migrate, rebuild, replace or retire.
Build the channel map and data mapping specification
Platform engineers translate the inventory into a channel map that assigns each brand or region to a Saleor channel, with its currency, default warehouse and stock rules, and then into a data mapping specification covering products, variants, attributes, prices, customers and orders. The specification states which fields come from the Commerce Cloud exports and which are rebuilt. It is complete when a reviewer can trace each source field to a Saleor destination or an explicit decision to drop it.
Run a pilot on one brand or region
Choose one brand or region with a manageable catalog and a single channel. Load its products, prices and stock into a non-production Saleor environment through the GraphQL API, rebuild the storefront calls for that channel, and connect payment and tax sandboxes. Test promotions, returns and checkout end to end with the merchandising and support teams. The pilot closes with a defect log and a list of rebuilt apps and webhooks that must be production-ready before the parallel run.
Operate a parallel run with test orders
Both platforms receive the same test orders for the pilot brand or region over an agreed period. Finance and operations compare totals, tax, discounts, stock deductions, payment captures and fulfillment messages between Commerce Cloud and Saleor. The output is a test order reconciliation report listing every mismatch, its root cause and the fix. The step is done when the remaining mismatches are documented and accepted by the business owner.
Cut over region by region or brand by brand
Repeat the pilot pattern for each remaining channel, moving one brand or region at a time with a cutover runbook. The runbook sets the freeze window for catalog and price changes, the final incremental data load, DNS and routing changes, payment webhook switches, and the rollback criteria with the named owner who can trigger rollback. Each cutover is complete when orders placed on the new channel reconcile with the warehouse and finance records.
Retain Commerce Cloud data and decommission
Keep Commerce Cloud available in read-only mode for the retention period your legal, tax and audit teams require, and confirm that exports, order history and customer records are archived in a format you can search. Only after that period is met do you disable the storefronts, stop scheduled jobs and cancel the contract. The step is done when your records show the retention requirement was satisfied, the archive is verified, and access to the old platform has been removed.
What drives cost and duration in a Saleor migration
This table lists the main factors that move the cost and schedule of leaving Salesforce Commerce Cloud for Saleor, with the reason each one matters and how to keep it under control. Read it as a checklist for scoping and for reviewing written quotes, since each driver usually multiplies work across the others.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| Channels, sites and brands | Each Commerce Cloud site becomes a Saleor channel with its own currencies, pricing, stock and products, so every extra brand or region adds mapping, testing and merchandising work. | Confirm which sites are truly separate brands and which are locales of one storefront. Ask the vendor to price a first wave of channels and add the rest later. |
| Catalog size and variants | Product, variant and attribute counts drive transformation scripts, validation passes and image handling. Price books must be remapped to channel-level pricing. | Clean up inactive products and duplicate variants before export. Ask for a sample migration run on a representative subset before pricing the full catalog. |
| Cartridge logic depth | Custom cartridge code for pricing, promotions, shipping or tax does not port directly. Each piece must be redesigned as a Saleor app, webhook or metadata-driven rule. | Inventory every cartridge hook and job, then mark each as keep, drop or rebuild. Ask the quote to list each rebuilt behavior as a separate line item. |
| Storefront rebuild scope | SFRA or PWA Kit storefronts are tied to Commerce Cloud APIs. Moving to a GraphQL storefront means rewriting templates, state handling, checkout flows and personalization hooks. | Decide early whether the storefront is rebuilt or reused. Ask for a fixed list of pages and flows in scope, and whether checkout is included. |
| Integration count | Each ERP, OMS, payment gateway, tax engine, CRM or marketing tool needs a new connection, usually through webhooks and API calls, and its own test cycle. | Rank integrations by business criticality and retire unused ones. Ask whether each integration is priced separately and who owns credentials after handover. |
| Order history volume | Historical orders, returns and customer records must be converted and reconciled. Large volumes lengthen import runs and validation, and matching statuses across systems takes manual review. | Decide how much history is needed for service and finance, and keep older records in an archive. Ask how imports are verified and how long a parallel run is planned. |
| Hosting model | Self-hosted Docker deployments need the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers, with at least 5 GB of memory for Docker according to the Saleor Docker Compose docs. Saleor Cloud shifts infrastructure work to a managed service. | Compare run costs for self-hosting and Saleor Cloud over the same period. Ask the quote to separate one-time setup from recurring infrastructure, monitoring and upgrade effort. |
What usually goes wrong and how to prevent it
Most failed moves from Salesforce Commerce Cloud to Saleor do not fail on the platform itself. They fail on the storefront, the channel model, the stock data, the history that never made it across, the webhooks that stall under load, and the infrastructure that was sized for a demo. Each card below names one risk and the check that catches it before cutover.
Underestimating the storefront rebuild
SFRA or PWA Kit storefronts carry cartridge-level logic for pricing display, promotions, checkout steps and account pages. Saleor serves all of this through GraphQL, so each template, query and checkout step has to be rebuilt or re-pointed, and the storefront becomes your team's code to run. Inventory every storefront route and feature flag in the current site, map each to a GraphQL query or mutation, and agree the list of pages in scope before estimating the work.
Mismatched currency and tax rules
Saleor prices and currencies are set per channel, so a site that shows euros, dollars and sterling with different tax treatment needs each channel configured with its own currency, tax settings and pricing. A channel that inherits the wrong rounding or tax rule produces orders that look correct in the storefront and wrong in accounting. Build a written channel model listing each site, currency, tax rule and price list, then place test orders in every channel and reconcile totals against the Commerce Cloud output for the same basket.
Stock sync errors across warehouses
Saleor supports multi-warehouse stock, but the stock your storefront shows depends on how the warehouses are assigned to each channel and how the ERP or WMS writes quantities back. If inventory feeds update one warehouse while the channel reads another, customers can buy stock that does not exist. Document which warehouse serves which channel, define who owns each stock figure, and run a side-by-side stock count comparison for several SKUs before the first live order.
Lost customer and order history
Commerce Cloud customer, order and loyalty data often arrives in XML exports with fields that do not map one to one to Saleor's model. Addresses, order statuses, return records and customer notes can be dropped silently in transit, and customers then reach the new site with no past orders. Reconcile record counts for customers and orders against the source export, sample individual records by hand, and keep the original store readable for a defined period so that support staff can look up history.
Webhook failures under load
Saleor extends through webhooks and apps rather than in-process plugins, so payment confirmations, fulfillment updates and tax or shipping calculations depend on events being delivered and handled reliably. During a promotion or peak traffic, a slow or failing app endpoint can delay orders or leave them in an inconsistent state. Load test the webhook path with realistic order volumes, confirm retry and dead-letter behavior in your apps, and monitor failed deliveries from day one.
Under-sized infrastructure at cutover
Saleor runs as several components: the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers. The Docker Compose setup asks for at least 5 GB of memory for Docker, which is a development baseline and not a production sizing. Teams that size only the API and database often find Celery queues backing up or cache misses slowing checkout during the first sales event. Run capacity tests against the expected peak, size each component separately, and agree a rollback path before cutover.
How the migration differs by starting point and team
Teams that already run a PWA Kit storefront have a React codebase that talks to the Salesforce commerce APIs. That code is the part most likely to carry over in some form, because the UI components, routing patterns and page-level logic are written in JavaScript and React. The backend calls are different. Saleor exposes everything through GraphQL, so product, cart, checkout and account queries must be rewritten against Saleor's schema rather than reused as they are. The hosting question also changes, since the storefront will need a home once Managed Runtime is no longer in use.
- Component reuse: Presentational React components and styling often move with little change, while data-fetching hooks and API adapters are rewritten.
- Checkout flow: Shopper-facing checkout logic, including payment steps and address validation, is rebuilt against Saleor's checkout and payment mutations.
- Hosting ownership: The storefront needs a host you control, with build, caching and monitoring defined by your team.
- Session and account data: Logged-in shopper sessions and saved carts need an explicit migration or re-login plan.
- Test coverage: Existing end-to-end tests show which journeys must keep working and make parity checks faster.
Before committing, confirm which PWA Kit extensions and third-party connectors your storefront depends on, and whether each has a Saleor app or webhook equivalent.
Teams on SFRA with a deep cartridge stack carry the most business logic inside server-side controllers, pipelines and custom models. Those cartridges usually hold pricing overrides, promotion rules, integration jobs and custom checkout steps. Saleor does not run in-process plugins, so each piece of cartridge behavior must be re-expressed as a Saleor app, a webhook handler, metadata or an API extension. This is where most of the engineering effort sits, and it is easy to underestimate because cartridge logic is often undocumented.
- Controller inventory: List every route, pipeline and hook in each cartridge, then mark whether it is storefront, back-office or integration logic.
- Pricing and promotions: Custom price adjustments are rebuilt using Saleor's channel pricing and promotion engine where possible, with custom logic moved into apps.
- Integration jobs: Scheduled jobs that push orders or pull stock become external services or Saleor apps that listen to webhooks.
- Custom attributes: Product and customer extensions stored as custom attributes or metadata need a mapping to Saleor's data model.
- Dead code: Cartridges often contain paths nobody uses, and removing them before migration reduces scope.
Confirm with your developers which cartridges are still in active use and which business rules are written only in code, since those rules must be captured before anything is rebuilt.
A single-brand team has one storefront, one catalog and usually one primary currency set, so the Saleor design can stay simple. A single channel may be enough, although some teams still add channels for separate markets or sales events. The main work is the storefront rebuild and the cartridge rewrite, not the structure of the catalog. Scope tends to be easier to freeze, and cutover planning is more straightforward because there is only one live site to switch.
- Channel model: One channel with one currency and one warehouse may cover the current estate, which keeps configuration small.
- Catalog mapping: Product types, variants and categories map directly from the export files, with fewer exceptions to handle.
- Cutover: Only one storefront needs DNS, redirect and search engine planning.
- Order history: Historical orders can be imported as a single dataset with one set of statuses.
- Simplicity risk: Small estates can still hide complex promotion or tax rules that need the same care as larger ones.
Confirm whether your single brand plans additional markets within the next release cycle, because adding channels later is possible but changes pricing and stock design.
Teams running several brands or regions on Salesforce sites with shared or separate price books are the reason Saleor is a strong fit. Saleor's channels can represent different sites, currencies and stock, and its per-channel pricing and multi-warehouse support map closely to multi-site price book setups. The design work moves earlier: every brand, region and currency combination needs a clear channel, warehouse and pricing decision before the catalog is loaded. Mistakes here are expensive because they spread across every product.
- Channel design: Decide whether each brand, region or currency combination gets its own channel, and document the reasons.
- Pricing: Map each price book to channel-level prices, and check how tax and rounding rules differ by market.
- Stock: Assign warehouses per channel where fulfillment differs, and test allocation rules with real order patterns.
- Shared catalog: Decide which products are shared across brands and which are brand-specific, because this affects product and channel listing data.
- Governance: Name an owner for channel configuration so later changes do not drift between brands.
Confirm your channel and warehouse model with the commerce, finance and fulfillment leads for each market before you start the catalog transform.
Teams without in-house engineers cannot treat Saleor as a configure-and-go product. Saleor is an API-first platform, so storefront development, apps, webhooks and hosting all need skilled people, whether employed or contracted. The question is less about the software itself and more about who will build, run and patch it after launch. A migration plan that assumes internal ownership without staffing it tends to leave the store without a clear support path.
- Build capacity: Storefront, integrations and data migration are external work unless you hire or contract for them.
- Run capacity: Saleor needs the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers kept running, with updates applied on a schedule.
- Support model: Decide who answers incidents at night and who approves configuration changes from business users.
- Knowledge transfer: Require documentation, runbooks and handover sessions as deliverables, not as informal follow-up.
- Ongoing services: Ongoing support, upgrades and testing are often contracted as a retainer, which should be defined in the written scope.
Ask any implementation partner to describe written deliverables, handover steps and post-launch support options before you agree a fixed scope. DeployOpen plans, builds and supports self-hosted platforms in your own infrastructure, and quotes follow from a written scope.
How to run Commerce Cloud and Saleor in parallel without splitting orders
The safest way to move a multi-brand estate is to give each brand or region one owner: one brand or region at a time routes to Saleor, and every other brand stays on Commerce Cloud until its own cutover is signed off. Splitting by brand keeps a single order inside a single system. Splitting one brand's orders across both platforms is where reconciliation problems start, so avoid it. Before the first cutover, decide which storefront domains, sites and currencies each platform owns, and write that map down. In Saleor, each brand or region maps to a channel with its own currency, pricing and warehouse assignments, so the channel configuration is the control point for routing and should be reviewed with the merchandising and finance owners before any traffic moves.
Inventory and orders need a named system of record for every SKU and warehouse. Where a warehouse stock pool is shared by brands still on Commerce Cloud, pick one platform to own the availability figure and sync the other through a scheduled export or an integration service that writes to the same stock records. Confirm with your operations team whether the warehouse management system accepts updates from two order sources. For order reconciliation, compare daily order counts, payment captures and refunds per channel between the two platforms, and investigate any order ID that appears in both or in neither. Identity is the harder problem: a customer who buys on a Saleor brand and a Commerce Cloud brand needs one profile in your CRM, so decide which platform owns the login and whether the account is migrated, linked or created on first purchase. Keep customer emails, consent records and tags consistent across both sides before any cross-brand campaign runs.
Define rollback criteria before the first cutover, not during an incident. Typical criteria include a sustained rise in failed payments or checkout errors on the Saleor channel, reconciliation gaps that are not explained within the agreed review window, stock figures that disagree with the warehouse system, and customer service contacts about missing orders. Agree who has authority to switch traffic back, how the routing change is made, and how orders placed during the switch are finished on the original platform. Confirm the rollback path in a rehearsal in a non-production environment, and keep Commerce Cloud live for the brand until the first full reconciliation cycle has closed. Ask your implementation partner to put the criteria, owners and rehearsal results in writing as part of the scope.
Questions buyers ask before migrating to Saleor
What does a migration from Salesforce Commerce Cloud to Saleor cost?
No single figure applies, because the cost depends on the scope of work rather than on a list price. Saleor's core is BSD-3-Clause licensed, so the software itself carries no license fee. The recurring and one-time costs are the storefront rebuild against the GraphQL API, the replacement of cartridge logic with apps and webhooks, data mapping, integrations with your CRM, payment and order systems, hosting, and staff time. Hosting is either Saleor Cloud managed hosting or your own Docker-based infrastructure, and that choice changes what you pay each month. Ask any partner for a quote that separates one-time build work from recurring hosting, support and upgrades, and that lists each integration by name.
How long does a Saleor migration from Commerce Cloud take?
Duration varies with the number of sites, brands, regions, price books, custom cartridge features and external integrations. A single-region catalog with a small number of cartridges is a very different project from a multi-brand estate that needs channels for each currency and stock location. The largest variables are the storefront rebuild and the rewrite of business logic that currently lives in SFRA or PWA Kit cartridges. Ask for a timeline tied to a written scope with named phases, and ask which phases can run in parallel with the existing storefront still live.
What must our in-house team provide during the migration?
Your team needs to own decisions that only the business can make. These include which channels map to which brands, regions and currencies, which promotions and loyalty rules must survive, which order statuses and fulfillment rules are in use, and which systems of record stay authoritative. Engineers must also supply access to Commerce Cloud exports, staging environments, payment sandboxes and the CRM and ERP. Plan for product and merchandising staff to validate catalog data after import, because mapping errors are easier to catch by people who know the products.
Can our own team migrate from Commerce Cloud to Saleor without a partner?
A capable engineering team can migrate, but the work is broader than moving data. Saleor is a Python and Django application that exposes everything through GraphQL, extends through webhooks and apps rather than in-process plugins, and needs PostgreSQL, Valkey or Redis, and Celery workers in production. Teams that already run Python services, understand GraphQL and have experience with payment and tax integrations are better placed to do it alone. Teams without that experience usually find the storefront, operations and security hardening take the longest. A partner can take on any part of that work under a fixed-scope agreement.
Does choosing Saleor Cloud or self-hosting change the migration work?
The migration work is largely the same, but the operating model changes. Saleor is offered as Saleor Cloud managed hosting or self-hosted with Docker, so the choice determines who patches, scales, backs up and monitors the API, Dashboard, database, cache and workers. Self-hosting gives you control over data location, network design and upgrade timing, and it moves those tasks to your team or to a partner under a retainer. Confirm with Saleor which hosting option meets your data residency and audit requirements before you design the target environment.
How does the Saleor release cadence affect migration planning?
Saleor publishes regular releases, and the release notes list the changes that matter for integrations. As a current reference, Saleor 3.23.42 was released on October 16, 2026, according to the Saleor GitHub releases page. Plan for the version you deploy to change during a long project. Pin the version used for development and testing, schedule an upgrade review before go-live, and budget time for regression tests on your webhooks and apps. Ask any partner how they will handle upgrades after launch and whether that work is covered by a retainer.
What should we ask a partner for in a migration quote?
Ask for a written scope that names each site, brand, channel, region and currency in the migration. Request a list of Commerce Cloud features to be replaced, with the replacement for each, such as an app, a webhook, a storefront component or a retired feature. Ask how catalog, customer and order exports will be mapped and validated, and who signs off on the results. Ask which environments are included, how cutover and rollback work, what testing is covered, and what happens to the storefront and integrations after launch. Confirm the deliverables, acceptance criteria and whether ongoing support is a separate retainer.
How DeployOpen scopes and runs a Saleor migration
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a move from Salesforce Commerce Cloud to Saleor, we start from a written scope that names the sites, channels, storefronts and integrations in play before any build work begins.
How we scope
- Inventory every SFCC site, locale, price book, currency and warehouse to map into Saleor channels.
- List each cartridge and custom integration, then classify it as an app, webhook, storefront logic or retirement.
- Agree written deliverables, timelines and exclusions with you before work starts, since engagements are fixed-scope.
- Confirm hosting targets, Docker or Kubernetes, and who owns the API, Dashboard, PostgreSQL and Celery workers.
How we build
- Configure Saleor channels, currencies, warehouses and promotions to match your existing multi-brand structure.
- Rebuild the storefront against the GraphQL API, reusing PWA Kit or SFRA components where the logic carries over.
- Write apps and webhooks for payments, tax, order management and CRM sync in place of retired cartridge code.
- Convert XML catalog, price book and customer exports into Saleor import files, then reconcile record counts.
How we hand over
- Test channel pricing, checkout, split payments, returns and warehouse routing against agreed acceptance criteria.
- Document environment variables, deployment steps, app configuration and the data mapping used in the migration.
- Deliver runbooks for backups, upgrades and incident response so your team can operate the stack independently.
- Provide a cutover plan that keeps the legacy store available until imported data is verified.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan Saleor version upgrades with regression tests covering channels, promotions and the storefront.
- Run security testing of the storefront, APIs and apps as part of the written scope where you request it.
- Confirm with us during scoping which compliance evidence we prepare; independent auditors issue any attestation.
