Migrating from Shopware 6.5 to 6.6: What Actually Breaks

March 8, 2026 • by Tobias Schäfer • 16 min read

#Shopware #PHP #Shopware 6 #Plugin Development

The most common 6.6 failure mode has nothing to do with PHP. It’s a blank white screen in the admin, caused by Vue 2 patterns that Vue 3 either removed or silently ignores. This guide covers all the breaking changes — frontend and backend — and a step-by-step process for getting through them without surprises.

Why 6.6 Was Different

Shopware 6 minor releases are usually incremental. APIs get deprecated, not removed. Twig templates shift slightly. You update, clear cache, fix one or two things, move on. That’s been the rhythm for years.

6.6 broke that rhythm.

Several large changes landed simultaneously: a full migration of the admin interface from Vue 2 to Vue 3, a Symfony 7 upgrade, the removal of all.js from the storefront build system, and a pile of previously-deprecated PHP APIs reaching their removal date. Any one of these would have made 6.6 a significant release. All of them together made it the most disruptive Shopware upgrade in years.

The result: a plugin that worked perfectly in 6.5 could render a blank screen in 6.6 without a single line of PHP changing. The frontend logic was the problem, and if you hadn’t specifically checked for Vue 3 compatibility, you had no way to know until you ran the update.

The expectation to set: This is not a trivial upgrade. If you have plugins that touch the admin interface — whether bought from the Shopware Store or built by your agency — assume they need review. Don’t assume compatibility.

What Changed: Overview

Category	Scope	Impact
System requirements	PHP 8.2+, MariaDB 10.11+, Redis 7.0+	Low-Medium
Admin: Vue 2 → Vue 3	All admin Vue components	High for plugins with admin UI
Admin: SDK package renamed	`admin-extension-sdk` → `meteor-admin-sdk`	Medium for admin extensions
Admin: vue-meta removed	Head management in admin views	Low (high if your plugin uses it)
Admin: Vuex → Pinia	Shopware store migrations begin	Low-Medium
Admin: Meteor component library	`mt-*` components introduced	Low — `sw-*` still works in 6.6
PHP/Backend: Symfony 7	All Symfony packages updated	Medium — depends on what you use
PHP/Backend: Deprecated APIs removed	Various services, types, method signatures	Medium — depends on what you use
Storefront: `all.js` removed	Plugin JS build model changed	High for plugins with storefront JS
Storefront: template changes	HTML structure, Twig variable renames	Low-Medium

The Vue 3 Migration

This is the biggest source of breakage in 6.6, and the one most likely to catch you off guard if you didn’t write the plugins yourself.

What Vue 3 Actually Changes

The Options API still works in Vue 3. If you have a simple plugin component using data(), computed, methods, and standard lifecycle hooks, it will mostly survive. The problems come from patterns that Shopware and the Vue 2 ecosystem used heavily — patterns that Vue 3 either removed or changed fundamentally.

this.$set() is gone. In Vue 2, you needed this.$set(obj, 'key', value) to make new properties reactive. Vue 3’s reactivity system is built on proxies — it doesn’t need this. Any plugin that calls this.$set() will throw a runtime error.

$listeners was merged into $attrs. In Vue 2, event listeners were separate from attributes. In Vue 3, they’re unified under $attrs. Any component that explicitly references this.$listeners will break.

v-model semantics changed. This one is subtle but widespread. In Vue 2, v-model on a custom component emits input and binds to a prop called value. In Vue 3, it emits update:modelValue and binds to modelValue. If your plugin has any custom input components, this is almost certainly broken.

Vue filters are removed. No more {{ price | currency }} in templates. You need computed properties or methods instead.

Lifecycle hooks were renamed:

beforeDestroy → beforeUnmount
destroyed → unmounted

These fail silently — the hook just doesn’t run. This is the worst kind of breakage: no error, just missing behavior.

this.$children was removed entirely. It no longer exists in Vue 3. this.$parent still exists but the component instance structure changed. Any plugin that traverses the component tree this way will throw an error or behave unexpectedly. The correct approach is provide/inject.

Shopware-Specific: Component Registration

Shopware has its own layer on top of Vue for registering and building components. In 6.5, you’d typically see:

Shopware.Component.register('my-plugin-component', {
    template,
    // ...component options
});

In 6.6, the internals of how these components are built and extended changed. If you’re overriding existing Shopware components (common in admin plugins), check that the Shopware.Component.build() and override patterns still resolve correctly.

Admin SDK Package Renamed

The extension SDK package was renamed in 6.6:

Before: @shopware-ag/admin-extension-sdk
After:  @shopware-ag/meteor-admin-sdk

Update your package.json and all import paths. The API largely stayed the same — this is mostly a find-and-replace across your JS files — but it’s a hard requirement: the old package is no longer maintained for 6.6+.

npm uninstall @shopware-ag/admin-extension-sdk
npm install @shopware-ag/meteor-admin-sdk@^4.0.0

Then update your imports:

// Before
import { ... } from '@shopware-ag/admin-extension-sdk';

// After
import { ... } from '@shopware-ag/meteor-admin-sdk';

vue-meta Removed

The vue-meta package was removed entirely from the admin in 6.6. If your plugin uses vue-meta to manage page titles or head tags in admin views, it will throw an error in 6.6. The replacement is Vue 3’s native Composition API alternatives. In practice this is rare in third-party plugins, but worth checking.

Vuex → Pinia

Shopware is migrating its own admin stores from Vuex to Pinia, starting in 6.6. This is an ongoing process — the adminMenu store was one of the first to move (6.6.8.0). For most plugins this is low impact, but if your plugin reads from or writes to Shopware’s built-in Vuex stores directly (rather than through the documented store API), watch for breakage as the migration continues through 6.6.x patch releases and into 6.7.

Before and After: A Component Override

Here’s a simplified example of a common admin component pattern that breaks in 6.6:

Before (Vue 2 / Shopware 6.5):

// src/Resources/app/administration/src/component/my-order-filter/index.js
import template from './my-order-filter.html.twig';

Shopware.Component.register('my-order-filter', {
    template,

    props: {
        value: {
            type: String,
            default: '',
        },
    },

    data() {
        return {
            internalValue: this.value,
        };
    },

    beforeDestroy() {
        this.cleanup();
    },

    methods: {
        onInput(val) {
            this.$emit('input', val);
        },

        cleanup() {
            // teardown logic
        },
    },
});

After (Vue 3 / Shopware 6.6):

// src/Resources/app/administration/src/component/my-order-filter/index.js
import template from './my-order-filter.html.twig';

Shopware.Component.register('my-order-filter', {
    template,

    props: {
        modelValue: {
            type: String,
            default: '',
        },
    },

    data() {
        return {
            internalValue: this.modelValue,
        };
    },

    beforeUnmount() {
        this.cleanup();
    },

    methods: {
        onInput(val) {
            this.$emit('update:modelValue', val);
        },

        cleanup() {
            // teardown logic
        },
    },
});

Three changes: prop name, emit event name, lifecycle hook name. Any one of these missing in a real plugin causes a silent failure or a broken two-way binding.

The Meteor Component Library

Shopware 6.6 introduced the Meteor component library — a standalone design system with mt-* prefixed components intended to eventually replace the existing sw-* admin components.

The important thing for a 6.6 migration: your existing sw-* components still work. They don’t generate deprecation warnings in 6.6. The formal deprecation of sw-* components (with @deprecated tags and console warnings) is a 6.7 concern, not a 6.6 one.

What this means in practice: you don’t need to migrate your sw-* admin templates as part of a 6.5 → 6.6 upgrade. Your plugins will continue to function. However, if you are writing new admin components or doing a significant rewrite, use mt-* from the start — you’ll have to migrate anyway when you get to 6.7, and the new components are better.

The components and their mt-* equivalents (for reference when you get to 6.7):

Old component	New component
`sw-card`	`mt-card`
`sw-button`	`mt-button`
`sw-text-field`	`mt-text-field`
`sw-number-field`	`mt-number-field`
`sw-textarea-field`	`mt-textarea-field`
`sw-select-field`	`mt-select-field`
`sw-checkbox-field`	`mt-checkbox-field`
`sw-switch-field`	`mt-switch`

When the time comes, these are not just renames — prop names, slot structures, and event names changed too. Note sw-switch-field → mt-switch, not mt-switch-field. A global find-and-replace won’t get you there cleanly.

$tc() → $t(): In Shopware 6.6, the $tc() translation function was deprecated in favor of $t(). Any plugin template using $tc('some.key') will work but generate deprecation warnings. The replacement is a straightforward rename throughout your templates and JavaScript files.

PHP-Level Changes

The PHP side of the 6.6 migration is real but more predictable than the admin changes, provided you did your homework in 6.5.

System requirements changed across the board. Before touching anything else, verify your environment meets the new minimums:

Dependency	6.5 minimum	6.6 minimum
PHP	8.1	8.2
MariaDB	10.4	10.11
Redis	6.2	7.0

If you’re running managed infrastructure, update these before the Shopware upgrade — not alongside it. PHP 8.2 in particular introduced its own deprecations (dynamic properties, for instance), so run your plugin code against 8.2 on a test environment before migrating Shopware itself.

Symfony 7. Shopware 6.6 upgraded all Symfony packages to version 7. If your plugin uses Symfony components directly (routing, form, security, console, etc.), check Symfony’s own 6→7 upgrade guide for anything that affects your code. Symfony 7 tightened type declarations and removed several long-deprecated features. The most common plugin issue: any service that extends or implements a Symfony class where the method signatures changed.

Deprecated APIs removed. The rule in Shopware is that methods deprecated in one minor release are removed in the next. If you were running 6.5 and had deprecation notices in your logs — those are now hard errors in 6.6. This is actually good practice: if you addressed all your @deprecated warnings in 6.5, the PHP upgrade is largely clean. If you ignored them, you have work to do.

Common areas where I’ve seen breakage:

EntityRepository method signatures: some parameter types tightened or changed
Internal service IDs: a handful of services were renamed or restructured in the dependency injection container
Type-hinted methods where mixed or loose types were tightened

My strongest recommendation before any 6.6 migration: run PHPStan against your custom plugins while still on 6.5. Shopware ships PHPStan configuration in vendor/shopware/core/dev-ops/ that catches deprecated API usage. The output will tell you exactly what will break before you upgrade anything.

# Run PHPStan against your plugin (adjust path to match your setup)
vendor/bin/phpstan analyse custom/plugins/YourPlugin/src/ --level=6

# Shopware's own ruleset is in the core package:
# vendor/shopware/core/dev-ops/phpstan/phpstan.neon
# Reference it in your phpstan.neon for Shopware-specific deprecation rules

Storefront Changes

The `all.js` Removal (High Impact for Storefront Plugins)

This one catches developers off guard because it’s not in the obvious “admin changes” category. In Shopware 6.5, the storefront compiled all plugin JavaScript into a single all.js bundle. In 6.6, that bundle is gone.

What this means: If your plugin adds JavaScript to the storefront — a custom slider, a tracking script, a product configurator — it previously relied on being included in all.js automatically. In 6.6, each plugin must compile and distribute its own JavaScript as a separate bundle in a dist/ directory.

The new model:

Before (6.5): all plugins → single all.js
After (6.6):  each plugin → its own dist/storefront/js/plugin-name.js

Shopware now uses a Webpack MultiCompiler setup that builds each plugin’s JS separately. PluginManager.initializePlugins() is now async to accommodate this.

The practical impact: A plugin with storefront JavaScript that hasn’t been updated for 6.6 will silently stop working — no error in the PHP logs, just missing JS behavior in the browser console. Check console.error in your browser after upgrading for PluginManager registration failures.

What needs to change in your plugin:

Ensure your JS entry point is at src/Resources/app/storefront/src/main.js (or matches Shopware’s expected entry path for your plugin)
Run bin/console theme:compile — the multi-compiler will build your plugin’s JS as a separate bundle
The compiled output lands at src/Resources/app/storefront/dist/storefront/js/ — commit this directory or ensure your deployment process generates it
Run bin/console assets:install to make the compiled assets available to the webserver

You do not need a custom webpack.config.js — Shopware’s theme compiler handles the build. What you do need is the correct file structure so the compiler can find and build your entry point.

Also note: direct imports from PluginManager or the Plugin base class are deprecated. Switch to async plugin registration patterns where the plugin manager is available via the async module system.

Template and Markup Changes

Some Twig template variables were renamed — check Shopware’s UPGRADE.md for the full list and update any overridden templates. Two structural changes worth noting:

Order items and cart line items changed from <div> to <ul>/<li> elements — CSS targeting these directly will break
Header and footer are now loaded via ESI (Edge Side Includes), which affects caching and any sub-request context handling

After updating, run:

bin/console theme:compile
bin/console cache:clear

Watch the compilation output carefully. Compilation errors surface template issues before your customers see them. If compilation succeeds but something looks wrong visually, check for undefined Twig variables — they fail silently and render as empty strings.

The Migration Process: Step by Step

I’ve done enough of these now that the order matters. Don’t improvise.

Check plugin compatibility first — before touching anything else. For every installed plugin, check the Shopware Store compatibility badge for 6.6 support. For custom/agency plugins, this means a code review against the breaking change list.
Update your server environment on staging: PHP to 8.2, MariaDB to 10.11, Redis to 7.0. Do this before the Shopware update — mixing environment and application changes obscures which one broke what.
Read Shopware’s official UPGRADE.md for 6.6. It’s in the Shopware repository. It lists every breaking change. This is the source of truth, not blog posts (including this one).

Update the admin SDK package if your plugins use it:

npm uninstall @shopware-ag/admin-extension-sdk
npm install @shopware-ag/meteor-admin-sdk@^4.0.0

Update your composer.json constraint to allow 6.6: "shopware/core": "~6.6.0".
Run composer update shopware/* on staging only. Not production. Not yet.
Run bin/console cache:clear immediately after.
Open the admin and check every page your plugins affect. Click through. Don’t just look at the dashboard. Open the specific modules your plugins add or modify.
Check PHP error logs for fatals. Fatal errors here mean PHP-level breakage — removed APIs, Symfony 7 incompatibilities, or type errors.
Fix Vue 2 patterns in admin components: $set, $listeners, v-model, filters, lifecycle hooks.
Rename $tc() to $t() throughout your admin templates and JavaScript files to clear deprecation warnings.
Check storefront JS plugins. If any plugin has code in src/Resources/app/storefront/src/, verify it compiles under the new multi-compiler model. Look for JS errors in the browser console — missing storefront behavior with no PHP errors is the signature of an all.js migration problem.

Rebuild all assets after any JS/template changes:

bin/console theme:compile
bin/console assets:install
bin/console cache:clear

Run your test suite. If you don’t have automated tests for your custom plugins, this migration is a strong argument for writing them. Manual testing at this scale misses things.
Deploy to production in a maintenance window. Schedule it, announce it, have a rollback plan ready.

The Compatibility Check: What to Do Before You Start

The first thing I do before any 6.6 migration is a plugin audit. Here’s how to think about it:

For Shopware Store plugins: The compatibility badge is visible on each plugin’s store page. If it shows 6.6 support, the developer has tested and published a compatible version. Update the plugin first, before updating Shopware itself.

For custom or agency-built plugins: There’s no badge. You need to review the code. Two directories tell you the risk profile:

src/Resources/app/administration/ — admin UI. Assume Vue 3 migration work is needed.
src/Resources/app/storefront/src/ — storefront JavaScript. The all.js removal may affect this.

A plugin with neither of these directories is very likely fine for the 6.6 upgrade — pure PHP plugins face only the deprecated API and Symfony 7 changes. A plugin with admin or storefront JS: assume work is needed until someone has specifically verified it against 6.6.

Before you schedule the migration, ask your agency or developer for a compatibility audit in writing. Not “do you think it’ll be fine” — ask for a specific assessment of each admin-touching plugin against the 6.6 breaking changes list. This protects you and creates a record of what was checked.

What About 6.7?

If you’re reading this having just survived 6.6, or you’re planning your path forward: 6.7 is where the Meteor component migration becomes mandatory. The sw-* components that have mt-* equivalents are formally deprecated in 6.7 — with console warnings and @deprecated tags — and the PHP minimum version moves to 8.3.

The good news: the jump from 6.6 to 6.7 is significantly smaller than from 6.5 to 6.6. The architectural disruption already happened. 6.7 is refinement, not reconstruction.

My recommendation: if you’re still on 6.5, don’t try to skip to 6.7. Migrate to 6.6 first, stabilize, fix everything that broke, run for a month or two in production, then approach 6.7 as a separate project. Trying to absorb both sets of breaking changes simultaneously is how projects go sideways.

Frequently Asked Questions

Can I skip 6.6 and go straight to 6.7?

Technically yes — Shopware allows version jumps. But you don’t escape the 6.6 breaking changes by doing this. The Vue 3 migration, the all.js removal, the Symfony 7 upgrade, the removed deprecated PHP APIs — all of that still applies, and you’ll be debugging two releases’ worth of breakage simultaneously. Unless you have a very specific reason to jump, go through 6.6 first.

How long does the migration actually take?

It depends almost entirely on how many admin-touching plugins you have and whether they were maintained. A shop with three or four well-maintained, frequently updated plugins from active developers: a focused half-day on staging, an hour deployment window. A shop with twelve plugins, several of which haven’t been touched since 6.4, some of them custom-built by an agency that no longer exists: weeks of work. There’s no universal answer. Audit first, then estimate.

Will Rise/Evolve/Beyond (SaaS) get auto-updated?

Yes. Shopware controls the update schedule for their SaaS editions. This is actually one of the strongest arguments for auditing plugin compatibility proactively — if you’re on Rise SaaS, Shopware will update you on their timeline, not yours. The notice period varies, but it’s not generous. If you haven’t already checked compatibility before the notification arrives, you’re in reactive mode.

Is there a compatibility mode or shim for the old components?

Shopware provided some deprecation shims during the 6.6 transition period that kept some removed patterns working temporarily. Don’t rely on them. They were explicitly documented as temporary, and they’re being removed. If your plugin depends on a shim, it’s borrowed time. Fix the underlying issue.

Where to Go From Here

If you’re managing a Shopware 6.5 shop and haven’t migrated yet, start with the plugin audit. That’s the work that determines your actual timeline and budget for this migration. Everything else follows from knowing what you’re dealing with.

If you’ve already been through 6.6 and are now thinking about 6.7, the process is the same — audit first, fix forward, don’t skip steps.

For more background on how Shopware is structured and what you’re actually running, the Shopware 6 overview covers the platform foundations. If you’re trying to understand whether upgrading edition tiers makes sense alongside the version migration, the Shopware 6 pricing breakdown has the numbers.

If you have a specific migration coming up and want a second opinion on what actually needs to happen — feel free to reach out. I’ll tell you honestly what I see in the code, not what you want to hear.

Migrating from Shopware 6.5 to 6.6: What Actually Breaks

Why 6.6 Was Different

What Changed: Overview

The Vue 3 Migration

What Vue 3 Actually Changes

Shopware-Specific: Component Registration

Admin SDK Package Renamed

vue-meta Removed

Vuex → Pinia

Before and After: A Component Override

The Meteor Component Library

PHP-Level Changes

Storefront Changes

The `all.js` Removal (High Impact for Storefront Plugins)

Template and Markup Changes

The Migration Process: Step by Step

The Compatibility Check: What to Do Before You Start

What About 6.7?

Frequently Asked Questions

Where to Go From Here

Related Posts

Shopware 6.6 to 6.7: What Actually Changes

Laravel AI SDK: A Practical Guide with Real Code Examples

Shopware 6 in 2026: Is It the Right Platform for You?

Why 6.6 Was Different

What Changed: Overview

The Vue 3 Migration

What Vue 3 Actually Changes

Shopware-Specific: Component Registration

Admin SDK Package Renamed

vue-meta Removed

Vuex → Pinia

Before and After: A Component Override

The Meteor Component Library

PHP-Level Changes

Storefront Changes

The all.js Removal (High Impact for Storefront Plugins)

Template and Markup Changes

The Migration Process: Step by Step

The Compatibility Check: What to Do Before You Start

What About 6.7?

Frequently Asked Questions

Where to Go From Here

Related Posts

Shopware 6.6 to 6.7: What Actually Changes

Laravel AI SDK: A Practical Guide with Real Code Examples

Shopware 6 in 2026: Is It the Right Platform for You?

The `all.js` Removal (High Impact for Storefront Plugins)