Shopware 6.8 announced for 2027: prepare the upgrade now

In November 2025, Shopware announced that the next major version 6.8 is planned for 2027 instead of 2026 (Shopware). For operators of a Community Edition shop with custom plugins, that sounds like a postponement, but above all it is a window of time: a good part of the breaking changes that 6.8 brings are already announced, marked as deprecated and described in a draft of the upgrade guide. Using the time until the major version spreads the work across many small steps instead of squeezing it into a few weeks before the upgrade. This article puts the support windows of 6.6 and 6.7 into context, shows what the end of Symfony configuration in XML means for custom plugins, how the sharpened labelling of deprecations makes the inventory easier and in which order the upgrade can be prepared – without naming dates that Shopware itself has not yet published.

What Shopware has announced for 6.8

The announcement is brief: Shopware has adjusted its release schedule, and the next major version 6.8 is now planned for 2027 instead of 2026 (Shopware, Update on the Shopware roadmap). The announcement does not name a quarter or a month, and Shopware has not published a more precise date elsewhere either. Anything beyond the year would therefore be an estimate. For planning a shop, the year is still a useful figure: between today and the release of the major version lies a period in which plugins, configuration and runtime environment can be prepared step by step without affecting day-to-day operations. What matters is to treat this period as working time rather than waiting time.

In the same announcement, Shopware extended the Extended Support for 6.6: according to Shopware, it remains active until 6.8 is available (Shopware). That is a link to an event, not a calendar date. This is the most important change compared with earlier statements: according to the Release Policy, support transitions are tied to major releases, not to fixed timelines (Shopware Release Policy). Anyone planning with a fixed end date for 6.6 is therefore planning with a figure that does not exist in this form. Only the sequence is reliable: first 6.8 is released, then the status of the older lines changes. For budget planning that is inconvenient, but for technical preparation it helps, because the focus shifts from dates to prerequisites.

We’ve adjusted our release schedule: the next major Shopware version, 6.8, is now planned for 2027 instead of 2026.

Shopware, Update on the Shopware roadmap (November 2025)

When exactly the major version arrives can at least be narrowed down by another rule once the time comes: each major version is preceded by a release candidate, typically approximately two months before the planned major release (Shopware Release Policy). The Release Policy itself qualifies this: depending on feedback from the community, the RC phase might be prolonged (Shopware Release Policy). The release candidate is therefore the first reliable signal for the final phase, but not a date on which a go-live can be pinned. For the preparation this leads to a simple rule: the work that is possible without a release candidate should be done beforehand, so that the RC phase remains available for testing rather than for rework.

Support windows: what the end of 6.6 and 6.7 depends on

The Release Policy describes the transition in one sentence: the last minor version of a major version enters Extended Support once the next major version is released (Shopware Release Policy). For the 6.7 line this means: as long as 6.8 has not been released, 6.7 remains the current line with regular minor versions. Only with 6.8 does the last 6.7 minor move into Extended Support. Shopware does not name a separate duration for this phase for 6.7, and the Release Policy explicitly states that the transitions depend on major releases and not on fixed timelines (Shopware Release Policy). Anyone setting up a budget plan is therefore better off working with events than with months: with the release of the release candidate, with the release of 6.8 and with their own upgrade window afterwards.

The previous round shows what the transition looks like in practice: with the stable version 6.7.0.0, Extended Support for the 6.5 line ended (Shopware release notes 6.7.0.0). The 6.6 line, by contrast, is still maintained; according to the release notes, 6.6.10.25 of 16 September 2026 is a security release (Shopware release notes 6.6.10.25). The pattern is clear: the status of a line changes with the release of the next major version, not on a fixed date. A shop on 6.6 is therefore not left behind until 6.8 is released. It does, however, run on a line whose extended Extended Support, according to Shopware, only lasts until 6.8 is available. Shopware has not quantified what applies to 6.6 after that, and the earlier commitment to fixed periods is outdated. What this means for shops still running 6.5 today is covered in Shopware 6.5 and the end of security updates.

For self-hosted installations, minor versions are released monthly (Shopware Release Policy). For preparing 6.8 that matters more than it sounds: every minor version of the 6.7 line can bring new deprecations aimed at 6.8. A shop that stays on an early 6.7 minor does not see these notices and only learns at the jump what has accumulated. Regular updates within the line are therefore not an end in themselves but the prerequisite for a complete inventory. How updates can be installed during live operation with little risk to revenue is described in the article on installing Shopware updates and patches safely.

• According to Shopware, there is no end date for 6.6 but a condition: Extended Support runs until 6.8 is available.
• For 6.7 the general rule of the Release Policy applies: the last minor version enters Extended Support once 6.8 is released.
• Fixed support durations from earlier announcements are outdated; the current Release Policy ties transitions to major releases.
• Shops still on 6.6 should sensibly not combine the move to 6.7 with the jump to 6.8 but complete it beforehand – the breaking changes between 6.6 and 6.7 are covered in the article on migrating plugins to Shopware 6.7.
• The monthly minor versions of the 6.7 line are the channel through which new notices about 6.8 arrive.

Symfony configuration in XML ends with 6.8

Since 6.7.14.0, loading Symfony configuration from XML files is deprecated – for Shopware bundles, for plugins and for the project directory config/ of an installation. According to the release notes, this configuration no longer works with Shopware 6.8, because Symfony 8 removes support for XML configuration entirely (Shopware release notes 6.7.14.0). This affects exactly the files many plugins use to describe their services and routes: service definitions, routes and package configuration. Anyone running custom plugins that have grown over years often finds such files in every single plugin, frequently copied from a template and unchanged since. The rework is manageable per file, but across all plugins it is an item that belongs in the plan.

How hard the break is, is described in the draft of the upgrade guide for 6.8 (as of September 2026): plugins that still ship such files are no longer loaded correctly and fail with an exception (GitHub shopware/shopware, UPGRADE-6.8.md). For XML files in the project directory config/ the consequence is quieter, but no less serious: according to the same draft, they are silently no longer loaded. Because this is a draft for an unreleased version, the wording may still change before 6.8. The direction, however, is described in the same way in the release notes and in the draft, and for planning the direction matters more than the exact wording.

• Affected: service definitions such as Resources/config/services.xml and further files following the pattern services*.xml.
• Affected: routes in routes*.xml, for example for custom controllers in the storefront or the administration.
• Affected: package configuration under packages/*/.xml.
• Affected: XML configuration files in the project directory config/ of the installation – according to the draft, they are silently skipped.
• Not affected according to the draft: Shopware-specific XML formats such as config.xml, custom-fields.xml and app manifests.

Taking deprecations seriously: what changed with 6.7.14.0

With 6.7.14.0, Shopware has also sharpened the meaning of a label. According to the release notes, a @deprecated annotation in core code is now consistently an actual deprecation: the functionality will be removed or replaced, and the migration is to be carried out as the annotation describes (Shopware release notes 6.7.14.0). For planned changes to interfaces, Shopware introduces separate BC change attributes, so that announced breaks and genuine deprecations are easier to tell apart. According to the release notes, the same minor version closes 522 issues (Shopware release notes 6.7.14.0) – an indication of how much moves within a line, even without a major version.

The last major version shows that the label has consequences: with 6.6.0.0 in March 2024, all code deprecated for 6.6 was removed (Shopware release notes 6.6.0.0). A deprecation is therefore not a question of style but an announcement with a due date. Ignoring it until the upgrade to the major version means receiving all incompatibilities at once – at the least convenient moment, namely when the upgrade already demands a lot of attention. Working through deprecations with every minor version spreads the same effort across many small, easily testable steps. The difference lies not in the amount of work but in whether it arrives in a plannable way or bundled under time pressure.

A simple distinction helps to classify the hits. Calls that a custom plugin makes against deprecated core code can typically be fixed in the plugin itself. Deprecations in extensions from the Shopware Store lie with the respective vendor; there the question is whether and when a 6.8-compatible version is planned. And deprecations in self-written customisations that reach deep into core processes indicate that the customisation might be solved with built-in features or in a different extension form. Whether an app or a plugin is the right form for this depends on how deeply the customisation has to reach into core processes and where it is to be operated.

PHP and Symfony: two schedules alongside Shopware

With the move to Symfony 7, PHP 8.2 became the minimum version in Shopware 6.6 (Shopware release notes 6.6.0.0). Shopware 6.6.0.0 was tested on PHP 8.2 and 8.3, 6.7.0.0 on PHP 8.2 and 8.4 and 6.7.14.0 on PHP 8.2, 8.4 and 8.5 (Shopware release notes). Tested does not mean the same as supported: the composer.json of 6.7.14.2 allows PHP 8.2, 8.3, 8.4 and 8.5 (GitHub shopware/shopware), and the same range is in the composer.json of 6.6.10.25 (GitHub shopware/shopware). For operation, a tested combination is the safer choice; the permitted range, by contrast, shows what can technically be installed.

On the Symfony side, Shopware 6.7.14.2 pins the FrameworkBundle to the 7.4 line (GitHub shopware/shopware). According to symfony.com, Symfony 7.4 receives security fixes until November 2029 (symfony.com). The 6.7 line therefore sits on a Symfony version with a long security window. With 6.8, Symfony 8 comes into play – this follows from the reason Shopware gives for the end of XML configuration (Shopware release notes 6.7.14.0). Which Symfony 8 version 6.8 requires has not yet been published by Shopware. For comparison: Symfony 8.1 requires PHP 8.4.0 or higher (symfony.com). Deriving a minimum PHP version for 6.8 from this would be an inference, not evidence. Testing plugins on PHP 8.4 or 8.5 now keeps the options open and shows early whether a plugin uses language features that are deprecated in newer PHP versions.

PHP runs on its own schedule, independent of Shopware. After two years of active support, each PHP branch receives two further years of fixes for critical security issues only (php.net). For PHP 8.2, security fixes end on 31 December 2026, and active support already ended on 31 December 2024 (php.net). That is before Shopware 6.8, which is planned for 2027. A shop running on 6.6 or 6.7 with PHP 8.2 today therefore needs the PHP change regardless of the Shopware upgrade. What this cut-off date means for other systems is shown in the article on what the PHP 8.2 end of support means for WordPress.

The table suggests an order that works well in practice: plan the PHP change separately from the Shopware upgrade and bring it forward. Doing both in one step makes it impossible to tell, in case of an error, whether the new Shopware version or the new PHP version is the cause. A shop on 6.7 can switch today to a PHP version that Shopware lists as tested in its release notes and run stably there before 6.8 is even available. According to php.net, PHP 8.4 receives security fixes until 31 December 2028 and PHP 8.5 until 31 December 2029 (php.net) – both branches thus extend beyond the year for which 6.8 has been announced. Which of them 6.8 requires remains open until Shopware publishes it.

Inventory: the compatibility traffic light per plugin

Preparation starts with a list of all extensions that are active in the shop or are due to become active: custom plugins, purchased extensions, themes and customisations in the project directory. Each entry goes into one of three columns. Green means ready: no Symfony configuration in XML, no open deprecation hits, PHP requirements within range. Amber means adapt: the plugin stays but needs rework before the upgrade. Red means replace: the plugin is no longer maintained, the vendor has not named a plan for 6.8, or the function can now be solved more simply with built-in features. The cover image of this article shows such a board as an example with placeholder names.

Searching for file names is a start, not a diagnosis. It finds service definitions and routes named according to the usual patterns; files with different names or configuration included via custom loaders are not captured. Conversely, not every XML file is a problem: config.xml for the plugin settings, custom-fields.xml and app manifests are not affected according to the draft of the upgrade guide (GitHub shopware/shopware, UPGRADE-6.8.md). Treating config.xml as an exclusion criterion wrongly sorts healthy plugins into the amber column. For a reliable classification, each hit calls for a look at the plugin base class and at the places where configuration is loaded.

# Compatibility traffic light per plugin - working state, names are placeholders
CustomPluginB:
  origin: in-house development
  symfony_xml: none              # no services*.xml, routes*.xml, packages/*.xml
  shopware_xml: [config.xml]     # not affected according to the draft upgrade guide
  deprecations: no open hits
  traffic_light: green

IntegrationE:
  origin: in-house development
  symfony_xml: [Resources/config/services.xml, Resources/config/routes.xml]
  deprecations: hits in the log, see work list
  traffic_light: amber
  task: migrate service definitions and routes before the upgrade

PurchasedExtensionG:
  origin: Shopware Store
  symfony_xml: unknown
  vendor_plan: not announced
  traffic_light: red
  task: ask the vendor, assess replacement or in-house build

The inventory depends on comparison with the vendor and with the test system. For purchased extensions, the most important line is whether a 6.8 version has been announced; for custom plugins, the question of who knows the code and can adapt it. Plugins that were once created for a special case and whose developer has left the project tend, in our experience, to end up in the red column more often than the technology alone would justify. For the amber column, the effort is typically easy to plan: migrate service definitions and routes, work through deprecation hits, add tests. Where a plugin has to be rewritten anyway, it is worth asking whether its task can now be solved more cleanly with built-in features or as a leaner extension.

• Symfony configuration in XML found (services.xml, routes.xml, packages/*/.xml)? Then amber.
• Only config.xml, custom-fields.xml or an app manifest? Not affected according to the draft and therefore no reason for amber.
• Hits in the deprecation log on the latest 6.7 minor? Then amber, with an entry in the work list.
• Does the plugin's PHP requirement exclude 8.4 or 8.5? Then amber until the requirement has been extended and tested.
• Vendor without an announced 6.8 version, or code without an owner? Then red, check for a replacement.
• None of the points applies? Green – but only after a run on the test system.

Schedule: from inventory to release candidate

Because Shopware names only the year 2027 for 6.8, the schedule cannot be calculated backwards from a date. It can, however, be structured forwards in phases whose order is fixed. The first phases do not depend on the major version and can start immediately; the last ones require the release candidate. Planning the phases outside the high-revenue weeks avoids conflicts with promotional periods – how traffic peaks such as Black Friday can be absorbed is covered in the article on a virtual waiting room for Black Friday shop traffic. The upgrade itself belongs in a quiet window with a fallback plan.

1. Create the inventory: record all plugins, themes and project configuration with traffic light, origin and owner.
2. Update to the latest 6.7 minor and evaluate the deprecation log; remove ignore patterns for Shopware deprecations.
3. Migrate Symfony configuration in XML, plugin by plugin, each with its own test and its own deployment.
4. Plan the PHP change separately: check and switch plugins on a PHP version listed as tested in the release notes before 6.8 is released.
5. Clarify purchased extensions: ask vendors, document answers, prepare replacements for red entries.
6. Set up a test system with realistic but anonymised data – how that works is shown in the article on Shopware staging test data without customer data.
7. Test the release candidate as soon as it is available and report findings back to Shopware.
8. Carry out the upgrade to 6.8 after the stable release in a quiet window with a fallback plan.

The release candidate phase is the shortest and the least plannable. According to the Release Policy, the release candidate typically appears approximately two months before the planned major release, and the RC phase might be prolonged depending on feedback from the community (Shopware Release Policy). During these weeks, only what was rebuilt beforehand should be tested. Starting to migrate XML configuration and work through deprecations only with the release candidate almost inevitably delays your own go-live. Conversely, a shop whose inventory contains only green and completed amber entries before the release candidate is in a comfortable position: it can use the RC phase to find surprises instead of closing known gaps.

How XICTRON supports the preparation for 6.8

XICTRON supports Community Edition shops through major version changes – from the inventory and the rework of custom plugins to the upgrade in a quiet window. As part of Shopware migration, we create the inventory with traffic light, migrate Symfony configuration in XML and work through deprecation hits as a work list, each on a test environment and with separate acceptance per plugin. Anyone who wants to keep the shop on a current minor version permanently will find the ongoing framework for this in Shopware maintenance: updates via a test environment, security patches, backups and monitoring – and with that also the regular evaluation of new notices about 6.8.

The runtime environment is part of the preparation. With Shopware hosting, the PHP version is part of the server configuration; a PHP change can be planned there as a separate step and rehearsed on a copy of the shop before it goes live. An upgrade is also a good occasion to record the starting point: the shop check for speed, SEO and accessibility provides a snapshot against which the shop can be compared after the upgrade. This makes it visible whether the new version has become slower or less accessible anywhere.

Moving 6.8 to 2027 takes the pressure off the calendar, but not off the code. Symfony configuration in XML is deprecated, deprecations are labelled more clearly than before, and PHP 8.2 loses its security fixes before 6.8 is released. Translating these three points into a work list now means the upgrade can be planned instead of reacted to. A short enquiry about upgrade planning for Shopware 6.8 is enough for a first conversation about inventory, traffic light and schedule.