In short: A store that has not seen updates for two years is not saved effort - it is a postponed emergency project with an unknown price tag. The 2026 release reality shows why: security fixes, legally required features like the withdrawal button and new channels like agentic commerce all arrive through regular updates. Update monthly in small steps and you get all of this on the side. Jump versions and you pay for everything at once - plus risk.
What happened between April and June 2026 alone
Three monthly releases, three examples of why your version level is not cosmetic:
- 6.7.9.0 (April): the native withdrawal button - legally mandatory for B2C shops selling to Germany from June 19, 2026. Those who were current set up a form. Those sitting on an old version suddenly had a legal project with a deadline.
- 6.7.10.0 (May): roughly 117 resolved issues in checkout, search and product listings - plus the new Agentic Commerce sales channel for AI product feeds.
- 6.7.11.0 (June): a new storefront component system, a Vite dev server, and a set of deprecations plugin developers should clear promptly.
That is the normal rhythm: every month a mix of security, stability, compliance topics and new capabilities. Postponing updates means giving up all four at the same time.
Why the big jump is so expensive
The classic pattern I see regularly in projects: "We'll do nothing for now, the shop is running." Two years later, something forces action - a security vulnerability, a PHP version discontinued by the hoster, a plugin that is no longer supported, or a feature the business needs. Then everything comes together:
- Plugin compatibility: A dozen plugins must be updated simultaneously - some with breaking changes, some no longer exist, some no longer have a vendor.
- Theme and templates: Two years of core template changes to catch up on at once, including renamed blocks and changed structures.
- PHP and database versions: The jump often forces a new PHP version, a new MySQL/MariaDB version and adjusted server configuration at the same time.
- Elasticsearch/OpenSearch: Search infrastructure that matched the old version has to be migrated along.
- Feeds and integrations: Product exports, Google Merchant Center, ERP connections - everything that ran silently must be retested.
Each of these points is manageable on its own. All of them together, under time pressure, in a live store with running revenue - that is the most expensive constellation in Shopware operations.
The math: small and regular vs. big and rare
Regular maintenance costs a plannable few hours per month: apply the update (tested on staging), check plugins, test, go live, observe briefly. The change set per step is small, error sources are quickly narrowed down, rollbacks are trivial.
The version jump after two years almost always costs a multiple - not because the individual steps are more expensive, but because diagnosis under uncertainty is added: if something breaks after jumping across 20+ releases, the cause can be anywhere. With a monthly update there is exactly one release to suspect.
Add the invisible risk: security holes in unpatched shops are not a theoretical problem, and a compromised shop costs more than any maintenance retainer - in revenue, in data, in trust.
What sensible Shopware maintenance looks like in 2026
From my project practice, this rhythm has proven itself:
- Monthly: Apply patch updates (tested on staging), review plugin updates, check security advisories.
- Quarterly: Clear deprecations in your own code, check PHP/database versions against the roadmap, review performance metrics.
- Yearly: Plan larger version steps, take plugin inventory (what is still needed?), review infrastructure.
That is exactly what my Shopware administration packages cover - starting at 897 € per month, plannable instead of firefighting. And if your store is already far behind: the controlled catch-up jump is doable too, it just needs an honest analysis first instead of optimism. I tell you transparently what it costs - see my pricing.
The best time for regular maintenance was two years ago. The second best is before the next mandatory feature with a deadline.