Shopware updates
Shopware 6.7 is the current major line; 6.7.0.0 appeared on 17 June 2025, and the current state of the line is 6.7.13.0 of 5 August 2026. The jump from 6.6 to 6.7 is technically the largest since Shopware 6 started: Vue 3 instead of Vue 2, Vite instead of Webpack, Pinia instead of Vuex. An update to 6.7 is therefore not a maintenance task but a project with a beginning and an end — with a plugin inventory, a staging run, a test list for the checkout process and a way back that is defined in advance. Sharpness Solutions GmbH in Oldenburg runs such updates on self-hosted shops, including shops that someone else built. This page was last updated on 17 August 2026.
Enquiries about Shopware updates rarely come from an interest in new features. They come because an extension is only maintained for 6.7 any more, because the host is raising the PHP version, because an audit is running — or because a first update attempt ended in an empty administration. The four starting points below cover most of what shop operators bring to us. They have one thing in common: the effort is not in the update itself, but in everything attached to it.
The effort depends on five factors. You can count four of them yourself: the number of store extensions, the number of your own plugins with files under src/Resources/app/administration/, the scope of the custom theme measured in overridden Twig blocks, and the number of connected systems. The fifth factor is the state of the code, and that can only be read, not counted.
After the jump to 6.7 the administration no longer loads, or individual modules are missing without an error message. The cause is almost always an extension that is still built against Vue 2, Vuex or Webpack. The PHP log says little about it, because the break happens in the build of the administration and not at run time.
Then this is not about an update. Shopware 5 has been out of vendor maintenance since the end of July 2024, and the way to 6.7 is a new build with data transfer: a new theme, new extensions, newly connected interfaces, a complete redirect list. That is calculated as a project, not as a version jump.
Updates run through the updater in the administration, a backup exists, but nobody has ever restored it. That makes every update a test in live operation. We close this gap before the version jump, not after it — it also makes every following patch level cheaper.
Shopware counts with four numbers. In 6.7.13.0 the first two positions denote the major line, the third the minor release and the fourth the patch level. According to the release policy, minor releases appear on the first Monday of the month and bring features, bug fixes and security fixes; patch releases come in between when a fault requires it. Shopware does not state a rhythm for major releases: 6.7 appeared in June 2025, and 6.8 is only expected for 2027. Breaking changes come with the major version. The risk assessment follows from this classification, and it is anything but symmetrical. A patch level is an operational task, a major jump is a project. Anyone who treats both the same either makes one of them too costly or the other too careless.
With patch and minor levels within 6.7 the risk is limited, but not zero. What is affected is code that depends on internal APIs instead of the documented extension points, and templates that point to markup that has changed. A practical rule from operation: do not install new x.x.x.0 releases immediately. Shopware withdrew 6.7.12.0 shortly after publication — according to the release notes this version cannot be installed or used for an update because of a fault discovered afterwards, and 6.7.12.1 should be used instead. Anyone who moves a month later avoids this class of surprise.
With the major jump from 6.6 to 6.7, not only the code changes but also the underlying stack. As minimum requirements for 6.7, Shopware names PHP 8.2, 8.3 or 8.4, Node.js from version 20 for the administration build, MySQL from 8.0.17 or MariaDB from 10.11, and Redis from 7.0 if it is in use. The documentation explicitly names problematic intermediate versions: MySQL 8.0.20 and 8.0.21, MariaDB 10.11.5 and 11.0.3. These are minimum values and not recommendations — for operation, the hosting guide lists a newer stack. Anyone who is on PHP 8.1 or MariaDB 10.6 today has two projects and not one — and the order is fixed: first the stack, then the application.
The administration of Shopware 6 is a Vue application, not a set of form pages. An extension there does not call a stable interface but becomes part of this application: it overrides Twig blocks of the administration templates, registers or extends components via Component.register() and Component.override(), brings its own entry point under src/Resources/app/administration/ and is compiled into the same build as the core. This is exactly where the effort of 6.7 comes from: when the application moves from Vue 2 to Vue 3, the contract with every plugin that hooked into it changes as well.
Three rebuilds take effect at the same time. First, the Vue 2 compatibility layer has been removed; components have to run against Vue 3. Second, Pinia replaces the state management Vuex — Shopware.State.get() becomes Shopware.Store.get(), and your own stores are registered again in a new way. Third, the administration builds with Vite instead of Webpack; your own webpack.config.js becomes a vite.config.js. Webpack and Vite are not cross-compatible: anyone who maintains a plugin for both lines needs separate releases for 6.6 and 6.7. As a rule of thumb for the inventory, a look at the directory is enough — every extension with files under src/Resources/app/administration/ is affected.
On the PHP side and in the storefront, the second block is added. 6.7 raises DBAL to 4, PHPUnit to 11, Dompdf to 3 and league/oauth2-server to 9, and moves the Symfony components up to 7.3; the jump to Symfony 7 itself was already made by 6.6, so it is no longer pending. The payment handlers have been merged into a single AbstractPaymentHandler class, the Store API route caching including all Cached*Route classes has been removed, delayed cache invalidation is active by default and the former configuration shopware.cache.invalidation.delay has been dropped. For payment and shipping methods, technicalName is mandatory, and custom field names with a hyphen or a dot are no longer accepted: field and field set names have to be valid Twig variable names. In the storefront, the header and footer load via ESI so that they can be cached independently, and the accessibility rebuild has changed markup, ARIA attributes and block structure. What was still behind the feature flag ACCESSIBILITY_TWEAKS in 6.6 is standard in 6.7 — pagination runs through anchor links instead of radio inputs, and icons from the icon helper carry aria-hidden. A custom theme is therefore affected just as much as a plugin: every overridden Twig block has to be read against the new original, because otherwise it quietly brings back an old structure.
With third-party extensions the situation is now better than it was shortly after the release. At the beginning of 2026 the large store plugins have compatible versions for 6.7 — in the first months this was different, and a good part of the fear of updating comes from that. Today the bottleneck is the custom-built extensions and the small ones without a maintainer. Shopware itself provides a first overview: under Settings, System, Shopware Updates, each active extension is shown in one of three states. This list is a start and not an approval — it does not know your own code and says nothing at all about templates.
There is no update path from Shopware 5 to Shopware 6, only a new build with data transfer. Shopware 6 is a different system: Twig instead of Smarty, a different data model, a different plugin architecture. Data is transferred — products, variants, categories, customers, orders, media, custom fields, SEO URLs — through the Shopware Migration Assistant. Theme, extensions and interfaces are created anew. Instead of a plugin update, this is a plugin replacement: for every function you decide whether a 6.7 extension covers it, whether it is rebuilt, or whether it is dropped because nobody used it anyway.
Two things follow from this for the planning. First, the target version is the current 6.7 level directly. An intermediate step via 6.6 brings nothing, because everything is rebuilt anyway, and it would only plan the rebuild to Vue 3, Vite and Pinia in order to repeat it later. Second, the date is not open-ended: Shopware 5 has been out of vendor maintenance since the end of July 2024, and anyone who cannot meet the date buys time with the paid safefive patches — that postpones the migration, it does not replace it. On switch-over day the redirect list then decides: the SEO URLs from Shopware 5 can be carried over, but the URL structure of Shopware 6 is a different one, and without complete redirects you lose visibility that has been built up over years. We generate the list from the existing data and check it before the cutover; there are no ranking promises attached to it, neither from us nor from anyone else.
A migration is therefore calculated differently from an update. For an update you count extensions, administration components and overridden Twig blocks and calculate the adjustment effort per item. For a migration you calculate a new build, plus data transfer, reconciliation and redirects — and for every function you decide again whether it comes along at all. Anyone who puts both in one pot gets a figure that is right for neither case. Our page on Shopware help describes the migration path in detail — Migration Assistant, mappings, data reconciliation, cutover. This page is about the path within Shopware 6.
It starts with a staging copy holding real data. Real catalogue and order data is necessary because faults in price logic, tax rates, discount rules and order documents do not show up with test articles. Four things are disconnected before the first page is loaded: mail delivery, so that nobody receives order confirmations from the test system; the payment providers, which are switched to sandbox accounts; the ERP interface, which is pointed at a test tenant; and indexing by search engines. Personal customer data is pseudonymised, or the system runs closed to the public — a staging instance with real customer data and open access is a data protection incident waiting to happen.
Updating is done from the command line, not through the updater in the browser. The documented path runs in two halves: locally, set the target version in the composer.json, then run composer update --no-scripts and composer recipes:update, then commit and deploy. On the server, sales-channel:maintenance:enable --all, system:update:prepare, system:update:finish follow, and at the end sales-channel:maintenance:disable --all. After that comes the follow-up work that is easily forgotten: the build of the administration, theme:compile, dal:refresh:index, es:index if the search is active, and cache warm-up. Shopware explicitly recommends the updater in the administration only for small instances, because it runs in the browser and hits timeouts and memory limits in larger shops. The path via the repository has the further advantage that the same change is carried out twice in an identical way: first on staging, then live.
The test list is written before the staging run and ticked off afterwards, not the other way round. It contains at least: a complete order with every active payment method, every shipping method, a voucher, a graduated price, a customer group price, net and gross display with every tax rate in use, invoice and delivery note as PDF, the order export to the ERP, the stock feedback, registration, password reset, mail delivery and each sales channel individually if there are several. The maintenance window lies outside selling hours. Which hour is the weakest in your shop is in your own analytics and not in a rule of thumb.
The way back belongs in the plan before the switch-over — with an abort criterion that is named in advance, and not with a feeling at three in the morning. With a blue-green deployment it is possible, according to Shopware, to switch back to the old environment without restoring a backup; however, this is only recommended if only Shopware and not the extensions were updated at the same time. The honest limit behind this: database migrations only run forwards. Anyone who goes back to the dump after the switch-over loses the orders that came in during that time. That is exactly why the window is short, lies in the weakest selling hour and starts with a backup of the database and the files that was taken immediately beforehand.
Three failures occur repeatedly after unsupported updates to 6.7, and all three are inconspicuous. First, a payment method stops working: the handler has not been moved to AbstractPaymentHandler or the technicalName is missing, the method disappears from the checkout, and otherwise the shop runs normally. Second, the price logic calculates incorrectly: an extension that intervenes in discount or price calculation is no longer applied, the order goes through — with the wrong amount. This is the most expensive case, because it can go unnoticed for weeks. Third, the ERP interface goes silent: a renamed custom field or a removed endpoint no longer fits, and it only becomes apparent when the goods do not go out.
This is why monitoring that measures more than availability belongs to the period after the go-live. Four values are useful, compared with the week before: the number of completed orders, the error rate in the log, the number of orders without a receipt from the ERP and the duration of an indexing run. Anyone who only checks whether the home page responds is monitoring the value that fails last in the event of a fault.
For planning, 6.8 is the next marker: expected for 2027, without a fixed date. Shopware ties the support transitions to major releases instead of calendar dates and has four states — Maintained, Extended Support, Security fixes only, End of life. With the release of 6.7, 6.6 moved into extended support and stays there until 6.8 appears; this state was designed to last one year, and with the postponement of 6.8 to 2027 Shopware has extended it. In extended support, the last minor of the line receives selected bug fixes and security updates as a patch, and older minors receive security fixes through the security plugin, and according to Shopware a further year of security updates through this plugin follows after that. In practical terms this means: anyone who moves to 6.7 now has the Vue 3, Vite and Pinia rebuild behind them when 6.8 arrives. That 6.8 will be the smaller jump for extensions is a well-founded expectation and not a promise from Shopware.
There is a case in which we advise against an update. If the shop is going to be replaced or rebuilt in the foreseeable future anyway, the 6.7 rebuild is money spent twice — the adjusted plugins and templates end up in the bin of the new build. In that case 6.6 in extended support, with a binding date for the new build, is the cheaper answer. If a project does not add up, we say so before the quotation and not after it.
Process
Send us the version and patch level and the output of bin/console plugin:list, or a screenshot from Settings, System, Shopware Updates. You will receive a written assessment with the target version, a list of risks, an effort range and a proposal for the maintenance window — even if you then hire someone else. Sharpness Solutions GmbH, Edewechter Landstrasse 161, 26131 Oldenburg. Telephone 0441 21 21 63 0, Monday to Friday 9:00 to 16:00, info@sharpness.de.
We review the version and patch level, composer.json and composer.lock, the plugin and app list with its origin — store, in-house development, previous agency — the files under src/Resources/app/administration/, the custom theme with its overridden blocks, the connected systems and the PHP, database and Node versions. If the repository is missing, we reconstruct the current state from the server.
Every extension is assessed individually: is there a 6.7 version, is an adjustment needed, is there a replacement, or will it be switched off? We check store extensions against the store and the Shopware account, and our own against the code. Extensions that nobody uses any more are removed at this point — it is the cheapest part of the project and the most frequently skipped.
Before the first line of code comes the result: target version, order of the steps, list of the extensions with the effort per item, a named maintenance window and the points that can only be decided on the test system. For clearly defined parts there is a fixed price, for the rest an estimate by work package.
We mirror the database and the files into a staging environment, disconnect mail delivery, switch payment to sandbox and the ERP to a test tenant, and pseudonymise customer data. If no staging environment exists, we set one up. After that, the first full run takes place from the command line, including the administration build, theme:compile and an indexing run. Whatever breaks, breaks here.
Adjusting your own plugins and templates is the longest block: Vue 3, Pinia instead of Vuex, Vite instead of Webpack, payment handlers, custom field names, overridden Twig blocks against the new original. In parallel, you test on the staging system against the test list. Approval is given in writing, item by item.
The go-live takes place in the agreed window outside selling hours, with a backup taken immediately beforehand, maintenance mode per sales channel and a defined abort criterion. After that comes closer monitoring of the four figures, the follow-up work from the acceptance, and the handover of the documentation. Finally, the question of who will install the monthly minor and patch levels in future: you or us, through an SLA.
Projects on this system
A selection — not the full client list.
The shop is only offline during the maintenance window at the switch-over, not during the project: the work takes place on a staging copy, and the live shop keeps selling unchanged. In the window itself, the sales channels go into maintenance mode via sales-channel:maintenance:enable --all, then system:update:prepare and system:update:finish run, followed by the builds for the administration and the theme and the indexing run. How long that takes depends on the volume of catalogue and order data and is known after the staging run, because we measure it there. A figure given before that would be a guess.
Before a major jump we always install the last minor of the 6.6 line with the current patch level first, that is 6.6.10.x. There are two reasons: Shopware actively maintains the last minor of a line, and anyone who makes two jumps at the same time cannot tell afterwards which of them broke something. The chain therefore runs in steps, each with its own functional test on staging.
An update from 6.6 to 6.7 is calculated by time and effort. Five factors determine the effort: the number of store extensions, the number of your own plugins with administration components, the scope of the custom theme in overridden Twig blocks, the number of connected systems and the state of the code. You can count the first four yourself; the fifth has to be read by someone from outside. After the plugin inventory there is a fixed price for the clearly defined parts and an estimate for the rest. A price list would calculate an average that you pay for.
Because the administration of Shopware 6 is a Vue application and an extension there does not call an interface but becomes part of the application: it overrides Twig blocks, extends components via Component.override() and is compiled into the same build. In 6.7 the Vue 2 compatibility layer has been removed, Pinia has replaced Vuex and Vite has replaced Webpack. This changes the contract with every plugin. The rule of thumb for the inventory: every extension with files under src/Resources/app/administration/ is affected.
Shopware itself gives a first overview: under Settings, System, Shopware Updates, each active extension is shown in one of three states — already compatible, compatible with the new Shopware version, or not compatible because no successor version exists. The store and the Shopware account under Licences provide the same information. The list does not know your own code and says nothing about templates. At the beginning of 2026 the large store plugins have compatible versions; the bottleneck is the custom-built ones and the small ones without a maintainer.
For small instances it is acceptable, for larger ones it is not — Shopware explicitly recommends it only for small shops, because it runs in the browser and there hits timeouts, memory limits and other resource limits. The reliable path runs via composer and bin/console: composer update --no-scripts and composer recipes:update locally, then system:update:prepare and system:update:finish on the server. The second reason is the more important one: via the repository, the same change is carried out twice in an identical way, first on staging, then live.
An individual theme does not survive the jump to 6.7 unchanged. The effort does not scale with the appearance but with the number of overridden Twig blocks: each of them has to be read against the new original, because otherwise it quietly brings back an old structure. Added to this are two changes that affect every theme: the header and footer load via ESI, and the accessibility rebuild of the storefront has become standard in 6.7 — it has changed markup, ARIA attributes and block structure, for example the pagination from radio inputs to anchor links. Themes with few overridden blocks therefore get through cheaply.
With the release of 6.7, Shopware 6.6 moved into extended support and stays there until 6.8 appears — expected for 2027, without a fixed date. This state was originally designed to last one year; with the postponement of 6.8 to 2027, Shopware has extended it. Shopware has four states: Maintained, Extended Support, Security fixes only, End of life, and ties the transitions to major releases instead of to calendar dates. In extended support, the last minor of the line — for 6.6 that is 6.6.10.x — receives selected bug fixes and security updates as a patch, and older minors receive security fixes through the security plugin; according to Shopware, a further year of security updates through this plugin follows after that.
No, there is no update path from Shopware 5 to Shopware 6. The change is a new build with data transfer: Twig instead of Smarty, a different data model, a different plugin architecture. The theme and the extensions are created anew, the interfaces are connected again, and the data comes along through the Shopware Migration Assistant. The target version is the current 6.7 level directly; an intermediate step via 6.6 brings nothing, because everything is rebuilt anyway. Our page on Shopware help describes the migration path in detail.
Yes, an update within Shopware 6 leaves data and URLs untouched: orders, customers, products, media and SEO URLs remain, and the database is migrated rather than replaced. Two points still need attention. 6.7 no longer accepts custom field names with a hyphen or a dot — they have to be valid Twig variable names, so they must be renamed and carried through in all templates and interfaces. And the order documents should be checked individually after the update, because Dompdf has moved to version 3 and layouts can shift.
There is a way back, and it has a limit. With a blue-green deployment it is possible, according to Shopware, to switch back to the old environment without restoring a backup; however, this is only recommended if only Shopware and not the extensions were updated at the same time. The limit: database migrations only run forwards. Anyone who goes back to the dump after the switch-over loses the orders that came in during that time. That is why the window lies in the weakest selling hour, is short, starts with a fresh backup and has an abort criterion that is defined in writing beforehand.
In most cases it makes no sense to wait for 6.8: 6.8 is expected for 2027, Shopware does not state a date, and the rebuild to Vue 3, Vite and Pinia is still due — just later and together with the changes of 6.8. Anyone who moves to 6.7 today has it behind them. There is one exception on the other side: if the shop is going to be rebuilt or replaced in the foreseeable future anyway, the update is wasted money. In that case 6.6 in extended support, with a fixed date for the new build, is the cheaper answer.
Yes, with update enquiries that is the normal case. We need shell or SFTP access, database access, an administrator account in the back end, the Git repository and the Shopware account with the licences of the paid store extensions. If the repository is missing, we reconstruct the current state from the server; that effort belongs in the estimate. The licences are the point where projects actually get stuck: if they are in the account of the old agency, paid extensions cannot be updated, and that is not a technical problem but an organisational one.
No, an update is a project with a beginning and an end and is commissioned as such. The question of a contract arises afterwards: who installs the monthly minor and patch levels? If we take that on, it runs through a service level agreement with four tiers — BASIC 24 hours, STANDARD 8 hours, ADVANCED 4 hours, PREMIUM 2 hours response time, each as a monthly flat fee net per shop. Without an agreement, processing takes place in order of receipt within 48 hours during our business hours, Monday to Friday 9:00 to 16:00.
Enquiry
Send us the version, the patch level and the plugin list. You will receive a written assessment: target version, which extensions are in the way, an effort range and a maintenance window — before the quotation, not after it.