BigCommerce vs Shopware: when each fits and what the decision turns on
A hosted BigCommerce store fits a merchant with no platform team that wants the vendor to run hosting, security patches and upgrades. Shopware 6 fits a merchant that must self-host, wants code under the MIT License and needs control over the codebase it depends on. A renewal or hosting requirement should be judged by who will operate the store over the coming years, because a hosted store shifts operational work such as database backups, patch cycles and overnight incidents to the vendor, while a self-hosted Shopware store keeps that work with your own team or partner.
Shopware 6 fits when the codebase itself is a strategic asset. The MIT License lets you read, fork and modify the source, and the Community Edition already includes a visual page builder, product management and Shopware Payments, although the Community Edition offers community support only. Shopware can run as SaaS, as PaaS on managed infrastructure or self-hosted, so the hosting model is a separate choice from the license. Ask Shopware in writing which responsibilities sit with Shopware and which sit with you under each hosting model, and compare that list with the team you actually have.
Three factors should decide it. First, expected gross merchandise value: the Community Edition is free only for shops linked to an account that generate 1 million euros or less in GMV over the preceding 365 days, and Rise is listed at 600 euros per month on the Shopware pricing page. Shopware states that plan pricing also depends on other individual factors, so request a quote against your GMV forecast. Second, B2B needs: Evolve lists B2B quotes and approvals, so confirm whether your approval workflows require that tier. Third, in-house engineering capacity: count the people who will maintain the store, and treat that cost as one you cannot skip.
Which platform fits which scenario
This table matches common buyer situations to the platform that tends to fit them better, with the reason tied to the researched facts. Read each row as a starting point, then check the named conditions against your own volumes, team and hosting rules before deciding.
| Scenario | Better fit | Reason |
|---|---|---|
| Small merchant with no in-house developers | BigCommerce | BigCommerce is a hosted SaaS store, so the merchant does not run servers, upgrades or patches. Shopware self-hosting or managed PaaS adds operational work that a small team may not carry. |
| Shop well below 1 million euros in yearly GMV with a developer or agency | Shopware 6 (Community Edition) | The Community Edition is MIT-licensed and free to use below the 1 million euro GMV threshold, and it includes a visual page builder and product management. Hosting and support costs remain with the merchant. |
| Shop growing toward 1 million euros in yearly GMV | Plan a move to a paid tier before crossing the threshold | Shops generating more than 1 million euros in GMV over 365 days need a paid plan. Model the Rise plan and its pricing basis against your projected GMV, and confirm the terms with Shopware before the threshold is reached. |
| B2B seller needing quotes and approvals | Shopware Evolve or BigCommerce, after a feature check | Shopware lists B2B quotes and approvals on its Evolve plan at 2,400 euros per month, which may fit larger B2B needs. Confirm that your specific B2B workflows, pricing rules and integrations are supported before choosing. |
| Team that must keep customer and order data on its own servers | Shopware 6 (self-hosted) | Shopware can run self-hosted, so data stays in infrastructure you control. BigCommerce is a hosted SaaS platform, so data residency depends on its hosting terms. |
| Merchant with a complex page builder or custom storefront needs | Shopware 6, if the team can build and maintain themes | The Community Edition includes a visual page builder, which helps non-developers edit pages. Complex custom storefronts still need development work, so compare the theme effort on both sides. |
| Merchant that wants predictable hosting and uptime responsibility handled by the vendor | BigCommerce | Hosted SaaS shifts infrastructure duties to the vendor. Ask BigCommerce for its uptime commitment in writing, since this comparison does not include one. |
| Team that needs community-only support at low risk tolerance | Shopware Rise or higher | Community Edition support is community-based only. Paid tiers list faster response times, with Rise at 8-hour response and Evolve at 4-hour response, according to Shopware's pricing page. |
How the Community Edition threshold changes the math
The free Community Edition sets the first budget boundary. 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. The test is a trailing window, so a store can cross the line in the middle of a financial year and need a paid plan from that point. Monitor the figure monthly as a rolling total and add the check to your finance calendar. Confirm with Shopware which accounts count as linked to your shop, because several storefronts, sales channels or sister brands may share one account and therefore one combined total.
Start with your own numbers. Export order data from BigCommerce for the last 365 days and sum the gross order value in the currency you report in. Your total may differ from Shopware's figure, because definitions of gross merchandise value can vary on taxes, shipping, refunds and cancelled orders. Ask Shopware in writing which definition applies to your account. The pricing page also states that plan pricing is based on gross merchandise value and further individual factors, so a store below the threshold can still receive a plan quote, and a store above it should request a written quote rather than assume the list prices apply to its case.
Put the numbers side by side. The Community Edition carries no license fee, but it includes community support only, so the budget for a store under the threshold is hosting, implementation, your own support arrangement and any extensions you buy. Above the threshold, the pricing page lists Rise at 600 euros per month with 8-hour support response, Evolve at 2,400 euros per month with B2B quotes and approvals and 4-hour response, and Beyond at custom pricing with 1-hour 24/7 support. A store approaching 1 million euros should model the plan it would move to, the support level it needs and the cost of a mid-year switch while there is still time to plan it.
Hosting choices: SaaS, managed PaaS or self-hosted Shopware
BigCommerce runs the store as a hosted SaaS service. The merchant subscribes to a plan, configures the storefront, catalog and apps through the admin, and calls the platform through its APIs. The merchant does not provision servers, databases or content delivery for the store. What stays with the merchant is the business configuration: what is sold, which apps are installed, who holds admin access, how API credentials are managed and how customer data is used in marketing and fulfillment.
- Infrastructure: BigCommerce provisions and operates the servers, databases and delivery network behind the store.
- Patching: The vendor applies platform updates to the core software on its own schedule.
- Backups: Your team does not run backup jobs for the hosted store, so ask BigCommerce what recovery coverage applies to your plan and how you would export your own copy of the data.
- Monitoring: Platform health sits with the vendor, while your team still monitors integrations, third-party apps and the storefront from the customer's side.
- Your responsibilities: App permission reviews, API credential rotation and the security of any custom code that calls the Catalog API.
Before you leave this model, check the availability commitments, support tiers and data export rights in your current agreement, and list which of these duties your team currently performs.
Shopware offers SaaS as one of its three hosting models, alongside managed PaaS and self-hosting, according to its pricing page. In the SaaS model, the vendor operates the hosted shop, so the merchant's operational work is closest to the BigCommerce model. The merchant configures the shop, manages its own users and roles, and chooses the extensions and integrations it needs. Shopware's pricing is tied to gross merchandise value and other individual factors, so hosting terms and plan limits should be read together with the plan itself.
- Infrastructure: Shopware operates the hosted environment for SaaS customers, and your team does not manage servers or database capacity.
- Patching: Confirm with Shopware how platform releases are scheduled for your shop, and whether you can test a release before it reaches production.
- Backups: Ask Shopware for the backup frequency, retention period and restore process that apply to your plan, and whether you can request a full export.
- Monitoring: Ask what uptime monitoring and incident notifications the vendor provides, and how you receive them.
- Your responsibilities: Extension reviews, storefront changes, user access management and the security of custom integrations.
Ask for the SaaS service description in writing, including how environments are separated, so you know exactly which duties transfer to Shopware and which remain in your team.
Shopware also supports PaaS on managed infrastructure, which sits between SaaS and self-hosting. A managed provider runs the infrastructure layers, while the merchant keeps control of the shop's code, themes, plugins and deployment pipeline. This model suits teams that want to maintain their own customizations but do not want to staff the hosting environment directly. The division of duties depends on the provider contract, so each duty below should be confirmed in writing rather than assumed from the model name.
- Infrastructure: The managed provider typically runs the servers, database services and network layer. Confirm exactly which components are included.
- Patching: Find out whether the provider patches the operating system and runtime, and whether your team applies Shopware platform updates and plugin updates.
- Backups: Ask who takes backups, how often, where copies are stored and how a restore is tested.
- Monitoring: Clarify whether the provider monitors availability and capacity, and whether your team receives alerts for application errors.
- Your responsibilities: Custom code, theme changes, plugin selection, deployment pipelines and the security of third-party integrations.
Request a responsibility matrix from each provider that lists every duty in this tab, with an owner named for each one.
Shopware is released under the MIT License, so the team can run the software on infrastructure it controls, including its own cloud accounts, data center or private network. This model gives the most control over the hosting stack and the upgrade schedule. It also places every operational duty with the owner of the environment, including capacity planning, security hardening, backups and incident response. Partners can help with the build and run, but the duties and their costs still need to be assigned in the statement of work.
- Infrastructure: Your team or a delivery partner provisions the application servers, database, cache and storage, sized for expected traffic and peak sales periods.
- Patching: You apply Shopware releases and plugin updates. Shopware currently maintains two minor lines, 6.7 and 6.6, so plan which line you run and when you move to the next one.
- Backups: You design the backup schedule, retention, off-site copies and restore tests for both the database and the media files.
- Monitoring: You collect logs and metrics, set alerts for errors, slow checkout requests and failed jobs, and define who responds.
- Your responsibilities: Hardening, access control, certificate management, vulnerability response and upgrade testing.
Read the license file in the official repository to confirm the terms that apply to your use, and budget for the operating staff or partner support that this model requires.
Hosting choice also determines where customer, order and payment-related data physically sits, and who can reach it. In the BigCommerce model and the SaaS and managed PaaS options for Shopware, the vendor or provider chooses or confirms the hosting regions, so your team needs written answers about where data, backups and logs are stored. In the self-hosted model, you choose the location. None of these choices, on its own, establishes compliance with a regulation or standard. They are inputs that your assessor or legal team will review alongside your contracts and controls.
- Data location: Ask each vendor or provider which regions host the shop database, media files, backups, logs and support access.
- Admin identity: Decide whether administrators sign in through single sign-on, whether multi-factor authentication is required, and how accounts are removed when staff leave.
- Service identities: List the API keys, integration accounts and service tokens used by apps and custom code, along with their owners and rotation schedule.
- Support access: Find out when vendor or provider staff can access your environment, how that access is logged and whether you can approve it.
- Exit rights: Confirm how you would receive a full copy of your data and in what format.
Keep a record of each answer, because the same questions will come up again in procurement reviews and security assessments.
Where your customer and order data lives
Moving from BigCommerce to a self-hosted Shopware store changes who holds customer and order records, who backs them up and who answers for them during an assessment. The six areas below are the decisions to settle before cutover, and each one depends on your own hosting, identity and compliance setup.
Data location and residency
With BigCommerce, the platform hosts the store database and media. With self-hosted Shopware, you choose the cloud account, region or data center that holds orders, customer profiles and addresses. Confirm which jurisdictions the database, object storage, search index, logs and any staging copies will sit in, including copies that developers make during the rebuild.
Backups and restore testing
BigCommerce handles platform-level backup for the hosted store, so you should not assume that duty transfers cleanly. A self-hosted Shopware store needs scheduled database and file backups, retention rules and a tested restore for orders and customer records. Ask who owns recovery objectives, where backup copies live, and how often a restore is rehearsed.
Admin access and identity
Store administrators, developers, support staff and agencies each need a defined level of access in the Shopware admin and the hosting console. Decide how these accounts are created, how multi-factor authentication is enforced, how contractor access is removed, and how admin actions are logged. Map these roles against the access model you use today in BigCommerce.
Payment card data scope
Whether card data touches your servers depends on the payment integration you choose, not on the Shopware license. Hosted payment fields or a tokenizing provider can keep card numbers out of your environment, while custom checkout code can bring it in. Confirm the payment flow with your acquirer and assessor before you pick the Shopware Payments route or a third-party gateway.
Security patching ownership
Shopware releases are published on a regular cadence across maintained minor lines, and every plugin, theme and PHP runtime beneath the store also needs updates. Assign named owners for core upgrades, extension updates and server patches, and define how quickly critical fixes are applied. Ask your implementation partner which support line and patch process will cover the store after go-live.
Compliance evidence and assessor scope
DeployOpen can prepare controls, configuration records, access reviews and evidence packs for your compliance program. Independent auditors and certification bodies issue any attestation or report, and they decide whether the evidence is sufficient. Agree early with your assessor which systems, logs and change records they will sample, so the store is built to produce them.
Page builder and B2B features in practice
The first decision is which storefront and B2B needs the Shopware Community Edition covers at no license cost and which need a paid plan. The Community Edition includes a visual page builder, product management and Shopware Payments, but only community support comes with it. Test the page builder against your real landing pages, category layouts and content blocks before assuming the free build is enough. Where the B2B quotes and approvals that BigCommerce merchants often rely on are concerned, Shopware's pricing page places them in the Evolve plan, listed at 2,400 euros per month with a 4-hour support response. Shopware also states that plan pricing depends on gross merchandise value and other factors, so treat the list figure as a starting point and ask for a written quote based on your volumes. The Shopware pricing page is the reference for current plan contents.
BigCommerce changes its B2B and storefront features over time, so verify them against the current product documentation and a trial account rather than against an older migration plan. Build an inventory of what your store uses: customer groups, price lists, company accounts and user roles, quote and approval workflows, and any storefront features that come from the theme or from an installed app. For each item, record whether it is native to BigCommerce, delivered by a third-party app or built by your team. Native features need a Shopware equivalent that you configure or build, and app-based features need a Shopware plugin or custom development. The Catalog API covers bulk pricing rules, custom fields and metafields, which gives you a route to export that pricing data, but the B2B logic that reads it must be rebuilt on the Shopware side.
Before you commit to a rebuild, confirm what you own in the theme and checkout. Find out whether your current theme is a licensed or purchased asset with restrictions on reuse, which parts are custom code, and which are edits to a base theme that will need to be ported. For checkout, list every customization, including payment methods, shipping rules, tax handling, custom fields and any scripts or third-party widgets, and check which of them Shopware provides natively and which need a plugin or development work. Shopware currently maintains two minor lines, 6.6 and 6.7, so confirm which line your plugins and custom code target and who will apply patches and upgrades after go-live. A written scope with these items listed will make any quote for the rebuild comparable across vendors.
What running Shopware costs compared with a BigCommerce subscription
A BigCommerce subscription bundles hosting, platform upkeep and most of the runtime into one recurring fee. Running Shopware moves those costs onto your own budget, split between plan fees, infrastructure, build work and staff time. The cards below list each component, whether it is one-time or recurring, and what drives it up or down.
Shopware plan fees
The Community Edition is free to use below the revenue threshold, while shops above it need a paid plan. The Shopware pricing page 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 custom priced with 1-hour 24/7 support. Plan pricing depends on gross merchandise value and other individual factors, so ask for the exact tier in writing before comparing it with your BigCommerce plan.
Hosting and PaaS choices
Shopware runs as SaaS, as PaaS on managed infrastructure or self-hosted. Self-hosting turns the server, database, caching and backups into your recurring costs, whether you pay a cloud provider or a data center. A managed PaaS option moves some of that operating work to the vendor at a different fee. Ask what each option includes for uptime targets, backups and patching, and whether the hosting fee is quoted separately from the plan.
Storefront build and theme work
Replacing BigCommerce themes and Stencil or Catalyst storefront code is usually a one-time project cost. It depends on how many templates, checkout steps and custom components you rebuild in Shopware's storefront. Shops with a simple catalog and standard checkout cost less to rebuild than shops with bespoke B2B ordering flows. Ask for the build scope in writing, including the templates covered and the testing included.
Plugins, payments and search services
BigCommerce apps are subscriptions that often bill monthly, while Shopware plugins may be one-time licenses or recurring fees, depending on the vendor. Payment and search services also carry their own fees, and the Shopware Community Edition includes Shopware Payments with community support only. Map each BigCommerce app you use to a Shopware plugin, then record its price model, renewal date and support terms.
Upgrades, support and staff time
Self-hosting means your team or partner applies Shopware minor and patch releases, tests extensions after each update and watches security advisories. Shopware currently maintains two minor lines, so you must choose which line to follow and when to move. Paid plans add vendor support response times, while the Community Edition relies on community support. Budget for recurring engineering time and a retainer if you do not keep that capacity in house.
Compliance and security responsibility
On BigCommerce, the provider runs the platform infrastructure, while on self-hosted Shopware your organization owns server hardening, access control, backups and card data scope if you handle payments outside a hosted gateway. These tasks are recurring costs and should appear in the quote. Confirm with your payment provider and assessor which parts of your environment fall in scope before you set a budget.
What a move from BigCommerce to Shopware involves
The sequence turns a BigCommerce store into a Shopware 6 shop with its catalog, customers, redirects and checkout verified before the old store is switched off. Each phase produces a signed-off artifact that the next phase depends on.
Inventory apps, integrations and checkout logic
Before any data moves, list every installed BigCommerce app, custom script, webhook, ERP or payment connection, tax rule, shipping rule and checkout customization. Record which business function each one serves and whether Shopware offers an equivalent plugin, a standard feature or needs custom development. The business owner and the developer sign the inventory, and the output is a gap list that shows which items are covered, which need a plugin, and which need custom work. Confirm plugin availability and licensing directly with Shopware and the plugin publishers, since the marketplace changes.
Export catalog, customers and orders
Export products, categories, customers and orders using the built-in CSV templates for smaller catalogs, or use the BigCommerce Catalog API for programmatic extraction of products, variants, images, custom fields and metafields. Store the raw exports in a versioned location that is separate from the live store. The check is a row-count and sample-record reconciliation against the BigCommerce admin, with any mismatches logged. Keep the source store live until images have been fetched and verified, because product images are not carried in standard CSV exports on other platforms, so you must download them from their source URLs.
Map data to Shopware products, properties and customers
Map BigCommerce product fields, variant options, custom fields and bulk pricing rules to Shopware products, property groups, options, price rules and customer groups. Decide how customer passwords are handled, since password hashes usually cannot be moved between platforms, and plan a password reset or account activation flow. A data engineer and a merchandiser sign off on a mapping document that lists every source field and its target. The output is a tested import file for a staging Shopware instance.
Import into a staging Shopware instance
Load the mapped catalog and customers into a Shopware 6 staging environment on the hosting model you have chosen, whether SaaS, PaaS or self-hosted. Check category trees, variant combinations, prices per customer group, stock levels, images and tax settings against the source. Record every import error and rerun until the error log is clean for the in-scope data. The check is a documented reconciliation report signed by the merchandising and finance owners.
Rebuild the theme and page builder layouts
Recreate the storefront design in the Shopware theme system and rebuild key landing pages, category layouts and product templates with the Community Edition's visual page builder or the paid plan tooling you select. Rebuild the checkout flow, account pages and any B2B ordering screens on the same footing as the source store. The output is a staging storefront that the design owner has approved on desktop and mobile, with accessibility and performance checks recorded in the test plan.
Build redirects and SEO continuity
Create a URL map from every indexed BigCommerce product, category, brand and content page to its new Shopware URL, then implement the redirects in the new store and verify them with a crawl of the old site. Carry over page titles, meta descriptions, canonical tags, structured data and XML sitemaps where they still apply. The check is a crawl report showing that old URLs return permanent redirects to live pages with no broken chains, reviewed by whoever owns organic search.
Test payments, tax, orders and integrations
Run end-to-end test orders through each payment method on the new store, including refunds and failed payments, and verify tax calculation, shipping rules, order notifications, ERP and fulfillment connections, and reporting. Confirm which payment provider integration applies in your country and whether Shopware Payments is an option for your merchant setup. Security and privacy owners review the PCI DSS scope of the chosen payment path, and the output is a signed test log with every failed case resolved or accepted.
Cut over and run in parallel
Choose a cutover window, freeze catalog edits, run a final incremental export and import, switch DNS or the storefront routing to Shopware, and keep the BigCommerce store running for a parallel period agreed in advance. Monitor orders, errors, search console data and customer support contacts during that period, and reconcile orders placed in both systems. The sequence is complete when the parallel run closes with no unreconciled orders and the BigCommerce subscription is scheduled for cancellation, with the agreed data retention copy archived.
Questions buyers ask before switching
How much effort does a switch from BigCommerce to Shopware take?
The effort depends mostly on how much of your store relies on BigCommerce apps, custom code and a bespoke storefront theme. A plain catalog with a standard theme and few integrations is far less work than a store with B2B pricing rules, custom checkout logic and many third-party connectors. Each of those areas needs a plan for export, import, rebuilding the functionality as Shopware plugins or custom code, and testing. Ask any partner to break the effort into catalog extraction, app replacement, theme rebuild, data import, SEO redirects and testing, each with its own scope and deliverables.
Can an in-house team run a self-hosted Shopware store?
An in-house team can run Shopware if it has people who can operate PHP-based application servers, a relational database, caching, search and the deployment pipeline, and who can apply Shopware updates on a regular schedule. Shopware publishes maintained release lines, so someone must track which line your store is on and plan upgrades before support windows change. Teams without that experience usually need an outside partner for the first build, the hardening and the upgrade runbook, then keep a smaller internal team for daily operations. Confirm the required skills and the supported hosting options with Shopware's documentation before you staff the project.
What does the work need from our team during a migration?
You need named owners for the product catalog, customer data, order history, the storefront design and the payment setup, plus someone who can approve decisions about which BigCommerce apps to replace. Your team must also confirm which integrations feed the store, such as ERP, shipping and tax tools, because each one needs an endpoint or export in the new setup. Expect your merchandising and customer service staff to review imported data and test checkout before go-live. Agree these responsibilities in writing at the start so that delays in one area do not stall the rest.
How long does a move from BigCommerce to Shopware take?
No fixed duration applies to every store, and no researched figure is available for this migration, so treat any single number with caution. The timeline is set by catalog size, the number of apps to replace, how much the theme changes, the volume of SEO redirects, integration complexity and the number of test cycles your business requires. Rate limits on the BigCommerce Catalog API can also extend extraction time for large catalogs. Ask for a timeline built from a written scope with milestones, and check that it includes a parallel run period before you turn off the old store.
Can we stay on the Shopware Community Edition after the migration?
You can stay on the Community Edition only while your shop stays under the revenue threshold that Shopware sets for it. 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. The Community Edition includes a visual page builder, product management and Shopware Payments, but community support only. If your business is near the threshold or expects growth, compare the Rise, Evolve and Beyond plans and their support response times before you commit. Confirm the current terms directly with Shopware, because plan details can change.
How is the 1 million euro threshold measured?
The threshold is measured as gross merchandise value, which Shopware's pricing page describes as the value of goods sold, over the preceding 365 days, for shops linked to an account. Shopware states that plan pricing also depends on gross merchandise value and other individual factors. Because the measurement counts all shops linked to the account, a multi-store setup can cross the threshold sooner than a single shop would. Before relying on the Community Edition, ask Shopware how it counts returns, multiple currencies and linked storefronts, and keep your own sales reports so you can show the figure at any time.
Which hosting option should we choose for Shopware?
Shopware can run as SaaS, as PaaS on managed infrastructure or self-hosted, according to its pricing page. SaaS reduces the number of systems you operate but limits how deep you can change the platform. Self-hosting gives you control over data location, network design and patch timing, but makes your team responsible for servers, backups, security patches and uptime. PaaS sits between the two. Choose based on your data residency rules, the security controls your auditors expect and the skills you can staff, and document that choice before the build starts.
Does DeployOpen handle the full Shopware migration?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask any partner, including DeployOpen, to show how they will handle catalog extraction, theme rebuild, data import and testing within your environment.
Who patches, upgrades and supports a self-hosted Shopware store
Moving from BigCommerce to self-hosted Shopware shifts day-to-day operations to your team or a partner you contract. The cards below cover the responsibilities that BigCommerce currently carries and that you must assign, price and staff before cutover.
Choosing a minor line to run
Shopware currently has two maintained minor lines, 6.7 and 6.6, so you must decide which one your store runs and when it moves. Staying on one line means you receive fixes for that line only, so plan a dated upgrade path before the line you chose stops receiving updates. Check the release notes for each patch before applying it, and confirm with Shopware which line will be supported for your planned go-live window.
Security patching ownership
With BigCommerce, the platform provider applies platform patches to the hosted service. On a self-hosted Shopware store, your team or your contracted partner applies Shopware patches, extension updates and operating system and PHP updates. Write down who watches the release feed, who tests patches in staging, and the maximum time allowed before a critical fix goes live.
Hosting and availability
Shopware can run as SaaS, as PaaS on managed infrastructure or self-hosted. Choosing self-hosting makes you responsible for servers, the database, caching, queues, load balancing and failover, and for the uptime targets your business needs. Ask any hosting provider for their written availability commitment and for how they handle incident communication.
Backups and restore testing
A self-hosted store needs regular backups of the database, media files, configuration and any custom plugin code, stored away from the production servers. A backup that has never been restored is not evidence of recovery, so schedule restore tests into a staging environment and record the results. Confirm retention periods and recovery objectives with your hosting provider in writing.
Support response tiers
Shopware's pricing page lists support response times by plan: Rise includes an 8-hour response, Evolve a 4-hour response, and Beyond 1-hour 24/7 support. Community Edition users have community support only. Map these tiers to your order volume and revenue exposure, and note that the tier you need may depend on your gross merchandise value. Confirm the current terms on the pricing page before you sign.
Staffing the store team
Running Shopware in-house requires roles for PHP and Symfony development, Shopware-specific theming and plugin work, DevOps, and a store owner who handles content and merchandising. Smaller teams often contract some of these roles to a partner under a retainer. Compare the cost of hiring for each role against a retainer, and ask any partner for named roles, response commitments and a written handover plan.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source platforms inside your own infrastructure. For a BigCommerce vs Shopware decision, we start by testing which of your store requirements the Community Edition can meet and which need a paid plan or a different platform.
How we scope
- Map your current BigCommerce apps, page builder use and B2B requirements to Shopware features and plugins
- Confirm your gross merchandise value over the preceding 365 days against the Community Edition threshold before design starts
- Agree hosting choices for SaaS, managed PaaS or self-hosted Shopware in a written, fixed-scope document
How we build
- Configure the Shopware 6 environment, storefront theme and product management in your own cloud account or data center
- Rebuild checkout, payment and customer account flows with Shopware Payments or the payment providers you already use
- Test catalog, pricing and B2B quote flows against agreed acceptance criteria before any production cutover
How we hand over
- Document architecture, configuration, plugin choices, backup routines and the upgrade path for both maintained Shopware lines
- Deliver runbooks for store administrators, developers and the team that will own the hosting environment
- Provide evidence of configuration and testing that your internal auditors or assessors can review
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover
- Review Shopware releases and plugin changes so your team can plan updates on a known schedule
- Keep the scope, deliverables and responsibilities for each support period agreed in writing
