Which fits a B2C team weighing Commerce Cloud against Shopware
A B2C team weighing Salesforce Commerce Cloud against Shopware should start with three questions: what the renewal or licensing terms now cost, where customer data must physically sit, and who will run the platform after launch. Commerce Cloud fits organizations that want a fully managed, contract-priced platform where the vendor carries most hosting and operations work, and that have no strong pressure to change their storefront or data location. Shopware fits teams that want an MIT-licensed core they can run as SaaS, on managed PaaS or on their own servers, and that are ready to own more of the operations. Residency or licensing pressure is usually the trigger, and the factors below decide the outcome.
The first filter is gross merchandise value. 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. Below that line, the Community Edition includes a visual page builder, product management and Shopware Payments, but with community support only. Above it, Rise costs 600 euros per month with 8-hour support response, Evolve costs 2,400 euros per month with B2B quotes and approvals and 4-hour response, and Beyond is custom priced with 1-hour 24/7 support. If your B2B buyers need quote and approval workflows, the pricing page places them in Evolve, so confirm that requirement early. Shopware also says pricing reflects other individual factors, so request a written quote built on your own figures.
Which option fits which scenario
This table matches common buying situations to the Shopware option that fits best, and to the case where staying on Salesforce Commerce Cloud for now still makes sense. Read each row by its condition first, because the gross merchandise value threshold, hosting model and support tier decide most outcomes. Settle the plan and hosting model before approving migration budget, since the Community Edition is free only below the 1 million euro threshold.
| Buyer scenario | Better fit | Condition that drives it |
|---|---|---|
| Renewal with pricing pressure | Shopware Community Edition, if GMV stays under 1 million euros; otherwise compare Rise and Evolve | Gross merchandise value over the preceding 365 days; above 1 million euros a paid plan applies, and final pricing depends on other factors. |
| Strict data residency rule | Self-hosted Shopware in your own infrastructure | Data stays where you deploy it. Confirm in writing the data locations of any SaaS or managed PaaS option. |
| Small in-house team | Shopware Rise or Evolve on SaaS or PaaS | Vendor-run hosting, upgrades and patching reduce the operations load. Rise lists an 8-hour support response, Evolve a 4-hour response. |
| Heavy B2B quoting and approvals | Shopware Evolve | Evolve lists B2B quotes and approvals. Test your quote and approval workflow against the plan before committing. |
| Need for vendor-run uptime | Shopware Beyond, or a managed Shopware PaaS | Beyond lists 1-hour 24/7 support at custom pricing. Self-hosting moves uptime duties to your team, so compare contracted availability terms in writing. |
| Content teams building pages without developers | Shopware Community Edition visual page builder | Included in the Community Edition with community support only. Production incidents need a paid plan's response commitments. |
| Migration cannot be scheduled against the renewal | Stay on Salesforce Commerce Cloud for now | Choose this if the migration timeline does not fit your contract dates or if dependent integrations are not ready. Confirm the timeline with both vendors. |
How hosting models and licensing change the decision
In a SaaS model, Shopware operates the platform for you, and the merchant configures the store, themes and integrations within the boundaries the provider allows. Patching, backups and uptime sit with the vendor, which removes most of the infrastructure work from your team. The trade-off is that your room to change the core, host data in a region of your choice or run custom services next to the store depends on what the plan permits. This model matters most when the team has little platform engineering capacity and the business accepts the vendor's hosting terms.
- Operations: the provider handles patching of the platform and day-to-day availability.
- Backups: confirm the backup frequency, retention and restore process in the contract, since these are not part of the open-source licence.
- Customization: extensions and infrastructure choices are limited to what the plan supports.
- Data location: confirm where customer and order data is hosted and which sub-processors are involved.
- Plan link: the paid tier is priced on gross merchandise value and other factors, so confirm how the rate is set.
Before committing, ask the provider to put the uptime commitment, support response times and data residency terms in writing.",
Shopware also runs as PaaS on managed infrastructure, where the infrastructure is operated for you but you keep more control over the application than in SaaS. The split of responsibilities is negotiated, so the exact line between the provider and your team has to be documented before go-live. This model suits merchants who want their own extensions, custom deployment pipelines or specific environment settings without operating servers, databases and caching themselves. It matters most when the store needs custom integrations but the team does not want to run the underlying stack.
- Operations: the managed layer typically covers hosting and infrastructure availability, while application changes stay with your team.
- Backups: confirm whether the provider backs up databases and media, and how often you can restore.
- Customization: more freedom than SaaS, but still bounded by the platform's supported setup.
- Support path: ask which incidents are handled by the provider and which by your partner.
- Plan link: the plan tier, not the hosting model alone, determines support response times.
Ask for a responsibility matrix that lists each patch, backup and monitoring task with a named owner.",
Self-hosting means your team or an implementation partner runs Shopware in your own cloud accounts or data centres. Patching, backups, monitoring and uptime become internal responsibilities, and so does the cost of the people who carry them. The advantage is full control over data location, network design, security controls and upgrade timing, which matters when residency, audit or sovereignty rules apply. It only pays off when the organisation can staff platform operations for the life of the store. Shopware's two maintained minor lines, 6.7.15.1 and 6.6.10.29, were both released on October 7, 2026, so an upgrade plan must choose and track a line rather than wait for a single release.
- Operations: your team owns the servers, containers, database, search and cache layers.
- Patching: apply security and minor releases on the line you chose, with a tested rollback.
- Backups: define recovery point and recovery time objectives, then test restores on a schedule.
- Uptime: availability depends on your architecture, monitoring and on-call coverage.
- Cost drivers: infrastructure, staff and partner fees recur, while setup is largely one-time.
Ask any implementation partner to write down which environments, runbooks and restore tests are included in scope.",
Shopware is released under the MIT License, so the core code can be used, modified and self-hosted without a licence fee for the software itself. The free Community Edition has a threshold, however. Shops linked to an account that generate more than 1 million euros in gross merchandise value over the preceding 365 days must move to a paid plan. Shopware's pricing page lists Rise at 600 euros per month, Evolve at 2,400 euros per month and Beyond at custom pricing, and states that plan pricing also depends on gross merchandise value and other individual factors. The licence therefore removes software fees below the threshold, while hosting, staff and support costs apply at any size.
- MIT core: the code licence is permissive, but it does not cover your hosting, staff or partner work.
- Threshold: above 1 million euros in gross merchandise value over 365 days, a paid plan is required.
- Plan features: Evolve adds B2B quotes and approvals with a 4-hour response, and Beyond adds 1-hour 24/7 support.
- Community support: the Community Edition is supported by the community only, so plan internal or partner coverage.
- Compare: set the paid plan price against the total cost of self-hosting, not the licence line alone.
Confirm current plan terms directly with Shopware before modelling the budget, because the pricing page is the source of record.
What data location and compliance mean for each hosting choice
Where data sits, who holds the keys and logs, and who can attest to controls decide how a Shopware move changes your compliance position. Each choice below moves some of that work between Salesforce, Shopware, your cloud provider and your own team. DeployOpen prepares systems and evidence but does not issue audit reports or certifications; independent auditors and certification bodies do.
Data location and hosting model
Shopware can run as SaaS, as PaaS on managed infrastructure or self-hosted. Each model puts customer, order and payment data in a different place. Under self-hosting, you choose the region, the cloud account and the data center, so residency is decided by your architecture. Under SaaS or PaaS, ask Shopware and Salesforce for the exact regions where production, backups and logs are stored, and whether support staff can access them from outside those regions.
Encryption key ownership
Ask who generates, stores and rotates the keys for database encryption, backups and object storage. Self-hosting lets you hold keys in your own key management service or hardware security module. With a vendor-managed SaaS or PaaS, confirm whether customer-managed keys are offered, what they cost, and what happens to data if the key is revoked. Document the answer before the migration, because it shapes your data processing agreements.
Access logs and log retention
Web server, application, admin and database logs record who touched customer records and payment flows. In a self-hosted Shopware stack, you decide where these logs go, how long they are kept and who can read them. On a managed platform, ask which logs the vendor keeps, for how long, and how you export them to your SIEM. Confirm that logs needed for incident investigation are available without a support ticket.
Audit evidence ownership
Assessors ask for evidence such as change records, access reviews, backup restore tests and vulnerability scan results. Under self-hosting, most of this evidence sits with your team and your tooling. Under a managed platform, some evidence sits with the vendor's reports, which may not map to your control set. Agree in writing which party produces each artifact and where it is stored before the cutover.
Identity integration and admin access
Single sign-on and multi-factor authentication for Business Manager style admin roles, Shopware administration users and support access determine who can change prices, export customers or alter checkout. Confirm which identity provider each platform supports, how roles map to your groups, and whether vendor support staff can act inside your store. Record each privileged account and its review cycle.
Third-party auditor and certification role
Neither platform's license nor a hosting plan makes your store compliant on its own. DeployOpen can plan, configure and document the controls, and prepare evidence for assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask Salesforce and Shopware which current reports they can share under your NDA, and which of your controls they cannot cover.
What a move from Commerce Cloud to Shopware involves
A move from Commerce Cloud to Shopware starts with a complete inventory of what leaves the platform: catalog, customers, orders, promotions, content assets and the site configuration that ties them together. Commerce Cloud exports are typically XML built on Salesforce's own schemas, so the first task is to decide which of those files your Shopware import will consume, which will be transformed by a script, and which will be retired. Confirm early which exports your Business Manager roles can run, how large the files are, and whether product images and media are exported separately. Keep the original storefront live until a test import of catalog, prices and customers has been reconciled against source counts. Ask the implementation partner to write down the mapping for every entity in advance, since missing fields found late are the most common source of rework.
Price books and sites need the most design work. In Commerce Cloud, a price book can be assigned to several sites and currencies, and each site can carry its own locale and catalog. Shopware organizes pricing around products, price rules, currencies, languages and sales channels, so each Commerce Cloud site has to be translated into a sales channel decision: one channel per storefront, with its own currency, tax and customer group settings. Decide which price books become customer groups, which become rules, and how promotions and coupon codes map to Shopware's promotion model. Customer exports need the same care. Check how passwords and address books are handled, because most platforms will not import password hashes, and plan a reset or account-linking flow for shoppers.
Storefront logic and integrations carry the rest of the effort. SFRA or PWA Kit behavior does not transfer directly, so decide early whether storefront work becomes a Shopware theme with its own twig templates and plugins, or a headless storefront that calls the Store API. That choice shapes who maintains the front end for years. On the back end, list every system that receives orders or customer data from Commerce Cloud today, including the CRM, the order management system, the payment provider and the tax and shipping services. Each connection needs a named owner, a replacement and a test plan that covers order status updates and refunds. Refer to the Migrate from Salesforce Commerce Cloud to Shopware guide only as a companion for step-by-step import detail, and confirm current Shopware licensing and plan terms with Shopware before you commit to a deployment model.
What drives the total cost on each side
What is the main cost driver on the Salesforce Commerce Cloud side?
The main driver is the Commerce Cloud contract, which is negotiated with Salesforce and typically covers platform access, usage tiers and the add-on services the business has bought. Confirm with your account team exactly which components the contract bundles, how usage is measured, and when the term renews. Commerce Cloud does not publish a list price that can be compared directly, so the reader should build the comparison from their own contract. Once the contract ends, the costs move to infrastructure, build work and internal staff, which are paid by the organization itself.
How does Shopware plan pricing depend on gross merchandise value?
Shopware plan pricing is based on gross merchandise value and further individual factors, according to its pricing page, and shops linked to an account above 1 million euros in gross merchandise value over the preceding 365 days need a paid plan instead of the free Community Edition. The listed plan prices are Rise at 600 euros per month, Evolve at 2,400 euros per month and Beyond at custom pricing. These plan fees recur monthly, so the annual figure depends on the plan and on any individual factors Shopware applies. Ask for the written terms that explain how the gross merchandise value is measured for the shop and what changes at renewal.
Which Shopware plan includes B2B quotes and approvals?
According to the Shopware pricing page, the Evolve plan lists B2B quotes and approvals and a 4-hour response time, at 2,400 euros per month. The Rise plan lists AI-assisted content and an 8-hour response time, at 600 euros per month. Beyond is custom priced and lists 1-hour 24/7 support. If B2B quoting is a requirement, the plan choice directly changes the recurring fee, so the reader should map the required workflows against the plan feature list before estimating the annual cost.
What hosting and infrastructure costs come with self-hosting Shopware?
Self-hosting moves hosting from a vendor fee into the organization's own cloud or data center budget. Shopware can run as SaaS, as PaaS on managed infrastructure or self-hosted, so the choice between these models changes who pays for servers, storage, databases, caching, backups, monitoring and staff time for patching. Recurring costs include compute, managed database and storage, content delivery, search and log retention. The biggest variable is peak traffic and how many environments the team keeps for staging and testing. Ask the hosting partner or cloud provider for a written breakdown tied to the expected traffic and environments.
What build and migration work is one-time and what can be reused?
Build and migration work is mostly one-time: exporting catalogs, customers and orders, mapping them to Shopware's data model, rebuilding storefront logic as a Shopware theme or headless app, and replacing Commerce Cloud cartridge behavior with plugins or custom code. Costs rise with the number of sites, locales, price books, custom checkout rules and integrations. Some work repeats, such as test cycles before each cutover. The reader should ask any implementation partner for a fixed scope listing each site, integration and data set, with deliverables and acceptance criteria agreed in writing before work starts.
What integration and support costs recur after launch?
Integration costs cover connections to the ERP, order management, payment providers, tax, shipping, CRM and marketing tools. These are mostly one-time to build, then recur as maintenance when those systems change. On the Shopware side, support level is tied to the plan, with response times of 8 hours on Rise, 4 hours on Evolve and 1 hour 24/7 on Beyond, according to the Shopware pricing page. The Community Edition offers community support only. Ask whether the support tier covers incidents in your integrations or only the platform, and whether an external partner or retainer is needed for after-hours coverage.
How much in-house staff does each side require?
On the Commerce Cloud side, the organization usually relies on Salesforce for platform operation and on its own or partner teams for storefront and business configuration. On the Shopware side, the organization takes on platform operations, upgrades, security patching, performance work and developer capacity for themes and plugins. Staffing is a recurring cost and is often the largest line once hosting is in place. Estimate roles by function, such as platform engineering, storefront development, operations and merchandising, and confirm with a partner which roles can be covered under a retainer rather than full-time hires.
What should a written quote for a Shopware move include?
A useful quote lists the scope in writing: sites, locales, catalogs, price books, customer and order data volumes, integrations, and the storefront approach. It should separate one-time work (discovery, migration, build, testing, cutover) from recurring work (hosting, support, upgrades, monitoring and backups). Ask for the assumptions behind each line, the acceptance criteria, the change-request process and the handling of any Shopware plan fees or licenses that are not included. Also request the Commerce Cloud exit items, such as data export support and a timeline for contract termination, so the comparison covers both sides.
How a Commerce Cloud to Shopware move is sequenced
The sequence moves a Salesforce Commerce Cloud store to Shopware in stages, so scope, data and storefront behavior are confirmed before customers see the new store. Each step closes with a written check that the client can review.
Agree the scope in writing
Before any build starts, the client and DeployOpen agree in writing which sites, locales, currencies, price books, catalogs, customer segments, promotions, payment methods and integrations are in scope. The client confirms which Shopware edition and plan will host the store, since Community Edition is limited by gross merchandise value and a paid plan is required above 1 million euros over the preceding 365 days. The step closes with a signed scope document listing deliverables, acceptance criteria and the client's named owners for data, storefront and integrations.
Export and map the commerce data
DeployOpen works with the client's Business Manager administrators to export catalogs, price books, customers, orders, promotions and coupon data, and maps each Salesforce structure to its Shopware equivalent, including products, variants, properties, tax rules, customer groups and sales channels. The client provides administrator access, a list of custom attributes and any data retention or personal data restrictions that apply to exports. The step closes with a field-level mapping document that the client approves and a test import of a representative sample.
Import and validate in a staging shop
The mapped data is loaded into a staging Shopware instance running in the client's own environment, and DeployOpen checks record counts, price calculations, tax output, customer logins and order history against the Salesforce source. The client's merchandising and finance teams sign off on sample products, prices and reports. The step closes with a reconciliation report listing every discrepancy and its resolution, with no open items in the pricing and customer data before the next stage.
Rebuild the storefront and checkout logic
DeployOpen rebuilds the storefront as a Shopware theme or headless front end, using the visual page builder in the Community Edition or the paid plan features the client selected, and reimplements cartridge behavior such as search rules, promotions, shipping methods and checkout steps. The client supplies brand assets, content, legal copy and approval for each page template. The step closes when the client has reviewed the storefront on desktop and mobile in staging and accepted each template and checkout journey against the agreed scope.
Run the original store in parallel
The Salesforce store stays live while Shopware runs in parallel, and both are compared on the same catalog and pricing changes for an agreed period. DeployOpen tracks orders, inventory updates and customer records that differ between the two platforms, and the client decides when data has been verified. Shopify's guidance for its own export path is a useful reference point here: keep the original store live until the new store has imported what it needs. The step closes with a written verification report that the client approves as the basis for cutover.
Test integrations and payments
DeployOpen tests the connections to the ERP, CRM, order management, payment providers, tax calculation, shipping carriers and marketing tools that the Salesforce store uses, including webhooks, API authentication and error handling. The client provides test credentials, vendor contacts and sandbox access for each system. The step closes with a test log covering each integration path, including failed payment, refund and order cancellation cases, and a list of any gaps the client accepts or fixes before cutover.
Cut over to Shopware
The client chooses a cutover window, DeployOpen makes a final data delta sync, updates DNS and redirects, and confirms the storefront, checkout and back office are working on the production Shopware instance. The client's support team monitors orders and customer contacts during the first period after launch. The step closes when the agreed go-live checklist is signed and the production store is confirmed to take live orders with the expected payment, tax and shipping behavior.
Decommission the Salesforce store
After the client confirms that the new store has operated correctly, DeployOpen and the client agree how long Salesforce data and exports are retained, remove or disable integrations that point to the old store, and archive records as required by the client's policies. The client confirms its contract end date and any data return or deletion obligations with Salesforce. The step closes with a decommissioning record listing archived datasets, revoked credentials and the confirmed end of live use.
Questions buyers ask before choosing Shopware or Commerce Cloud
Is Shopware Community Edition enough below the 1 million euro threshold?
For many shops below the threshold, the Community Edition is the starting point to evaluate, because Shopware's pricing page says shops above 1 million euros in gross merchandise value over the preceding 365 days need a paid plan instead. The Community Edition includes a visual page builder, product management and Shopware Payments, but support is community only. Check whether your store, including any linked accounts, stays under the threshold over a rolling 365-day period, and confirm with Shopware how that threshold is measured for your setup. Also weigh the cost of your own support staff against a paid plan's response times, since community support carries no contractual response commitment.
What drives the cost of moving from Commerce Cloud to Shopware?
The main cost drivers are the size and complexity of the catalog, the number of sites, markets and currencies, how much cartridge logic must be rebuilt as Shopware themes, apps or headless components, and the integrations with your ERP, order management and CRM. Costs fall into one-time items (data mapping, build, testing and cutover) and recurring items (hosting, Shopware plan fees if applicable, extensions, and support). Shopware states that plan pricing depends on gross merchandise value and other individual factors, so ask Shopware for a quote based on your own figures. When requesting outside help, ask for a fixed-scope written proposal that lists each deliverable, the integrations included and the testing approach.
How long does a migration from Salesforce Commerce Cloud usually take?
Duration depends on the scope rather than on a fixed template, so no general timeline is safe to assume. The biggest variables are how many storefronts and locales you run, how far your SFRA or PWA Kit logic has been customized, how clean your exported customer and order data is, and how many systems must be reconnected before go-live. Plan for a parallel run in which the existing store stays live until the new one is verified. Ask any provider for a schedule tied to named milestones, and ask your Shopware partner which phases they have timed on comparable scopes, in writing.
Can an internal team migrate to Shopware without outside help?
An internal team can handle a migration if it has engineers who know Shopware's architecture, theme and plugin development, PHP and the hosting stack, and if it has the capacity to run data mapping, testing and cutover alongside daily operations. Common gaps are payment and tax configuration, search and performance tuning, and B2B approval flows, which need careful testing. Teams that lack this experience often bring in outside help for part of the work, such as the platform build or security hardening, while keeping ownership of the catalog and business rules. Assess your team's skills honestly against the scope before deciding.
What do Shopware support response times mean in practice?
Shopware's pricing page lists an 8-hour response on Rise, a 4-hour response on Evolve and a 1-hour response on a 24/7 basis on Beyond, with custom pricing. A response time is the window in which the vendor acknowledges a request, not the time to a fix, so it does not guarantee resolution. Check what counts as a priority incident, which channels are covered, and whether support includes hosting issues or only platform questions. Compare these terms with your own uptime and incident needs, and confirm the exact contractual wording with Shopware before you rely on it.
Should we choose self-hosted Shopware or the managed PaaS option?
Shopware can run as SaaS, as PaaS on managed infrastructure, or self-hosted, so the choice is mainly about who operates the platform. Self-hosting gives you control over data location, network design and upgrade timing, but your team or a partner must own patching, backups, monitoring, scaling and incident response. Managed options shift part of that operational load to the vendor, under the terms you agree. Decide based on your data residency rules, in-house operations skills and the staffing you can sustain, and confirm which responsibilities each option assigns to you.
What does the migration need from our team?
The migration needs named business owners who can approve catalog rules, pricing, tax, promotions and customer data handling, plus technical contacts for your existing Commerce Cloud estate, ERP, payment provider and CRM. Provide access to current exports, site and price book documentation, integration specifications and a test environment. Expect the team to make decisions on which features move, which are retired and which change. Ask any provider to list these inputs in the written scope so you can confirm your resources before work starts.
Does Shopware's MIT license mean we can avoid all fees?
The MIT License covers the Shopware source code and permits use, modification and redistribution, but it does not remove other costs. Your total spend still includes hosting or infrastructure, development, third-party extensions, payment fees, and any paid Shopware plan that applies to your gross merchandise value. Read the license file and your plan terms together, and confirm with Shopware which of your costs are subscription fees and which are open-source components you operate yourself.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Salesforce Commerce Cloud to Shopware, we start with a written scope that separates the Community Edition path from a paid plan decision, then build and document the result in your environment.
How we scope
- Confirm whether your shops exceed the 1 million euro gross merchandise value threshold that requires a paid Shopware plan.
- Map Commerce Cloud sites, price books and storefront features to Shopware 6 components, marking gaps such as B2B quotes and approvals.
- Agree hosting model options (SaaS, managed PaaS or self-hosted) and the owner of each operational task in writing before work starts.
How we build
- Build Shopware in your own infrastructure, including the storefront theme or headless integration your team has chosen.
- Rebuild cartridge logic, checkout rules and CRM or order integrations as Shopware extensions or services, tested against your data.
- Test catalog, customer and order imports against exports from your live Commerce Cloud estate before any cutover is scheduled.
How we hand over
- Deliver architecture notes, configuration records, runbooks and a list of open decisions for your team to review.
- Document how product, customer and order data moved, including fields that did not map and the manual steps that remain.
- Walk your platform, security and commerce staff through operations, upgrades and backup procedures before sign-off.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Agree in writing who handles Shopware security updates, patch windows and incident response, and how that differs from vendor support tiers.
- Ask for a quote that itemizes scope, deliverables and retainer terms, since DeployOpen prices follow from the written scope.
