Shopware vs PrestaShop: when each platform fits
Choose Shopware when you want a merchant-ready admin and a clear path to paid support as gross merchandise value grows. Choose PrestaShop when you want an OSL-3.0 core with no revenue cap and your team is comfortable building and maintaining its own extensions. The decision usually turns on five questions: expected GMV against the 1 million euro threshold, required B2B features, the extension ecosystem you depend on, API needs and in-house PHP capacity. Answer them in that order, because the first one can rule out a platform before the others matter. Start with annual GMV over the preceding 365 days. Shopware's pricing page says shops linked to an account above 1 million euros in gross merchandise value must move from the free Community Edition to a paid plan, so a shop that expects to cross that line within your planning horizon needs a budget line for Rise, Evolve or Beyond from the start. PrestaShop has no revenue cap in its license, so the cost question shifts to hosting, extensions and the people who maintain them. Confirm the exact plan terms with Shopware directly, since plan pricing also depends on individual factors beyond GMV.
Next, check B2B requirements and API needs. Shopware's Evolve plan lists B2B quotes and approvals, which many wholesale teams treat as a deciding feature. For integrations, PrestaShop 9 provides a webservice with access keys for CRUD access to products, orders and customers, plus an Admin API built on API Platform with OAuth2 authentication and Swagger documentation. Map your ERP, payment and fulfillment integrations against those interfaces before you commit, and confirm with each vendor which endpoints and roles your integration actually needs. Finally, assess the extension ecosystem and PHP capacity. Ask which payment, tax and marketplace connectors you need, whether they exist for each platform and who maintains them after launch. PrestaShop's module licensing under AFL-3.0 and its supported lines (8.2.8 and 9.1.5 were both published on August 18, 2026) matter for your upgrade plan. A team with strong in-house PHP skills can take on that maintenance work; a team without it should price in external support before choosing the platform with the lighter build.
Which platform fits which scenario
This table matches common Shopware and PrestaShop scenarios to the platform that fits better and the condition behind that choice. Read each row against your own GMV, team skills and integration needs, since the conditions decide the answer more than the platform name does.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Small shop with modest, predictable GMV | PrestaShop | The shop stays well below 1 million euros in annual GMV, so no paid Shopware plan is triggered, and PrestaShop's core has no revenue cap under OSL-3.0. Confirm current module and theme costs for your needs. |
| Shop approaching 1 million euros in annual GMV | Decide on the growth path first | Shopware's Fair Usage Policy requires a paid plan above 1 million euros in GMV over 365 days. If you expect to cross that line, budget for a Rise, Evolve or Beyond plan or ask Shopware to confirm the cost before choosing. |
| B2B wholesaler needing quotes and approvals | Shopware | Shopware's Evolve plan lists B2B quotes and approvals. This applies only if you accept the paid plan. Confirm whether PrestaShop's modules cover your quote and approval workflow before assuming parity. |
| Team with strong PHP skills wanting maximum customization | Either, depending on the codebase you want | PrestaShop is open source under OSL-3.0 with AFL-3.0 modules, which suits teams that want to modify the core. Shopware is MIT-licensed, which also allows modification. Choose by which framework your developers already know. |
| Team needing a documented admin API | PrestaShop | PrestaShop 9 adds an Admin API built on API Platform with OAuth2 and Swagger documentation, and its webservice gives CRUD access with access keys. Confirm the endpoints you need against the PrestaShop 9 developer documentation. |
| Team that wants a free edition with a built-in page builder | Shopware | The Shopware Community Edition includes a visual page builder and product management, but it carries community support only. Choose it if you can run without paid support response times. |
| Team that needs a supported PHP and database stack on current versions | Confirm for both | PrestaShop 9 requires MySQL 5.7 or MariaDB 10.2 minimum and recommends at least 512M memory_limit. Shopware's supported stack is not covered by the supplied facts, so confirm it on the Shopware requirements page before deciding. |
| Team that must run on Windows servers | Neither, confirm before choosing | PrestaShop states Windows is not actively supported and works best on Unix-based systems. Confirm Shopware's operating system support directly with the vendor. |
How each platform is built and deployed
Shopware and PrestaShop both run on PHP, but they reach production in different ways. Shopware offers three hosting models with different operating responsibilities, while PrestaShop is a self-hosted application whose install path, web server and runtime settings you own.
Shopware's three hosting models
Shopware can run as SaaS, as PaaS on managed infrastructure, or self-hosted on your own servers. Each choice moves responsibility for servers, patching and upgrades between Shopware and your team. Plan pricing is based on gross merchandise value and other factors, so confirm with Shopware how hosting choice interacts with the plan you need. Ask which upgrade path applies to each model before you commit.
Self-hosting Shopware on your infrastructure
Self-hosting places Shopware in your cloud account, data center or private network, which suits teams with strict data residency rules or existing platform engineering. Your team then owns the PHP runtime, database, caching, queues and the upgrade calendar. Confirm the exact system requirements for your target Shopware release before sizing servers.
PrestaShop's self-hosted install model
PrestaShop has no vendor-run hosting tier in the supplied facts, so you install it on a server you control. Its documented stack is PHP with Apache 2.4 or later, or Nginx, and MySQL 5.7 or MariaDB 10.2 at minimum. Confirm the PHP version your chosen release needs, since the supplied requirements name the database and web server but not a PHP version for every line.
Installing from releases, not the repository
The PrestaShop GitHub repository is for development and preview, and the README says production shops should be installed from the releases page. Using the development branch for a live store means running code that is not packaged for production. Build your deployment pipeline around the tagged release artifacts and test upgrades in a staging copy first.
Web server and runtime tuning
PrestaShop works best on Unix-based systems, and Apache or Nginx both serve it. The docs recommend a PHP memory_limit of at least 512M, which you set in your runtime configuration and validate under load. Windows hosting is not actively supported, so a Windows-based estate would need a deliberate decision and extra testing that the supplied docs do not cover.
Operations and database ownership
Under PrestaShop, your team owns the web server, the MySQL or MariaDB database, backups and the ongoing security patching of the application. Under self-hosted Shopware, the same ownership applies to the Shopware stack. Under Shopware SaaS or PaaS, part of that work sits with the provider. Ask each vendor which operational duties they carry and write them into the contract.
How the 1 million euro GMV rule changes the decision for Shopware
The 1 million euro GMV threshold decides whether the free route stays open for Shopware. Shopware's Community Edition is free under the MIT License, but 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 (Rise, Evolve or Beyond). Plan pricing is based on gross merchandise value and other individual factors, so the cost at that point is not fixed by the threshold alone. If your forecast for the shop, or for the account it sits under, could cross that line within the planning horizon, model the paid plan cost before you commit to the Community Edition as the base for a build.
PrestaShop's core is licensed under OSL-3.0 and its modules under AFL-3.0, and the supplied facts do not describe any revenue cap on the open-source route. That difference matters for a team whose GMV is growing: the Shopware decision carries a commercial trigger that the PrestaShop decision does not, based on the facts supplied here. Do not read the absence of a cap as a guarantee of free use in every scenario. Confirm with PrestaShop, in writing, whether any commercial terms, hosted offerings or add-on subscriptions could apply to your shop, and check the licenses of every third-party module you plan to install, since module licenses are separate from the core.
Before choosing, ask Shopware in writing which account and shop structures count toward the 365-day GMV figure, how multiple storefronts under one account are aggregated, and what the Rise or Evolve quote would include for your volume. Ask whether the Community Edition's visual page builder, product management and Shopware Payments features stay within the free route for your use, and what support you receive there. Then ask PrestaShop how its maintained 8.x and 9.x lines and any commercial support arrangements are priced for your team. Record the answers alongside your own GMV forecast, so the licensing decision is made on written terms rather than on the headline license alone.
Capabilities, APIs and maintained versions side by side
This table sets Shopware and PrestaShop side by side on license, maintained release lines, API surface, support tiers, hosting and database requirements. Where the documented facts do not answer a question, the cell names what to confirm with the vendor or in your own environment. The main takeaway is that Shopware's support tiers and GMV rule are clearly tied to its paid plans, while PrestaShop's API and hosting details are documented but its commercial support options need confirming.
| Capability | Shopware | PrestaShop |
|---|---|---|
| License | MIT License for the shopware/shopware repository, with a free Community Edition and paid Rise, Evolve and Beyond plans | PrestaShop Core under OSL-3.0, with modules under AFL-3.0 |
| Latest supplied release lines | 6.7.15.1 and 6.6.10.29, both released October 7, 2026, showing two maintained minor lines | 9.2.0 released September 30, 2026; 9.1.5 and 8.2.8 released August 18, 2026 |
| Revenue threshold for free use | Shops over 1 million euros in annual GMV must move to a paid plan under the Fair Usage Policy | No revenue cap in the core license; confirm module license terms for each add-on you plan to use |
| API surface | Confirm the current Shopware API scope, authentication model and documentation with Shopware before you design integrations | Webservice with access keys for CRUD on products, orders and customers; PrestaShop 9 adds an Admin API with OAuth2 |
| API documentation and multi-shop | Confirm documentation coverage and multi-shop behavior in current Shopware developer docs | PrestaShop 9 Admin API includes Swagger documentation and multi-shop support |
| Support model | Community support only on Community Edition; Rise 8-hour, Evolve 4-hour and Beyond 1-hour 24/7 response times on paid plans | Commercial support options are not covered in the supplied facts; ask vendors and partners what they offer |
| Hosting options | SaaS, PaaS on managed infrastructure or self-hosted on your own servers | Self-hosted on Unix-based systems; Windows is not actively supported; install production shops from the releases page |
| Database and PHP requirements | Confirm the current PHP and database versions in Shopware's installation documentation | MySQL 5.7 or MariaDB 10.2 minimum, Apache 2.4 or later or Nginx, memory_limit of at least 512M recommended; confirm the PHP version |
What each license and edition covers
Shopware's core code is published under the MIT License, one of the most permissive open-source licenses in common use. For a self-hosting team, the license itself lets you read, modify and run the code without a royalty owed to the vendor for using that code. It does not set what you pay Shopware, because commercial terms come from the Fair Usage Policy and the plan you choose.
- Permissive grant: The MIT License in the shopware/shopware repository allows use, modification and redistribution, provided the copyright notice is kept.
- Separate revenue rule: The license text carries no GMV limit. The 1 million euro threshold comes from Shopware's pricing page and its Fair Usage Policy.
- Measured on linked accounts: 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.
- Hosting stays open: Shopware can run as SaaS, as PaaS on managed infrastructure or self-hosted, so the license does not dictate a hosting model.
Confirm with Shopware in writing how GMV is calculated across multiple shops or storefronts under one account before you assume the free tier applies.
The free Community Edition includes a visual page builder, product management and Shopware Payments. Support for this edition is community-only, so no contracted response time applies to it. That matters most when a payment or checkout fault affects live sales and the team needs a defined escalation path.
- Visual page builder: Included for building storefront pages without writing custom front-end code.
- Product management: Included in the free edition, per the Shopware pricing page.
- Shopware Payments: Included, but with community support only, so incident response depends on public channels rather than a contract.
- Operational budget: Without paid support, production incidents fall to your internal team or an implementation partner, which is a recurring cost even when the license fee is zero.
- Ceiling: Once a shop passes the 1 million euro GMV threshold, the free edition stops being the option you should plan around.
Before you design a build around the Community Edition, list each feature your launch needs and confirm which of them are included in the free edition and which require a paid plan.
Shopware's paid plans are Rise, Evolve and Beyond. The pricing page states that plan pricing is based on gross merchandise value and further individual factors. The figures below are the list prices and response times as published on the Shopware pricing page, so check the current page before you budget.
- Rise: 600 euros per month, with AI-assisted content and an 8-hour support response.
- Evolve: 2,400 euros per month, with B2B quotes and approvals and a 4-hour support response. This tier matters when negotiated pricing and approval chains are part of your order flow.
- Beyond: Custom pricing, with 1-hour support available 24/7. It suits high-volume shops that need contracted response windows, and its scope must be agreed in writing.
- Recurring cost: Plan fees recur monthly. Implementation, customization and hosting are separate costs paid to whoever builds and operates the shop.
- Cost drivers: GMV and other individual factors set the final price, so the published figure is a starting point for your quote.
Ask Shopware for the written plan terms, how GMV is measured for your account, and exactly what each response time covers.
PrestaShop uses two licenses. PrestaShop Core is licensed under OSL-3.0, and PrestaShop modules are licensed under AFL-3.0, according to the LICENSE.md file in the PrestaShop repository. Because the core and modules carry different terms, the license of each component you install matters as much as the license of the platform itself.
- Core under OSL-3.0: Covers the ecommerce application in the PrestaShop repository, which you can self-host and modify.
- Modules under AFL-3.0: Each module's license should be checked before installation, since terms can differ between modules and their sources.
- No revenue cap in the overview: The topic overview describes the core as having no revenue cap. Confirm this against the current license text before you rely on it for a growth plan.
- Paid add-ons and editions: The supplied facts do not describe PrestaShop's commercial offerings, support terms or add-on pricing, so request these directly from the vendor.
- Production source: The PrestaShop README says production shops should be installed from the releases page, not from the development repository.
Ask PrestaShop in writing which license governs each paid module and support contract you plan to use, and what support covers during the lifetime of your chosen version.
How identity and integration work on each platform
PrestaShop exposes shop data to outside systems through its webservice, which gives third-party tools CRUD access to resources such as products, orders and customers using access keys. Each key is scoped to the resources and methods you grant it, so the first decision is which ERP, marketplace connector or fulfillment service really needs write access and which only needs to read orders. Treat keys as service credentials: create one per integration, record its owner, rotate it on a schedule and remove it when the integration is retired. For PrestaShop 9, the newer Admin API is built on API Platform, uses OAuth2 for authentication and ships with Swagger documentation, so teams building new integrations should evaluate it alongside the legacy webservice before committing to one model. Confirm in the PrestaShop 9 webservice documentation which resources each route covers in your version.
The PrestaShop README describes the platform as highly customizable and states that it supports the major payment services. Payment integrations are typically installed as modules, and module licensing is separate from the core: PrestaShop modules are under AFL-3.0, so review each payment or ERP connector's own license and support terms before it goes into production. For identity, the Admin API's OAuth2 support covers machine-to-machine access to the back office API; whether back-office staff can sign in through an external identity provider with single sign-on is a question to put to the vendor and to your module supplier, not an assumption to build on.
Shopware's identity and single sign-on options depend on the deployment: SaaS, PaaS on managed infrastructure or self-hosted, and on the plan you choose. The facts available for this comparison do not establish which SSO protocols, identity provider connectors or API authentication methods each Shopware edition supports, so do not assume parity with PrestaShop's access key or OAuth2 model. Before you shortlist either platform, ask for a written answer for four items: how staff authenticate, how the storefront API authenticates customers and machines, which payment providers are supported natively versus through extensions, and whether ERP connectors are first-party or partner-built. Check the answers against the Shopware pricing page for plan-level features and against Shopware's developer documentation for the deployment you intend to run.
What drives running cost on each platform
This table breaks the running cost of a Shopware or PrestaShop shop into components, showing who gets paid, whether each cost is one-time or recurring, and what moves it up or down. Use it as a checklist for quotes: Shopware's plan prices are the only published figures here, so ask for every other component in writing against your own scope. The main takeaway is that Shopware's paid-plan costs scale with GMV and support tier, while PrestaShop's costs depend more on hosting, modules and in-house skills.
| Cost component | Who is paid | One-time or recurring | What drives it and what to ask for |
|---|---|---|---|
| Hosting or PaaS fees | Hosting provider, or Shopware if you choose its SaaS or PaaS option | Recurring | Shopware offers SaaS and PaaS, so ask whether plan prices include hosting. Confirm PrestaShop hosting options and sizing with providers. |
| PHP and database operations | Your team or hosting provider, for patching PHP and database versions | Recurring | PrestaShop 9 needs MySQL 5.7 or MariaDB 10.2 minimum, with a 512M PHP memory limit recommended. Confirm Shopware's requirements. |
| Upgrades between maintained lines | Your team or a services partner | Recurring, with a cost each upgrade cycle | Shopware maintains 6.7 and 6.6, and PrestaShop maintains 8.x and 9.x. Ask for the upgrade testing scope and rollback plan. |
| Extensions and themes | Extension vendors, theme sellers or developers you hire | One-time build or purchase, plus recurring licence fees | Ask each vendor for licence terms and update support for your version. PrestaShop modules fall under AFL-3.0. |
| Paid support tiers | Shopware for Rise, Evolve or Beyond; PrestaShop support providers if you buy one | Recurring | Rise is 600 euros and Evolve 2,400 euros per month, per Shopware's pricing page. Ask for response times in writing. |
| GMV-based plan step-up | Shopware, once annual GMV passes 1 million euros | Recurring | Shopware's Community Edition is limited to shops under 1 million euros annual GMV. Confirm whether PrestaShop has any revenue-linked fees. |
| Staff skills | Your employees or contract developers | Recurring salary or contract cost | Ask which platform your developers already know and how much custom work your roadmap needs. |
How to move a shop from PrestaShop to Shopware or back
This sequence moves a live shop's catalog, customers, orders and extensions from one platform to the other without losing track of what was changed. It ends with a tested, documented cutover that the merchant can roll back if a check fails. The same order of work applies in either direction, because the data model and the API surface are what decide the effort.
Inventory products, customers, orders and extensions
Start by listing every data type the shop depends on: product catalog with variants, categories, prices and stock, customer accounts and addresses, order history, invoices, discount rules and content pages. List every installed module or Shopware extension and record what each one does, who owns it and whether the vendor still supports the version in use. The merchant and the lead developer sign off on this inventory before any build starts. It is done when every data type has an owner, a target field or a documented decision to drop it, and every extension has a keep, replace or retire decision.
Map source fields to target fields through the APIs
Build a field mapping document that pairs each source attribute with its destination on the other platform. For a PrestaShop source, the webservice gives CRUD access to products, orders and customers through access keys, so extraction can go through the same interface the shop already exposes. On the Shopware side, the Admin API and Store API shape how records are written, and the team should confirm the endpoints and authentication model against the current Shopware documentation for the version they will run. Identify fields with no direct equivalent, such as custom product attributes or order states, and decide how each one is represented. The mapping is complete when a sample of records from each entity type round-trips with no unexplained differences.
Rebuild themes and custom modules
Themes do not transfer between the two platforms, so storefront templates, checkout flows and any custom PrestaShop modules must be rebuilt as Shopware plugins, theme code or configuration. Treat this as new development with its own design review, not a copy job. Confirm which features are available in the Community Edition and which depend on a paid plan, since that affects what can be rebuilt without a licence change. The step closes when each custom feature has a passing functional test on a staging copy and the business owner has accepted the storefront behavior in writing.
Reconfigure payments and tax rules
Payment providers, tax classes, rounding rules and shipping zones are configured separately on each platform and rarely carry over unchanged. Ask each payment provider for its current integration guide for the target platform, and confirm webhook endpoints, test credentials and refund handling in a sandbox. Recheck tax rates and reporting rules with the finance or tax adviser for every market the shop sells into. The step is done when a test transaction completes, a refund posts correctly and a sample order produces the expected tax lines in both the storefront and the accounting export.
Run a full test migration on a staging copy
Run the complete data migration against a staging environment built from the same infrastructure intended for production. Compare record counts for each entity type, spot-check order totals and tax lines, and check that customer logins work through the agreed authentication method. Run performance and load checks on the hosting stack, including the database, caching and search services that the target platform requires. Record every defect, its fix and the retest result. The run is complete when two consecutive test migrations produce matching counts and no open high-severity defects remain.
Test security, backups and rollback
Before cutover, review access to the admin interfaces, API keys and OAuth credentials, and confirm that old PrestaShop access keys are revoked once they are no longer needed. Verify that backups of both the source and target databases are restorable and that the team has written a rollback procedure with named owners. Run a security test against the new environment, including the storefront, checkout and APIs, so that issues surface before real customer data moves. The step closes with a signed-off checklist that shows backups restored in a test, rollback steps rehearsed and access reviewed.
Cut over and confirm post-launch checks
Schedule the cutover with the merchant, freeze catalog and order changes on the source for the agreed window, run the final incremental data sync, and switch DNS or routing to the new shop. Watch order flow, payment callbacks, error logs and search indexing against the checklist written earlier. Keep the source shop available in read-only form until the business confirms that orders, refunds and reports are correct. The migration is finished when the post-launch checklist is complete, the source is archived, and the handover documents list who now maintains each integration.
Where Shopware and PrestaShop projects usually run long
Most delays on either platform come from work that looks small at the start: the environment, the theme and module layer, and the data migration. Before a team commits to either platform, it should ask for a written scope that covers each of these items separately, because the effort behind them differs sharply between a shop with a few hundred products and one with years of order history, custom attributes and multiple storefronts. On both platforms, the first decisions are the hosting stack, the database version and the PHP runtime, since these determine which extensions and payment connectors can be installed without rework. PrestaShop 9 documents MySQL 5.7 or MariaDB 10.2 as its minimum, Apache 2.4 or later with Nginx also working, and a memory_limit of at least 512M, so teams should confirm those values against their own image and host before any build starts.
Payment and tax integration, performance tuning and upgrades are where projects most often run long after launch. Tax rules, payment providers and shipping carriers each need a tested path from checkout to accounting, and that testing has to be repeated whenever a connector or a core version changes. Extension compatibility is the most common slip: a module that works on one maintained line may need replacement or rework on another, so teams should list every paid and custom extension, record its vendor, and confirm its support status for the version they plan to run. Shopware's paid plans add a second planning variable, because a shop that grows past 1 million euros in gross merchandise value over the preceding 365 days must move off the free Community Edition, and projects that forecast GMV loosely often discover the plan requirement mid-build. Ask for a sensitivity range for GMV in the scope, not a single forecast.
DeployOpen scopes this work in writing before any implementation starts, so environment setup, theme and module customization, data migration, payment and tax integration, performance testing and the upgrade plan each appear as named deliverables with agreed acceptance criteria. That document is also the place to record assumptions that drive cost, such as the hosting target, the number of storefronts and integrations, and the GMV band the shop expects to occupy. Teams comparing the two platforms should ask any implementation partner to price each of these items separately, so the difference between platforms shows up in the right line of the quote rather than being hidden in a single total.
Questions buyers ask before choosing Shopware or PrestaShop
What drives the cost of running Shopware versus PrestaShop?
Cost follows the license model, the hosting you choose and the people you pay to build and operate the shop. Shopware's Community Edition is free under the MIT License, but 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 says plan pricing is based on gross merchandise value and other individual factors, so ask for a written quote for your volume. PrestaShop Core is licensed under OSL-3.0 with no revenue cap in the supplied facts, so license cost is usually not the main line item. Recurring costs on both sides include hosting, PHP and database operations, security patching, module licenses and developer time for upgrades. Ask any implementation partner to price these components separately in the written scope.
How long does a Shopware or PrestaShop implementation take?
No single duration applies to both platforms, because the timeline depends on scope, integrations and how much the shop differs from the default product. The main drivers are the number of payment, shipping, ERP and tax integrations, custom theme and checkout work, data migration from an existing shop, and the approval steps your team requires. A shop that uses standard catalog, checkout and payments needs far less time than one with B2B quotes, multi-shop structures and custom APIs. DeployOpen does not publish durations, and most engagements are fixed-scope with timelines agreed in writing before work starts. Ask for a phased plan with a discovery stage that lists integrations and data volumes before accepting any date.
What does the work need from our own team?
The work needs a named business owner, a technical owner who can approve architecture and hosting decisions, and access to the people who run your payments, catalog, ERP and identity systems. Engineers should expect to review the hosting stack, database and PHP settings, and the process for backups and upgrades. Compliance or security staff should be available to define access control, logging and evidence requirements. Your team also needs to decide who owns content, product data and merchandising rules after launch. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, so confirm in the scope which tasks stay with your staff.
Can an in-house PHP team run Shopware or PrestaShop without outside help?
An in-house PHP team can run either platform, but the workload is more than installing software. PrestaShop 9 requires MySQL 5.7 or MariaDB 10.2 minimum, Apache 2.4 or later (Nginx also works) and a memory_limit of at least 512M, and the documentation says it works best on Unix-based systems. Shopware runs as SaaS, PaaS or self-hosted, so the choice of hosting decides how much operations work your team owns. Self-hosting means your engineers handle server patching, database tuning, backups, PHP version changes and each major upgrade. Check whether your team has done ecommerce upgrades before, and whether it can cover on-call hours for checkout outages.
Is the Shopware Community Edition enough if our GMV is below 1 million euros?
The Community Edition can be enough below the threshold, provided your shop stays under 1 million euros in gross merchandise value over the preceding 365 days. The Community Edition includes a visual page builder, product management and Shopware Payments, but the pricing page says it comes with community support only. If you need paid response times, B2B quotes and approvals, or a managed hosting arrangement, the paid plans are the relevant comparison. Watch your trajectory as well as today's figure, since the rule applies once sales cross the threshold. Confirm with Shopware how the 365-day calculation is applied to your account and which features you would lose or gain on a change of plan.
Which PrestaShop line should we choose, 9.x or 8.x?
Choose the 9.x line for a new build because it is the current major line and includes the Admin API built on API Platform with OAuth2 authentication, multi-shop support and Swagger documentation. The 8.x line still receives releases, with 8.2.8 published on August 18, 2026, so an existing 8.x shop does not need to move immediately. Check the PrestaShop 9 system requirements against your hosting, and test every third-party module on 9.x before committing, since module compatibility determines the upgrade effort. Also confirm the support window you need, because the supplied facts show release dates but do not set an end-of-life date for either line.
How do we confirm extension and API support before signing a contract?
Ask for evidence from the vendor documentation and from a proof of concept in your own environment. For PrestaShop, the webservice gives third-party tools CRUD access to products, orders and customers using access keys, and PrestaShop 9 adds an Admin API with OAuth2. For Shopware, confirm the API endpoints, authentication method and plugin list your integrations need, and check the plan that includes them. Make a list of every integration, including payments, shipping, ERP, tax and identity, then test each one against the exact version you will run. Put the tested items, the owner of each module license and any module that needs custom code into the written scope before signing.
How DeployOpen helps choose, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates and hardens self-hosted open-source platforms inside the client's own infrastructure. For Shopware vs PrestaShop, we start from your licensing position, hosting stack and upgrade appetite, then build and document the platform you choose.
How we scope
- We confirm the annual gross merchandise value your shops generate before choosing an edition path.
- We map which PHP version, database and hosting model your team can operate for the platform you select.
- We agree deliverables, timelines and responsibilities in writing before any build work starts.
- We define which API surfaces your integrations need, such as PrestaShop's webservice or Admin API.
How we build
- We install the platform in your cloud account, data center or air-gapped network, not in ours.
- We configure payments, product data, integrations and custom modules against the scope you signed off.
- We test checkout, order flows and API access with security testing before go-live.
- We document configuration, module choices and upgrade steps so your team can maintain the shop.
How we hand over
- We deliver runbooks covering installation, backups, updates and rollback for your chosen version line.
- We transfer administrative access, secrets handling and license records to named owners in your organization.
- We walk your engineers through custom extensions and the paths your team will own after handover.
- We provide written documentation of the architecture and the decisions behind each platform choice.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover moving between maintained minor lines when your platform vendor publishes new releases.
- We can run scheduled security testing of your storefront, APIs and integrations as part of ongoing work.
- Ask us to confirm support windows and paid-edition requirements for your chosen platform before signing.
