Shopware vs Sylius: when each one fits
Shopware suits teams that want merchant-ready admin features and a paid support tier on day one, while Sylius suits teams with in-house PHP and Symfony capacity that will build the storefront, admin behavior and checkout themselves. Both codebases are MIT-licensed, so license cost does not separate them. The real cost difference lies in who builds, operates and upgrades what the shop does. Start by counting your Symfony developers and asking how much of the back office and checkout must work at launch without custom code.
Next, test Shopware's GMV rule against your forecast. The Shopware 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. If you expect to cross that threshold, price Rise, Evolve or Beyond into the comparison, since plan pricing also depends on GMV and other individual factors. Sylius's Community Edition is free and open source, so the equivalent question for Sylius is the scope of modules you will build or buy, not a revenue cap.
Finally, check whether your B2B, multi-store or fulfillment needs point to Sylius Plus. The Sylius README lists one-page checkout, a B2B suite, multi-store management, partial order fulfillment, returns handling, a loyalty system and multi-source inventory as Sylius Plus modules, with SLA-backed support. Ask Sylius which of these you would need, confirm the current Sylius Plus terms directly, and ask Shopware how its paid plans cover B2B quotes and approvals. Either way, request a written scope from implementers so that build effort, upgrade work and support are priced against the same requirements.
Which platform fits which team scenario
This table maps common team situations to the platform that usually fits better, and names the condition that drives each choice. Read each row against your own launch date, engineering capacity and sales model, since the right answer often turns on one factor rather than on feature lists.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Merchant needs a working admin on launch | Shopware | Shopware ships a merchant-ready admin and visual page builder in the Community Edition, so store staff can run products and pages without a custom back office. Confirm the feature set for your market in the current release. |
| Strong Symfony team building a custom storefront | Sylius | Sylius is a headless framework on PHP, Symfony and API Platform with a REST API for custom storefronts, which suits teams that want to own the frontend and domain model. |
| B2B wholesaler needing quotes and approvals | Shopware (Evolve) or Sylius (Elesto or Sylius Plus) | Shopware lists B2B quotes and approvals in its Evolve plan. Sylius offers a B2B suite in Sylius Plus and a preconfigured B2B setup called Elesto. Compare which set covers your approval rules and confirm licensing for each. |
| Multi-store group | Sylius Plus or Shopware paid plan | Sylius Plus includes multi-store management. Confirm which Shopware plan covers your store structure, since plan pricing depends on GMV and other factors on Shopware's pricing page. |
| Marketplace model with multiple vendors | Sylius (Dafre) | Sylius presents Dafre as a multi-vendor marketplace variant. Confirm whether it meets your vendor onboarding and payout requirements before you commit. |
| Budget relies on free software with community-only support | Shopware Community Edition or Sylius Community Edition | Shopware's Community Edition includes community support only, while Sylius Plus carries SLA-backed support. If you need contractual response times, plan for a paid tier on either side and confirm terms in writing. |
| Revenue will exceed 1 million euros GMV within 365 days | Plan for a Shopware paid plan or evaluate Sylius | Shopware's Fair Usage Policy requires a paid plan above 1 million euros GMV over the preceding 365 days. Sylius is MIT-licensed with no comparable revenue threshold in the supplied facts, so confirm its terms directly. |
| Ready to run and extend the core in-house | Sylius Community Edition | Sylius requires Composer-based installation and a team that maintains its own integrations, so the effort sits with your engineers rather than with a bundled merchant admin. |
How Shopware and Sylius differ in architecture and deployment
Shopware and Sylius both sit on PHP and Symfony, but they ship in very different shapes. Shopware arrives as an integrated platform with its own admin and storefront, while Sylius arrives as a framework that your team assembles and exposes through its API. The cards below cover where that split changes who runs the server, how upgrades land, and how much build work falls to your team.
Integrated admin and storefront
Shopware ships a merchant admin, storefront and commerce features as one product, so a merchant can run a shop without a custom application layer. It can run as SaaS, as PaaS on managed infrastructure, or self-hosted on your own servers. The deployment choice decides who patches the operating system, database and PHP runtime, and how much of the stack you can change. Confirm which of those layers your chosen model hands to Shopware and which stay with your team.
Headless framework with a REST API
Sylius is a headless framework: the README describes a REST API for integrations and custom storefronts, so the storefront is something your team builds or chooses. That suits teams with their own frontend, ERP or marketplace integrations, but it means the storefront, checkout experience and admin screens are project work rather than defaults. Ask which Sylius capabilities you would need to build yourself and which come from plugins or Sylius Plus.
Symfony and API Platform foundation
Both platforms are PHP products, and Sylius builds directly on Symfony and API Platform, which your developers will need to know well to extend it. Shopware is also PHP, but its extension model is its own. Staffing matters more than language here: a team fluent in Symfony will find Sylius familiar, while a team that mainly knows Shopware's plugin system will need to learn Sylius's service and resource conventions before it can ship changes.
Composer and Docker installation
Sylius is installed with Composer, following its documentation's requirements and a Docker guide, so your team owns the application repository, dependency lock file and container images. Shopware's self-hosted path also involves your own servers, but the platform is delivered as a product you configure and update. Check how your CI/CD pipeline, secrets handling and container registry will fit each model before you commit to either.
Upgrades across maintained lines
Shopware maintains two minor lines at the moment, 6.7.15.1 and 6.6.10.29, both released on October 7, 2026. Sylius publishes v2.3.1 and v2.2.11, released on October 14, 2026, and keeps CHANGELOG and UPGRADE files for each 2.x minor from 2.0 to 2.3. Your team should read the UPGRADE file for every hop it plans, because those notes decide how much custom code and plugin work each upgrade costs. Confirm the support window for each line with the vendor before you plan a version.
Who operates the stack
With Shopware SaaS or PaaS, part of the operating burden moves to the vendor, so your team focuses on configuration, extensions and store operations. With self-hosting on Shopware, or with any Sylius deployment, your team or your implementation partner runs servers, backups, search, queues and security patching. Put this responsibility split in writing before you select a model, because it drives the size of the operations team you need after go-live.
Shopware vs Sylius feature by feature
This table compares Shopware and Sylius on licensing, release lines, APIs, admin, B2B, multi-store, returns, loyalty, inventory, plugins, support and hosting. Where a capability sits in Sylius Plus rather than the Community Edition, the row says so, and where the supplied facts do not settle a point, the cell tells you what to confirm with the vendor.
| Capability | Shopware | Sylius |
|---|---|---|
| License | MIT License for the shopware/shopware repository, with a free Community Edition and paid Rise, Evolve and Beyond plans | MIT license for the Sylius repository, with a free Community Edition and Sylius Plus as the paid module set |
| Maintained release lines | 6.7.15.1 and 6.6.10.29, both released October 7, 2026 | v2.3.1 and v2.2.11, both published October 14, 2026 |
| REST API | Confirm endpoint coverage and versioning for your use case in the Shopware developer documentation | Documented REST API for integrations and custom storefronts, per the Sylius README |
| Headless use | Confirm headless storefront options and API scope for your plan with Shopware | Designed as a headless platform on PHP, Symfony and API Platform, so custom storefronts are a core pattern |
| Admin out of the box | Merchant-ready admin included with the platform, the core reason teams pick it | Developer framework; admin and storefront are built or assembled by your team, confirm admin scope in the docs |
| Visual page builder | Included in the Community Edition, per Shopware's pricing page | Not listed as a core feature; confirm whether a Sylius Plus or plugin option covers your needs |
| B2B features | B2B quotes and approvals listed on the Evolve plan, per Shopware's pricing page; confirm details per plan | B2B suite included in Sylius Plus; Elesto is a preconfigured B2B setup for manufacturers and wholesalers |
| Multi-store | Confirm multi-store support and which plan includes it with Shopware | Multi-store management included in Sylius Plus, not in the Community Edition |
| Returns handling | Confirm returns workflow coverage with Shopware for your plan | Returns handling included in Sylius Plus, not in the Community Edition |
| Loyalty system | Confirm whether a loyalty feature exists natively or through a plugin | Loyalty system included in Sylius Plus, not in the Community Edition |
| Multi-source inventory | Confirm inventory model and multi-warehouse support with Shopware | Multi-source inventory included in Sylius Plus, not in the Community Edition |
| Plugin distribution | Shopware plugin ecosystem; confirm marketplace and compatibility rules with the vendor | Plugins distributed through the Sylius Store and on Packagist under the sylius-plugin type |
| Paid support tier | Rise lists 8-hour response, Evolve 4-hour, Beyond 1-hour 24/7, per Shopware's pricing page | Sylius Plus includes SLA-backed support; confirm response times in your agreement |
| Hosting options | SaaS, PaaS on managed infrastructure or self-hosted, per Shopware's pricing page | Self-hosted on your infrastructure with Composer and a Docker guide; no managed SaaS option in the supplied facts |
What the license and paid editions cover for each platform
Both Shopware and Sylius publish their core code under the MIT License, which allows you to use, modify and self-host it without a license fee. That shared point removes license cost as a differentiator between the two, so the decision comes down to the features in each edition, the support you need and the effort to build what the product does not include. The MIT license does not cover the paid plans, which are separate commercial agreements.
- Permissive terms: MIT lets you run and change the core code inside your own infrastructure.
- No license line for the core: Neither vendor charges for downloading or running the open-source code.
- Paid tiers are separate: Shopware's plans and Sylius Plus are commercial offerings on top of the MIT code.
- Plugins carry their own terms: Check the license of each Sylius plugin or Shopware extension you plan to use.
Confirm the license of each extension and third-party module in your build with the vendor before you rely on it.
Shopware's core is MIT licensed, and it offers a free Community Edition alongside paid Rise, Evolve and Beyond plans. The Community Edition includes a visual page builder, product management and Shopware Payments, with community support only. Under its Fair Usage Policy, 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 states that plan pricing depends on gross merchandise value and other individual factors.
- Rise: Listed at 600 euros per month, with AI-assisted content and 8-hour support response.
- Evolve: Listed at 2,400 euros per month, with B2B quotes and approvals and 4-hour response.
- Beyond: Custom pricing, with 1-hour 24/7 support.
- GMV threshold: The 1 million euro annual GMV rule applies to shops linked to an account, so check how your accounts are structured.
- Hosting choice: Shopware can run as SaaS, as PaaS on managed infrastructure, or self-hosted.
Ask Shopware for a written quote that states your expected GMV, which plan it maps to, and whether the response times apply to your region and hours.
Sylius is MIT licensed and describes itself as a headless open-source eCommerce platform built on PHP, Symfony and API Platform. The free Community Edition gives you the framework and a REST API for integrations and custom storefronts. Sylius Plus is the commercial tier, adding modules such as one-page checkout, a B2B suite, multi-store management, partial order fulfillment, returns handling, a loyalty system and multi-source inventory, with SLA-backed support. The sylius.com site also presents Elesto, a preconfigured B2B setup for manufacturers and wholesalers, and Dafre, a multi-vendor marketplace variant.
- Community Edition: Free, MIT licensed, and built as a framework you assemble and extend.
- Sylius Plus modules: One-page checkout, B2B, multi-store, returns, loyalty and multi-source inventory.
- SLA-backed support: Part of the Plus offering, so confirm the response targets in writing.
- Elesto: A preconfigured B2B option for manufacturers and wholesalers.
- Dafre: A multi-vendor marketplace variant.
Confirm with Sylius which Plus modules are included in your contract, what the SLA covers, and whether Elesto or Dafre fits your model without changes to your build.
On both platforms, the paid tier buys a service and support commitment, plus features you would otherwise build or maintain yourself. It does not buy the right to use the MIT code. Your costs also include the hosting stack, your own developers or a partner for the implementation, and ongoing upgrades. Those are the largest recurring items for most teams, and they are not covered by any license fee.
- Subscription tier: Shopware's plans are priced on GMV and other factors, while Sylius Plus pricing is set in a separate commercial agreement.
- Build and integration work: Custom features, theme work and integrations are paid for through your team or a partner.
- Hosting and operations: Self-hosting puts servers, backups and monitoring on your side of the budget.
- Upgrades: Both vendors maintain two minor lines, so budget for regular upgrade work.
- Support windows: Response times differ by plan, so match them to your incident needs.
Request a quote that separates license or subscription fees, implementation, hosting and recurring upgrade effort so you can compare the two options on the same basis.
What drives running cost on Shopware and Sylius
The biggest difference in running cost is who sells you the components. On Shopware, the licence is free under the MIT License, but the free Community Edition is limited by the 1 million euro gross merchandise value rule, and the Shopware pricing page sets Rise at 600 euros per month and Evolve at 2,400 euros per month, with Beyond priced individually. Those plan fees are recurring and scale with GMV and further individual factors, so you should confirm exactly which plan your projected volume lands on before comparing totals. On Sylius, the core is MIT-licensed, but Sylius Plus pricing is not in the facts supplied for this page, so you must request it in writing. Either way, you pay a PHP and Symfony team or an agency for the storefront, integrations and any plugins from the Sylius Store or Packagist, and each plugin adds a maintenance line. Split the budget into one-time and recurring costs. One-time costs include the build or configuration of the storefront, integration with your ERP and payment providers, and data migration from your current platform. On Shopware, a large share of this is configuration through the merchant-ready admin, so the agency bills more for setup and less for custom code. On Sylius, a larger share goes to developers writing the storefront and checkout. Recurring costs include hosting (self-hosted, PaaS or SaaS, which Shopware supports), upgrades between maintained minor lines (Shopware 6.7 and 6.6 are both maintained, and Sylius 2.3 and 2.2 are both maintained), plugin and extension maintenance, and your support tier. Shopware support response times rise with plan level, so ask what response time is included at each tier. When you request a quote from any partner, including DeployOpen, ask for four things in writing. First, the scope: which features, integrations and plugins are included and which are excluded. Second, upgrade responsibility: who tests and applies minor and major releases, and who pays when a plugin breaks. Third, support response commitments: the hours, the severity levels and the response times, with the source stated for any vendor SLA. Fourth, hosting ownership: who holds the cloud account, the backups and the on-call duty. Illustrative example: a quote that omits plugin upgrades will look cheaper in year one and cost more when the next maintained release arrives.
Moving a shop from Shopware to Sylius or back
The sequence below turns a move between Shopware and Sylius into a checked plan: it confirms the commercial position first, then maps what carries over, rebuilds what does not, and proves the new shop works before any customer is switched across.
Confirm the GMV position and license terms
Start with the commercial facts. If the shop runs on the Shopware Community Edition, check the gross merchandise value over the preceding 365 days against the 1 million euro threshold in Shopware's pricing page, because a shop above it needs a paid plan under the Fair Usage Policy. Confirm which Shopware plan and hosting model (SaaS, PaaS or self-hosted) is in place, and confirm that Sylius Plus or any Sylius plugin license covers the features you need. Both platforms are MIT-licensed at the core, so the license decision rests on paid tiers and modules, not on the code. The output is a written note of current GMV, plan, hosting and every paid component, signed off by the business owner.
Inventory data, integrations and customizations
Your team, or the implementation partner, lists every data object in use: products, variants, prices, customer accounts, orders, returns, promotions, tax rules and media. Then list every integration (ERP, payment, shipping, tax, PIM, marketing, analytics) and every custom plugin, theme and checkout change. Mark each item as one of three things: standard data that exports cleanly, data that needs transformation, or code that must be rebuilt. The output is a register that states the owner, source system and target for each item, so no integration is discovered during cutover.
Map catalog, customer, order and promotion data
Build a field-level mapping between Shopware's data model and Sylius's data model, which uses its own entities for channels, locales, taxonomy, shipping and payment methods. Decide how product variants, option sets, customer groups and promotion rules translate, and where a rule has no direct equivalent and must be redesigned. Agree how historical orders are stored and whether they are needed as live records or as read-only archive. The output is a signed mapping specification with worked examples taken from real records, reviewed by merchandising, finance and fulfillment.
Export, transform and load test data
Extract data from the source with a repeatable script or export job, transform it according to the mapping, and load it into a non-production instance of the target. Run the load several times until the record counts, totals, tax values and media links match the source within agreed tolerances. Where a record fails validation, log the cause and fix the mapping rather than editing records by hand. The output is a load report that shows counts and reconciliation results for each data type, reviewed by the data owner.
Rebuild storefront, plugins and admin workflows
Plan the components that do not carry over directly. Shopware themes and Twig templates do not transfer to Sylius, which uses its own storefront approach and REST API for custom storefronts. Custom plugins and checkout logic need to be rewritten against Sylius's extension points, and admin workflows such as approvals or returns must be rebuilt or replaced with Sylius Plus modules where they fit. Confirm each Sylius plugin on the Sylius Store or Packagist, and check it against the release line you intend to run. The output is a rebuild backlog with each item tied to a business requirement and a named owner.
Run parallel testing and reconciliation
Operate the old and new shop side by side in a controlled test environment. Replay representative orders through checkout, payment, tax, shipping, refunds and returns, and compare the outcomes with the source system. Include integration tests with the ERP, payment provider and fulfillment, and run security checks on the new deployment, including access control and secrets handling. The output is a test report with pass or fail status for each scenario, and a list of open defects with agreed fixes before go-live.
Plan and execute cutover
Agree a cutover runbook that defines the freeze window for catalog and order changes, the final incremental data sync, DNS or routing changes, payment and webhook switches, and the rollback criteria. Confirm the backup of the source system and the restore procedure before the freeze starts. After cutover, watch orders, payments and error logs closely, and keep the source system read-only until the business confirms that reconciliation is complete. The output is a signed cutover record and a retained rollback path for an agreed period.
Where Shopware and Sylius implementation projects run long
Shopware projects usually run long when the team treats the admin as finished and discovers late that it is not. Configuring the admin, connecting the payment, tax and ERP integrations, choosing between SaaS, PaaS and self-hosted hosting, and selecting plugins each carry their own decisions and sign-offs. Sylius projects run long for a different reason: the team owns more of the build. Designing the domain model, building the storefront, wiring the REST API, and writing the checkout and order logic are all work your developers do before a merchant sees anything usable. Ask who owns each of those pieces in the written scope, and whether the plan assumes any of them is already done.
The delays that recur on both platforms are predictable. B2B approval rules are often described loosely at kickoff, then rewritten once buyers, credit controllers and sales staff disagree on who approves what. Payment and tax integrations take longer than planned because the certification, sandbox and rounding details belong to third parties. Data migration quality is the quiet risk: poorly cleaned product, customer and price data pushes testing back. Custom features are the most expensive assumption. A requirement that a team expects to be configuration on one platform can become a plugin search, a code change or a Sylius build, so classify each requirement as configuration, plugin or custom code before estimating.
Before committing to either platform, confirm the upgrade path between the maintained minor lines. Check which Shopware lines are currently maintained and how your plugins and customizations move between them, and check how Sylius's CHANGELOG and UPGRADE files handle the 2.x minor versions your custom code depends on. Ask the vendor and your implementation partner for a written upgrade plan that covers your plugins, your payment integration and your data model, because an upgrade you postpone for a year often costs more than the one you planned.
Shopware vs Sylius questions buyers ask before hiring help
How much more effort is it to build a Sylius store than to configure Shopware?
Shopware usually needs less build work for a standard store because its admin, product management, visual page builder and checkout are already part of the platform. Sylius is a developer framework on Symfony and API Platform, so most storefront screens, admin workflows and integrations are designed and written by your team or a partner. The gap narrows when the business needs little beyond a standard catalog and checkout, and widens when it needs custom order flows, bespoke promotions or several channels. Sylius Plus adds prebuilt modules such as one-page checkout, a B2B suite and multi-store management, which reduces some build work but still needs configuration and testing. Ask any bidder to split the estimate into configuration, custom code and integration work so you can compare the two platforms on the same terms.
Is the free Shopware Community Edition enough, and when does the GMV rule apply?
The Community Edition is enough for a shop that stays under the threshold and does not need paid support or the features in Rise, Evolve or Beyond. 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 must move to a paid plan. The Community Edition includes a visual page builder, product management and Shopware Payments, with community support only. Paid plans are priced on gross merchandise value and other individual factors, so the plan cost depends on your volume and needs. Rise lists 600 euros per month with 8-hour support response, and Evolve lists 2,400 euros per month with B2B quotes and approvals and 4-hour response. Confirm your GMV trajectory and support requirements with Shopware before you commit to a build.
What does Sylius Plus add beyond the free Sylius Community Edition?
Sylius Plus adds a set of commercial modules to the open-source core, including one-page checkout, a B2B suite, multi-store management, partial order fulfillment, returns handling, a loyalty system and multi-source inventory. It also includes SLA-backed support, which the free community setup does not provide. These modules matter most when your business needs wholesale accounts, several stores under one administration, or warehouse-level inventory. If you only need a single B2C store, the Community Edition plus your own code may cover the scope. Sylius also offers Elesto as a preconfigured B2B setup for manufacturers and wholesalers, and Dafre as a multi-vendor marketplace variant. Ask Sylius for current Plus pricing and the exact SLA terms, since neither is supplied here.
Can our team run Shopware or Sylius without outside help?
A team can run either platform in-house if it has PHP and Symfony skills, a Linux operations capability and someone who owns upgrades and security patches. Shopware's admin and built-in tools lower the day-to-day load for merchandising staff, but hosting, deployment, plugin review and upgrades still need engineers. Sylius asks more of your developers because most business logic and admin behavior is code you own. Both are MIT-licensed, so there is no license fee to pay for the software itself, but staff time, hosting and support contracts are real costs. Outside help is most useful for the first build, for hardening and for the first upgrade between minor lines, where the release notes and UPGRADE files need careful reading. Decide who will take each of those tasks before you pick a platform.
How long does a Shopware or Sylius project usually take?
Duration depends on the scope, so no general figure applies. The main drivers are the number of custom checkout, pricing and promotion rules, the number of integrations with ERP, payment, shipping and tax systems, the number of storefronts or markets, and how much data migration is needed from an existing shop. A Sylius build usually has more custom code to design and test than a Shopware configuration, which tends to lengthen the schedule when the requirements are broad. Shopware projects can still run long when plugins need heavy adaptation. Under a fixed-scope agreement, DeployOpen agrees the scope, deliverables and timeline in writing before work starts, so you can compare two written plans. Ask each party for a milestone plan that shows testing, data migration and go-live readiness separately.
What does a store build need from our side?
The build needs named decision makers, a staging environment that matches production, and access to the systems the store must talk to. Your team should provide product data, tax and shipping rules, payment provider accounts, and a sign-off owner for each stage. For Sylius, you also need developers who will review code, write tests and maintain the repository. For Shopware, you need someone who can approve plugin choices, theme changes and the upgrade path between the maintained 6.6 and 6.7 lines. Hosting can be SaaS, PaaS or self-hosted in Shopware's case, so decide early who operates the environment. Agree on written acceptance criteria before development starts, because unclear sign-off is one of the most common causes of delay.
How DeployOpen helps teams choose, implement or migrate
DeployOpen plans, implements and supports self-hosted open-source platforms inside the client's own infrastructure. For Shopware vs Sylius, we start with a written scope that fixes the decision criteria, the build boundaries and the handover deliverables before any work begins.
How we scope
- Written scope lists which Shopware edition or Sylius setup the shop needs, agreed before work starts.
- Scope maps required checkout, B2B, multi-store and inventory features to either out-of-the-box Shopware or custom Sylius work.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing; ongoing support is available as a retainer.
How we build
- Build the shop inside your own cloud accounts, data centers or air-gapped network, on the hosting model you choose.
- For Sylius, implement custom storefronts and integrations against the REST API, with plugins reviewed before installation.
- Run security testing on the storefront, APIs and payment integration before any production launch.
How we hand over
- Document the architecture, deployment steps, upgrade path between maintained minor lines and customization decisions.
- Provide runbooks for backups, restores and version upgrades so your team can operate the stack after handover.
- Prepare configuration and evidence needed for your compliance reviews, while independent auditors issue any assessment results.
How we support
- Offer ongoing support, upgrades and continuous testing as retainers aligned to the handover documentation.
- Plan upgrade windows around the release cadence of the platform you chose, with the written scope defining responsibilities.
- Confirm with your team which support tier, response times and plugin vendor terms apply before signing the scope.
