Shopware 6.8: Outlook, roadmap, changes, and preparation

Shopware 6.8 will be the next major release after Shopware 6.7. Originally expected in 2026, it has officially been postponed to 2027. As of August 17, 2026, Shopware has not published a specific date or final scope.

The release is nevertheless relevant today. The public upgrade guide already shows initial technical changes, some extensions have a confirmed end of support, and the 6.7 line contains migration paths, feature flags, and deprecations for the next major step.

A reliable outlook needs to distinguish three categories:

1. Officially confirmed: The broad schedule and strategic priorities.
2. Technically in preparation: Changes in the evolving UPGRADE-6.8.md that may still change before release.
3. Under discussion: RFCs and drafts that are not release commitments.

What Shopware has officially confirmed about 6.8

Three things are officially confirmed: Shopware announced on November 12, 2025 that 6.8 would move from 2026 to 2027, names stability, documentation, and Agentic AI as its priorities for the extended period, and extends support for Shopware 6.6 until 6.8 becomes available. As the reason for the postponement, the company cites the balance between progress, robustness, stability, and developer experience.

Shopware names three priorities for the extended development period:

• platform stability, performance, and security,
• improved documentation and developer experience,
• continued development of Agentic AI capabilities.

Extended support for Shopware 6.6 will continue until 6.8 becomes available. This gives merchants on 6.6 more time, but extended support should not be confused with the active feature development happening in 6.7.

Why the postponement can be beneficial

A major release permits breaking changes — and every such change creates work for extension vendors, agencies, and merchants. The longer cycle buys everyone time: for stabilization, extension migrations, longer-visible deprecations, and a planned replacement of the B2B Suite and language pack. Shopware has also shown that visible commerce capabilities can be delivered through 6.7 minor releases.

The longer cycle offers several opportunities:

• 6.7 can be stabilized and expanded further.
• Extension vendors have more migration time.
• Deprecations can remain visible longer before removal.
• Merchants can replace the B2B Suite, language pack, and custom legacy code in a planned way.
• Architectural changes can be prepared through feature flags and testing.

The extra time is not a reason to do nothing until 2027. Teams that begin all changes only at release waste the preparation window.

What a major release is likely to change

Shopware major releases are traditionally the point at which obsolete APIs, services, configuration options, and compatibility layers are removed. New visible features may appear as well, but the most important result is often a cleaner technical foundation.

The current upgrade guide on Shopware's trunk is useful for this reason. It is a living developer document, not a final release contract. The following points represent its status in August 2026.

In preparation: removal of deprecations

Shopware marks APIs and configuration as deprecated in 6.7 before removing them in 6.8. The affected areas include old cache options, Administration blocks, services, events, and API behavior.

Most of this is invisible to a standard store. Custom plugins and deep integrations can use these interfaces directly. Deprecation logs and upgrade documentation should therefore be reviewed before 6.8 is released.

Axios 1 becomes the Administration default

Shopware 6.7 already supports Axios 1 alongside the older client. Custom Administration extensions can opt in using useAxiosV1: true. The current 6.8 guide makes Axios 1 the default.

Relevant differences include request cancellation, error codes, and some defaults. Plugin developers should test HTTP calls with the new client under 6.7 rather than assume a compatibility mode will remain available.

Webhooks receive a dedicated Messenger transport

The current 6.8 guide describes a dedicated webhook transport. Operators who override Messenger receivers or shopware.admin_worker.transports need to add it. Otherwise, webhooks may no longer be processed after the update.

This is a small configuration change with major operational impact. Default setups may work automatically, while custom worker configurations need an explicit review.

The cache rework continues

Shopware 6.7 removed the previous Store API cache layer and prepared a new HTTP caching model. The current 6.8 guide removes obsolete configuration and moves selected cacheable Store API GET routes into the standard HTTP cache.

Operators should document and measure reverse proxy behavior, cache keys, invalidation, and response headers under 6.7 instead of copying old settings blindly.

Agentic Commerce moves out of the core

The experimental Agentic Commerce sales channel was tested in the 6.7 core. The current 6.8 upgrade guide instructs merchants to install the SwagAgenticCommerce extension before updating to retain configured sales channels and functionality.

This suggests a more modular evolution outside the core. Merchants using the experimental channel should document data, feed URLs, configuration, and tracking before migration.

B2B Suite ends; B2B Components become the target

Shopware confirms in its documentation that the legacy B2B Suite will no longer be supported from 6.8. New B2B functionality is already being developed in B2B Components.

Affected merchants need more than an extension swap. Organizations, employees, roles, budgets, approvals, quotes, order lists, customer-specific catalogs, and individual pricing all require assessment. A production B2B migration is a dedicated business project.

The former language pack will no longer be supported

Since 6.7.3, Shopware can manage available translations natively from the core. According to the documentation, the language-pack extension will no longer be supported from 6.8.

Before moving, review installed languages, custom snippets, plugin translations, and deployment workflows. Core migration does not replace an editorial translation strategy.

Storefront and developer experience

Shopware 6.7.11 introduced Twig UX Components, a Vite-based storefront dev server, CSS custom properties generated from theme settings, and a global JavaScript event system. These building blocks point toward reusable components and modern development workflows.

It is not yet confirmed which foundations become mandatory in 6.8 or replace existing mechanisms. New themes and components should still consider the current 6.7 approaches to avoid creating fresh legacy code.

Agentic AI remains a strategic priority

Shopware explicitly names Agentic AI as a focus through 6.8. The 6.7 line already includes Agentic Commerce feeds, AI Discovery Files, Copilot blueprints, and an experimental MCP server.

This does not mean every future AI capability will ship in 6.8 or Community Edition. Shopware may deliver features through minor releases, commercial extensions, or services. The strategic direction is confirmed; individual product details are not.

Under discussion: an entity-based cart

A public Shopware RFC discusses replacing the session-based cart with an entity-based system targeting 6.8. Stated goals include multiple carts per customer, better performance, and reduced architectural complexity.

Its status is Draft. It must not be presented as a committed feature. The RFC is still useful because it indicates which fundamental commerce models Shopware is exploring.

What merchants should prepare now

Seven preparations pay off regardless of the final release date: keep Shopware 6.7 current, document the extension inventory, review custom code for deprecations, migrate B2B Suite and language pack, document the infrastructure, build automated core tests, and reserve budget and a release window. Each one reduces the eventual major-upgrade risk — even if the 6.8 scope still changes.

1. Keep Shopware 6.7 current

A maintained 6.7 system exposes deprecations, migration paths, and new compatibility options early. Jumping from an old 6.6 or neglected 6.7 version directly to 6.8 would change more variables at once. What the update to Shopware 6.7 brings and how to run it cleanly is covered separately.

2. Create an extension inventory

Record vendor, version, business criticality, maintenance status, and possible replacement for every plugin, app, and theme. Unmaintained extensions deserve particular attention.

3. Review custom code for deprecations

Static analysis, tests, and logs should reveal outdated APIs, Administration overrides, Axios calls, cache configuration, and event subscribers. Every deprecation removed under 6.7 reduces later major-upgrade risk.

4. Migrate B2B Suite and language pack

Both support endings are officially documented. Affected projects should complete analysis and migration well before the 6.8 production update.

5. Document the infrastructure

Record PHP, database, Redis, OpenSearch, queue workers, cron, reverse proxy, Node toolchain, deployment, and observability. Final 6.8 system requirements are pending, but undocumented custom configuration is already a risk.

6. Build automated core tests

At minimum, login, search, cart, checkout, payment, order transfer, customer account, and core API flows should be reproducible. Without regression tests, every release candidate becomes a large manual project.

7. Reserve budget and a release window

Major upgrades require analysis, adaptation, testing, deployment, and monitoring. A placeholder in the roadmap and budget prevents 6.8 from becoming unplanned maintenance. The easiest way is to anchor it in an ongoing maintenance retainer that plans for major upgrades from the outset.

What merchants should not do yet

Just as important as the preparation is the boundary: the year 2027 is not a launch date, an RFC is not a confirmed feature, and today's trunk guide is not a release contract. Basing architecture or budget decisions solely on unconfirmed 6.8 details builds on sand. In concrete terms:

• Do not infer a final launch date from the year 2027.
• Do not sell an RFC as a confirmed feature.
• Do not design production architecture solely around today's trunk guide.
• Do not postpone every useful 6.7 feature because 6.8 is planned.
• Do not wait for the first release candidate to analyze B2B Suite or language pack migration.

A realistic internal timeline

The internal timeline splits into three phases: clean-up work from today until an official preview, production-like testing during the release-candidate phase, and a controlled, unhurried rollout after the final release. Teams that take the first phase seriously turn the other two into routine work instead of crisis projects.

Now until an official preview

• update and stabilize 6.7,
• inventory extensions and custom code,
• resolve deprecations,
• start confirmed migrations,
• expand automated tests.

During release candidates

• update a production-like stage,
• verify final system requirements,
• test plugins and themes using approved versions,
• compare performance and core business processes,
• plan rollback and maintenance windows.

After the final release

• do not automatically update production on day one,
• assess first patches and vendor approvals,
• weigh individual risk and required features,
• deploy with monitoring and a post-release review.

Is it worth waiting for 6.8?

For most active stores, the answer is no. Shopware 6.7 continues to receive features, performance improvements, and security updates, while 6.8 is planned for 2027 but has neither a fixed date nor a final scope. A maintained 6.7 foundation is at the same time the best preparation for 6.8 — waiting brings no advantage.

Remaining on an older version may mean foregoing improvements for a long time and increasing the eventual migration step.

Conclusion: 6.8 preparation begins by cleaning up 6.7

The reliable 6.8 outlook currently consists less of a completed feature list than a clear direction: release in 2027 with more emphasis on stability, performance, security, developer experience, and Agentic AI.

Technical preparations are already visible. Axios 1, webhook transport, cache cleanup, modular Agentic Commerce, and the end of B2B Suite and language pack provide concrete work packages.

The best time to prepare is not release day. Teams that maintain 6.7, remove deprecations, automate tests, and finish confirmed migrations turn 6.8 into a planned upgrade rather than an emergency project.

Official sources

• Shopware: Next major version 6.8 planned for 2027
• Evolving technical upgrade guide for Shopware 6.8
• Shopware B2B Suite end of support with 6.8
• Shopware language pack documentation
• Entity-based cart RFC – Draft status