Why teams migrate from Salesforce Commerce Cloud to Shopware and what the work involves
If your Salesforce Commerce Cloud renewal, a licensing change, a data residency requirement or lock-in to SFCC cartridges is forcing a decision, Shopware 6 is a self-hosted or managed option that needs a full data conversion and a storefront rebuild. Nothing in Shopware carries over from Business Manager automatically: catalog, price, customer and order data must be converted into Shopware's model, and the Storefront logic written in SFRA or PWA Kit must be rebuilt as a Shopware theme or as a headless app against Shopware's APIs. Plan the migration as a rebuild with a data project attached, not as a configuration exercise. Most teams run this work through an internal platform team working with an implementation partner. The internal team owns the business rules, the catalog structure, the integrations with ERP, payments and order management, and the cutover decision. The partner typically carries the data conversion scripts, the theme or app development, hardening and the test cycles. Shopware's own licensing shapes the commercial side: the Shopware source is under the MIT License, so the code is free to use, but shops linked to an account that generate more than 1 million euros in gross merchandise value over the preceding 365 days need a paid plan instead of the free Community Edition. Confirm which side of that threshold your estate sits on before you choose a hosting model.
The effort and risk depend mostly on how much SFCC-specific logic you run: custom cartridges, multi-site price books, personalization and order management hooks. Ask any partner for a written scope that lists each export, each cartridge feature and each integration, and for a cutover plan that keeps the Salesforce storefront live until the new one passes testing. Shopware's plan pricing is based on gross merchandise value and other individual factors, so ask Shopware for a quote against your own figures, and ask the partner to separate one-time build work from the recurring hosting, support and maintenance costs.
Which Commerce Cloud capabilities map to Shopware 6, and which need rework
This table compares the main Salesforce Commerce Cloud capabilities with Shopware 6 and marks each as clean, needs rework or gap. Read each row as a planning signal: a clean match still needs data validation, and any row marked gap or unconfirmed should go to a written scope review before migration work starts. Shopware's Community Edition is free to use but carries community-only support, so the plan choice affects how much of the work you can hand to a vendor.
| Capability | Shopware 6 position | Migration effort |
|---|---|---|
| Catalog and price books | Products, variants and prices are managed in Shopware. Price book logic must be mapped to Shopware price rules and customer groups. | Needs rework |
| Customers and addresses | Customer records and addresses can be imported, but password hashes and customer groups need confirmation before import. | Needs rework |
| Promotions and coupons | Shopware offers promotion and discount rules. Confirm that each Commerce Cloud promotion type has an equivalent before rebuilding it. | Needs rework |
| Multi-site setups | Shopware supports multiple sales channels. Confirm how many sites, currencies and languages your estate needs on one installation. | Needs rework |
| Cartridge logic | Cartridges do not carry over. Custom logic must be rebuilt as Shopware plugins, themes or app-based integrations. | Gap |
| B2B quotes and approvals | Available in the Evolve plan according to Shopware's pricing page. Confirm the exact feature set before relying on it. | Gap on Community Edition |
| Payments | Shopware Payments is included in the Community Edition with community support only. Confirm gateway coverage for your markets. | Needs rework |
| Page building | The Community Edition includes a visual page builder. Confirm that your existing SFRA or PWA Kit page templates can be recreated with it. | Needs rework |
Which XML exports, customer records and integrations move to Shopware
Most of the migration effort sits in what leaves Business Manager and how it maps onto Shopware entities. The cards below cover the catalog, price book and customer exports, the order and coupon data that follow them, and the external integrations that must be rebuilt rather than copied.
Catalog XML and product mapping
Catalog exports from Business Manager use Salesforce's XML schemas, with products, variation masters and variants, categories and attributes in separate elements. Shopware models products, variants through property groups and options, and categories as a tree, so each Salesforce attribute needs an explicit target field before any data loads. Confirm the export format and schema version in your own Business Manager, and map a sample of configurable products first to catch variation logic early.
Price book and currency mapping
Salesforce price books are exported per currency and can carry tiered or customer group prices. Shopware stores prices per currency and per customer group on the product, and it supports rules-based pricing for more complex cases. Document every price book, the sales channel it serves and any scheduled price changes, then decide which of these become static prices and which become rules. Test a few products in each currency before cutover.
Customer accounts and addresses
Customer exports carry profile data, addresses and customer groups, but password hashes generally cannot be moved between platforms in a usable form. Plan for a password reset flow, or confirm with your own team and Shopware's documentation how credentials and consent records would be handled. Keep customer group assignments and marketing opt-in status as separate fields, and reconcile duplicate accounts before import.
Order history and coupon codes
Historical orders are usually imported for reference, service and returns, not to recreate payment state. Coupon codes exported as CSV from Business Manager need to be checked for usage limits, validity dates and campaign links, because Shopware promotions are modeled differently. Decide which order fields become read-only records, and agree with finance how open orders, refunds and tax lines are carried over.
CRM, ERP and tax integrations
Connections to the CRM, the ERP and tax calculation are usually built as Salesforce cartridge code or external jobs. Each one needs a new integration in Shopware, either through its API, an app or a middleware layer. Inventory the endpoints, data formats and sync frequency before design starts, and confirm which tax engine the Shopware storefront will call and how product tax classes map to it.
Payment, shipping and identity connections
Payment providers, shipping carriers and identity services are wired into the storefront through cartridge hooks and custom controllers. In Shopware, each one is rebuilt as a payment handler, a shipping method or a plugin, and webhook events must be tested against the new order lifecycle. Check each provider's certification and supported regions with the provider, and test refunds, failed payments and address validation end to end.
The migration sequence from inventory to decommission
This sequence moves a Salesforce Commerce Cloud estate to Shopware 6 in controlled stages, so each site, price book and order record is confirmed before Commerce Cloud is switched off. Each step produces a named artifact that the next step depends on.
Inventory sites, data and custom logic
Your team lists every site, locale, catalog, price book, promotion, customer segment and cartridge in Business Manager, and records which cartridge hooks carry business rules such as tax, shipping, promotions and payment. The architecture lead also records which integrations (ERP, OMS, CRM, payment and tax services) read from or write to Commerce Cloud. 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 a pilot store with a representative catalog
Install Shopware 6 in the infrastructure you control, choose the Community Edition or a paid plan after checking your gross merchandise value position, and build one storefront theme against a subset of products. Choose a pilot catalog that includes variants, bundles, B2B price tiers and at least one localized market, so it exercises the hardest data shapes. The step is done when the pilot store can display, price and check out those products end to end in a test environment.
Convert and validate catalog, price and customer data
Your data engineers map the XML catalog, price book, customer and order exports from Commerce Cloud to Shopware's product, price, customer and order structures, and write repeatable import scripts. They then run the scripts against the pilot and compare record counts, SKU-level prices, tax classes and customer group assignments against the source. The step closes when a validation report shows zero unexplained differences, and every exception has a documented decision from the business owner.
Rebuild promotions, checkout and integrations
Developers rebuild the cartridge logic that was inventoried, such as promotions, shipping rules, payment flows and service calls, as Shopware plugins, theme changes or external services, and connect them to the ERP, OMS and CRM you retained. Test scripts cover checkout, returns, tax and promotion stacking, with failures logged against the inventory items. The step is done when every item marked for rebuild passes its test cases in staging and the business owner signs the acceptance list.
Run a parallel period with reconciliation
Keep Commerce Cloud live while the new store takes controlled traffic or a defined set of orders, and reconcile orders, payments, stock movements and prices between the two systems each day. Finance checks that tax, refunds and currency conversions agree, and operations confirms that fulfillment and returns work from the new order records. The parallel run ends when reconciliation shows no open variances over an agreed period that your steering group sets in advance.
Plan cutover with DNS and redirects
Document the cutover runbook, covering DNS changes, TLS certificates, URL redirects from every indexed Commerce Cloud URL to its Shopware equivalent, search engine verification, payment gateway webhooks and a rollback path. Rehearse the runbook in staging and confirm the redirect map covers category, product and locale URLs. The step is done when the runbook has been rehearsed, the redirect coverage report is signed off, and the rollback owner is named.
Decommission Commerce Cloud after records are secured
Once the store is live and stable, export and archive the final order history, returns, customer records and invoices in formats your finance and legal teams accept, and confirm that support staff can retrieve them without Commerce Cloud. Then cancel or downscale the Commerce Cloud contract according to its terms, and confirm the renewal and data retention obligations with Salesforce in writing. The step is done when the archive is verified, access is tested, and the decommission record is approved by the data owner.
Community Edition or a paid Shopware plan: how to decide
Shopware's pricing page says shops linked to an account that generate more than 1 million euros in gross merchandise value over the preceding 365 days need a paid plan instead of the free Community Edition. A store below that line can run on the Community Edition under the MIT License, which keeps software licensing out of the budget. The Community Edition includes a visual page builder, product management and Shopware Payments, but support comes from the community only. The recurring cost shifts to your own hosting, engineering, and any agency work, so the real question is whether your team can absorb support gaps without a contractual response time.
- Licensing cost: The Community Edition carries no Shopware subscription fee for stores under the threshold.
- Feature scope: Page building, product management and Shopware Payments are included.
- Support model: Help comes from community channels, not a contracted response time.
- Hosting choice: You can self-host, or use SaaS or PaaS if a vendor offers it for your account.
- Ongoing cost: Hosting, patching, and developer time remain your own expense.
Confirm your trailing 365-day gross merchandise value against the threshold before you commit, and ask Shopware how it measures GMV across linked accounts.
Once a shop linked to an account passes the 1 million euro GMV mark over the preceding 365 days, the Community Edition no longer applies and a paid plan is required. Shopware lists Rise at 600 euros per month with AI-assisted content and 8-hour support response, and Evolve at 2,400 euros per month with B2B quotes and approvals and 4-hour response. Beyond is priced individually and includes 1-hour 24/7 support. Shopware states that plan pricing depends on gross merchandise value and other individual factors, so the listed monthly figures are starting points, not a quote for your store.
- Rise plan: 600 euros per month, AI-assisted content and 8-hour support response.
- Evolve plan: 2,400 euros per month, B2B quotes and approvals, and 4-hour support response.
- Beyond plan: Custom pricing with 1-hour 24/7 support.
- Pricing drivers: Gross merchandise value and other individual factors set the final price.
- Recurring cost: Plan fees repeat monthly, on top of hosting and implementation work.
Request a written quote that states the GMV basis, the plan terms and any renewal conditions before you move the catalog and customer data.
Some teams need a paid plan regardless of GMV because they require B2B quotes and approvals or a contracted support response time. Salesforce Commerce Cloud customers often run negotiated pricing, approval workflows, and account-level ordering, so the feature list matters as much as the threshold. The Evolve plan lists B2B quotes and approvals and a 4-hour support response. Beyond offers 1-hour 24/7 support. The Community Edition offers no contracted response time, so an outage during a peak sales period falls to your own on-call staff. Map each B2B workflow you run today against what the chosen plan includes, and check whether any requirement depends on a custom build.
- B2B quotes and approvals: Listed in the Evolve plan, so confirm how it maps to your negotiated price books and approval chains.
- Support response: Evolve offers 4-hour response, Rise 8-hour, and Beyond 1-hour 24/7.
- Custom workflows: Anything beyond the listed features may need custom development, which is a separate cost.
- Ownership of incidents: Under the Community Edition, your team carries first-line response.
- Service levels: Ask whether the response times are contractual commitments and what happens when they are missed.
Ask the vendor to confirm in writing which B2B features and support terms apply to your specific account and plan.
Shopware can run as SaaS, as PaaS on managed infrastructure, or self-hosted. The choice changes who owns uptime, security patching, backups and scaling, and it interacts with the plan decision because the hosting cost and responsibility sit alongside the software licence. Teams leaving Salesforce often choose self-hosting for data control or to avoid a single hosting vendor, but self-hosting moves operational work to your own staff. A PaaS deployment can reduce that burden while keeping control of the store. Decide the hosting model first, then price the plan against it.
- SaaS: The vendor operates the platform, which reduces infrastructure work for your team.
- PaaS: Managed infrastructure handles much of the runtime, while you keep configuration and data.
- Self-hosted: You control the environment, and you own patching, backups, scaling and incident response.
- Data location: Confirm where customer and order data is stored under each model.
- Exit path: Check how you would move the store later if the hosting model changes.
Ask for the hosting responsibility split in writing, including who handles backups, security patches and disaster recovery under each option.
What drives migration cost and duration
This table breaks the Salesforce Commerce Cloud to Shopware move into its cost components, showing who is paid for each, what drives it up or down, and what to ask for in a written quote. Read it as a checklist for comparing proposals, since the largest swings usually come from storefront rebuild scope, integration count and how much of the cartridge logic is custom. Shopware plan fees are the only recurring line that a public fact sets, so confirm every other figure in writing before work starts.
| Cost component | What drives it | What to ask for in a quote |
|---|---|---|
| Discovery | Number of sites, locales, price books and cartridges in use; undocumented custom code in Business Manager | A written inventory of sites, cartridges, jobs and integrations, with the discovery output as a named deliverable |
| Data conversion | Volume and quality of XML catalog, price book, customer and order exports; variant and attribute complexity | Mapping document from each SFCC export to Shopware entities, validation rules and a test import against a copy of production data |
| Storefront rebuild | Whether SFRA or PWA Kit templates are rebuilt as a Shopware theme or as a headless app; number of page types and custom flows | Page-by-page scope with a list of reused and rewritten components, and the Shopware theme approach named |
| Integration work | Count of connected systems such as ERP, OMS, CRM, payment and tax; whether each has a documented API | An integration list with the owner, direction of data flow and test plan for each connection |
| Hosting and operations | Choice of self-hosted, PaaS on managed infrastructure or SaaS; required environments, backups and monitoring | Hosting topology, who patches and upgrades Shopware, and the recurring support model in writing |
| Shopware plan fees | Shopware states plan pricing depends on gross merchandise value and other factors; Community Edition applies only below the 1 million euro threshold over 365 days | Confirm plan tier, GMV calculation basis and renewal terms directly with Shopware before budgeting |
| Testing | Number of checkout paths, promotions, B2B flows and payment methods; load and security test scope | Test plan with regression coverage, performance targets agreed in scope, and security testing deliverables |
| Internal staff | Time needed from merchandising, IT, finance and customer service during discovery, cutover and hypercare | A staffing assumption table from the vendor, so your team can plan its own allocation |
What usually goes wrong and how to prevent it
Most failed Salesforce Commerce Cloud to Shopware migrations break at the seams between data, logic and operations rather than in the storefront itself. The cards below name the failure points that recur in these projects and the checks that catch them before cutover.
Price book mismatches
Commerce Cloud price books, currencies and customer-group prices do not map one to one onto Shopware price rules, price lists and currencies. A product can import with the right base price and still show the wrong amount for a B2B account or a region. Reconcile a sample of SKUs per price book and currency against the source storefront before cutover, and confirm how each tier is represented in the target.
Lost customer and order history
Customer exports carry profile fields, but order history, saved addresses and password hashes often need separate handling and may not transfer in the same format. Without a plan, returning shoppers arrive with empty accounts and support teams lose the trail for open returns. Confirm with your implementation partner which history is imported, which is kept as read-only archive, and how customers reset credentials.
SEO redirect gaps
Commerce Cloud URL patterns for products, categories and content pages rarely match Shopware's routes. Every indexed URL that lacks a 301 redirect to its new equivalent loses ranking signals and sends shoppers to error pages. Build the redirect map from a crawl and the search console data of the live site, then test a sample of old URLs on staging before launch.
Cartridge logic assumed to be a theme
Cartridge code often contains business logic, such as shipping rules, tax handling and inventory checks, that a theme cannot hold. Teams that scope the project as a visual rebuild discover this late and find the logic missing from checkout. Inventory every cartridge hook and controller, classify each as theme, plugin or external service, and assign an owner before estimating the work.
Promotion rule drift
Promotions built in Commerce Cloud, such as stacked discounts, coupon codes and customer-group offers, can behave differently under Shopware's promotion rules. The rule may still exist while stacking order, usage limits or exclusions change, which shifts basket totals. Run a fixed set of test baskets through both systems, covering each active promotion and common combinations, and record every difference before go-live.
Underestimated integrations
ERP, tax, payment, shipping, CRM and marketing connections usually sit outside the storefront and are often undocumented. Each one needs its own mapping, credentials, test cases and failover behavior, and each depends on data formats the new platform must produce. List every system that sends or receives data from Commerce Cloud today, confirm the owner and contract for each, and test end to end with the production configuration.
Cutover without a rollback path
A cutover that switches DNS and payment credentials at once leaves no route back if orders fail or the catalog is wrong. Keep the source platform live and its order feed open until the new store has processed real orders and reconciled them. Agree in writing the rollback trigger, the person who makes the call, and how orders placed during a rollback are reconciled.
Questions buyers ask before moving from Commerce Cloud to Shopware
How much effort and cost should we expect when moving from Commerce Cloud to Shopware?
No supplied figure sets a total cost for this move, so the honest answer is that cost follows the scope you agree in writing. The main components are the export and transformation of XML catalog, price book and customer data, rebuilding SFRA or PWA Kit storefront logic as a Shopware theme or headless app, re-integrating payments, CRM and order management, hosting, and ongoing operations. Some of these are one-time costs and some recur, including hosting, support and upgrades. Costs rise with the number of sites, locales, price books and custom cartridge features. Ask any implementation partner for a quote that separates these components, and ask Shopware what its plan fee covers in your case.
How long does a Shopware migration from Salesforce Commerce Cloud take?
No supplied fact gives a duration, so treat any timeline as something to confirm against your own estate. The timeline is set by the number of storefronts and locales, how much cartridge logic must be rebuilt, how clean the XML exports are, and how many back-office systems must be reconnected. Parallel running for orders, customers and promotions usually extends the schedule, as does any storefront redesign. A fixed-scope agreement fixes deliverables and dates before work starts, which makes the timeline easier to check against the scope.
What must our internal team provide during the migration?
Your team needs to own the business decisions and the source knowledge. That means a complete inventory of sites, price books, promotions, customer groups, payment and tax rules, and every integration that touches orders or customers. Engineers must document the custom cartridge logic so it can be rebuilt, and someone must sign off on data mapping and test cases. Operations staff should agree on cutover, rollback and freeze windows. Ask the implementation partner to list these inputs in the written scope so gaps are visible early.
Can we run a Shopware migration entirely in-house?
Yes, it is possible for a team with strong Shopware and PHP skills, but it depends on capacity and risk tolerance. The work covers data extraction from XML exports, building a Shopware theme or headless app, configuring checkout and payments, and running security and performance testing. Teams without recent commerce migration experience often underestimate the reconciliation of prices, customer records and open orders. Compare the cost of in-house staff time against a fixed-scope engagement, and confirm which activities you want to keep internal.
Is the Shopware Community Edition enough for an enterprise B2C store?
Community Edition may be enough for some stores, but it depends on what you need from the platform. Shopware's pricing page says the Community Edition includes a visual page builder, product management and Shopware Payments, with community support only. Support response times, B2B quotes and approvals, and the commercial plans listed on that page are not part of it. Review those differences against your SFCC feature list, including B2B workflows and service levels, before choosing.
When does the Shopware paid plan threshold apply to our store?
Shopware's pricing page says shops linked to an account that generate more than 1 million euros in gross merchandise value over the preceding 365 days need a paid plan instead of the free Community Edition. Measure your gross merchandise value across all shops linked to the account, not only the largest one, and track it over a rolling 365-day window. Shopware also states that plan pricing depends on gross merchandise value and other individual factors, so confirm the exact plan, the price and the threshold rules with Shopware before you commit.
Who runs the Shopware platform after launch, and what recurs?
Shopware can run as SaaS, as PaaS on managed infrastructure, or self-hosted, according to its pricing page. Self-hosting shifts hosting, patching, backups, monitoring and security testing onto your team or a partner, and those costs recur. Plan for regular upgrades across the supported minor lines, which the shopware/shopware GitHub releases page shows as 6.7 and 6.6 in the current release cycle. Ask any partner whether ongoing support, upgrades and continuous testing are offered as a retainer, and what that retainer covers.
How the migration changes by store size and starting point
The starting point decides how much of a Shopware migration is data work and how much is rebuilding behavior. A single-site store with a standard SFRA storefront and few custom cartridges is mostly a catalog, customer and order move plus a theme rebuild, and the project can be scoped around one Shopware sales channel, one currency and one tax setup. Before you commit to a timeline, confirm which Business Manager exports you can actually produce for that site, check how many product attributes and variation rules the catalog carries, and decide whether historical orders are migrated in full or only as read-only records. Those three answers set most of the effort for a small estate.
A multi-site, multi-currency estate changes the work from data conversion to structure. Each Salesforce site, its locale, its price books and its currency rules have to be mapped to Shopware sales channels, currencies, tax classes and customer groups before any data is loaded, because price books in Commerce Cloud do not map one to one onto Shopware price rules. Ask your team to list every price book, every site alias and every customer group in use, then agree which of them become separate channels and which become shared data. Shopware's plan structure also matters here: Shopware's pricing page states that plan pricing depends on gross merchandise value and other individual factors, so confirm the expected volume per site before you plan the hosting model.
A heavy custom cartridge base is the largest scope risk. Every cartridge hook, pipeline and custom controller has to be classified as one of three things: replaced by a standard Shopware feature, rebuilt as a Shopware plugin, or retired. Most of the rework sits in checkout, promotions and integrations with an order management or ERP system. A PWA Kit storefront changes the storefront rebuild in a different way. PWA Kit React components and Managed Runtime routing do not port into a Shopware Twig theme, so the team either rebuilds the storefront as a Shopware theme or moves to a Shopware headless setup that calls the Store API from a new frontend. That second route is a separate architecture decision, not a theme change, and it should be scoped and priced as one.
How DeployOpen scopes, runs and supports a Shopware migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and that includes a Shopware 6 store that replaces Salesforce Commerce Cloud. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.
How we scope
- Inventory the SFCC sites, price books, catalogs, customer groups and cartridge logic that the written scope must cover
- Confirm which Shopware edition, hosting model and plan question the store needs before build work begins
- Agree in writing which SFCC integrations (CRM, ERP, payments, order management) move, stay or retire during cutover
How we build
- Convert XML catalog, price book and customer exports into Shopware data structures, with test imports checked against source records
- Rebuild storefront behaviour as a Shopware theme or headless app, and document each cartridge feature that changes or is dropped
- Test checkout, promotions, tax and multi-currency flows in a staging environment inside your own infrastructure before cutover
How we hand over
- Deliver runbooks for deployment, backup, restore and the import scripts used during the migration
- Document data mappings, integration contracts and open items so your internal team can review and extend them
- Walk your team through the cutover plan, rollback steps and post-launch checks before the written handover is signed off
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after launch, scoped in writing
- Plan Shopware minor-line upgrades and regression tests so your storefront and integrations keep working through releases
- Ask for the support response terms and upgrade responsibilities in the written scope before you sign
