How do I update my Shopware 6 store safely?

An update button tells you little about the work your installation needs. The starting version, target release, hosting and extensions matter. Shopware’s update guide recommends a test environment, a backup and checks of extension compatibility. The technical procedure depends on the specific version transition.

For Shopware SaaS, the provider updates the store according to its FAQ. The merchant’s focus is therefore more on checking business processes and connected services. The self-hosted update plan below cannot be transferred unchanged to SaaS.

We start with a brief inventory: Shopware version, hosting model, theme, extensions and custom development. Connecting these components to business processes is particularly useful. Which plugin calculates customer prices? Which application transfers orders? Who maintains the ERP connection?

• Target version and requirements: Check release notes and the server environment required for this particular transition.
• Extensions and theme: Confirm compatibility and assign responsibility for outstanding changes.
• Test environment: Prepare a suitable copy and prevent real payments, customer emails and writes to the production ERP.
• Backup and recovery: Back up the database, files and configuration together, and test the recovery procedure.
• Acceptance tests: Define representative orders, payment methods, shipping rules and integration checks in advance.
• Deployment: Agree on the maintenance window, approval, stop conditions and handling of orders created in the meantime.

A positive compatibility indication does not replace testing your individual combination. Shopware’s version upgrade guidance is particularly relevant to custom extensions: changes to technical interfaces can require adaptations. We would clarify these tasks before the live deployment, rather than during a maintenance window that has already begun.

Opening the homepage and adding a product to the basket is not enough. The test must reach the outcome your business depends on. For a test order, we therefore also check payment status, shipping charges, confirmation and the intended transfer to the ERP. Business customers may additionally require specific prices or payment terms.

Consider a simplified example, not a documented client case: a merchant updates Shopware and its payment extension. A test order appears in the store, but the ERP does not import it because the integration expects a particular payment status. The store initially looks functional. Only testing the entire order flow reveals the gap. Configuration, an extension or a mapping rule could be responsible; without investigation, any of those explanations would be a guess.

We would first trace one order using its identifier. What state exists in the store, what was transmitted, and how does the ERP process the message? We then correct the relevant component. The same questions apply to Odoo and other ERP systems. As an Odoo Partner, we include downstream operations in the discussion instead of approving only the storefront. Our article on ERP and inventory management for online stores explains the broader division of responsibilities.

A backup is necessary, but restoring it after new sales can overwrite orders, payment statuses or other changes. Before deployment, agree when order acceptance and background processes will pause and how they will resume. Incoming payment notifications and orders already transferred to the ERP also need to be considered.

At sjmedia, we would define a clearly documented backup point and name the person responsible for deciding on a rollback. The affected transactions are reconciled after operations resume. Advice to “just restore the backup if anything goes wrong” is inadequate for a trading store. A fixed downtime commitment would not be credible without understanding the installation.

Estimating effort requires more than a version number. A maintained store with compatible extensions needs different work from an installation with several skipped releases, custom development and unclear integration responsibilities. The proposal should distinguish assessment, technical changes, testing, deployment and follow-up checks. Our Shopware cost guide covers the broader running costs.

If Shopware suits your processes, maintaining it can be the sensible choice. Repeatedly expensive workarounds, however, justify reviewing the platform decision. PrestaShop is an important alternative in our assessments where the required workflows can be implemented transparently and economically. PrestaShop also needs maintenance, compatible modules and testing. The fact that an update requires work is not sufficient reason to migrate. Our PrestaShop and Shopware comparison supports that wider decision.

A useful starting point is the current version, an extension list, hosting details and a short description of the most important order workflows. Include known faults and custom development. We can then clarify the checks needed before a reliable proposal and agree who will approve the business processes.

Our Shopware services connect that assessment with technical implementation. A specific maintenance or update engagement should deliver more than a new version number: tested workflows, documented changes and clearly identified open issues. Those are the practical criteria for deciding whether the update is complete for your business.