The Shopware 6.6 upgrade is a project, not a command
A major Shopware upgrade removes what was deprecated, and your plugins are what break. How to find the wall before you hit it, how to rehearse on staging, and how to plan a weekend that does not become a fortnight.
Photo: free stock photography (Unsplash licence) — see imprint
A major version is a promise that the deprecated things are now gone
Minor Shopware updates add things. Major updates take things away — that is the whole point of the number changing. Everything the platform marked as deprecated over the previous major line is fair game for removal, and the removals are not a bug report you can file. They were announced, sometimes years in advance, in changelogs nobody on your side was reading because the shop was working fine.
This is why the upgrade feels unfair. Nothing you did broke. Code that has worked untouched for two years suddenly does not, because a method it called no longer exists, a service was renamed, a template block moved, or a JavaScript dependency the storefront used to bundle is no longer bundled. Your code did not change. The floor under it did.
The plugin compatibility wall is the schedule, not the code
Your own code you can fix. Your plugins you cannot, and that is where upgrades actually die. Every third-party extension in your shop has its own vendor, its own release cadence and its own opinion about whether supporting the new major is worth their weekend. Composer will simply refuse the upgrade until every constraint is satisfiable, which means one abandoned plugin from a one-person vendor who has moved on can hold a six-figure shop on an old version indefinitely.
So the first task of the upgrade is not technical, it is an inventory. List every extension, find its current compatible version, and put each one in a bucket: ready, promised, silent, dead. The silent and dead ones are your project. For each you decide — replace with a standard feature, replace with a competitor, rebuild it yourself, or drop the functionality. Every one of those four is a decision with a cost, and none of them are made by a developer at midnight during the deployment.
Where the breakage actually lives
In practice the damage clusters in a few predictable places, and knowing them lets you scope before you start. Twig template overrides are the worst offender, because a theme that copied a block wholesale will silently render an old version of a page that has since changed underneath it — no error, just a checkout missing a field nobody notices until orders look odd. Storefront JavaScript is second: front-end build tooling and bundled dependencies shift between majors, and a plugin that assumed a global was there finds it is not.
- Twig overrides that copied a block instead of extending it — silent, not loud.
- Storefront JS built against assumptions about what the bundle provides.
- Admin extensions — the supported way to extend the admin keeps moving; check it early.
- Direct DB writes and raw SQL that bypassed the DAL and now hit a changed schema.
- Custom entities and migrations that were never written to be re-runnable.
Rehearse on a copy that is embarrassingly close to production
A staging environment with 200 demo products proves nothing. The bugs you are hunting are data-shaped: the order from 2021 with a payment method that no longer exists, the customer with an umlaut in a field that used to allow it, the 60,000-row property table that turns a five-minute migration into a four-hour table lock. Restore a real production dump, anonymise it, and run the upgrade against that. Then run it again from the same dump, because the first run is never the one you learn from.
The output of the rehearsal is not 'it worked'. It is a runbook: the exact command order, the measured duration of each step, the point of no return, the rollback trigger, and the named person who decides. Time every step. If the database migration took 40 minutes on staging with the same data, your maintenance window is not two hours, and finding that out on Saturday night is expensive in a way that finding it out on Tuesday is not.
When not to upgrade this quarter
We will say the thing that costs us money: a stable, secure, profitable shop does not have to move the month a major appears. Waiting has real benefits — the plugin ecosystem catches up, the early patch releases land, and other people find the sharp edges for you. What you cannot do is wait forever, because the gap only ever gets wider and the eventual jump only ever gets more expensive.
The signals that say go are boring: your security support horizon is approaching, a plugin you need only exists for the new line, or the deprecation debt has grown to the point where every small change costs a week. The signal that says wait is that three of your critical extensions have no compatible release and no dated commitment. Upgrading anyway on that footing means going live with functionality missing and hoping nobody in sales notices before Thursday.
| Phase | What you produce | How it goes wrong |
|---|---|---|
| Inventory | Every extension bucketed: ready, promised, silent, dead | Skipped — the wall is discovered by Composer at 22:00 |
| Decisions | A named owner and a plan for each dead plugin | Deferred to the deployment, where nobody can decide |
| Rehearsal | Timed runbook from an anonymised production dump | Run on demo data — proves nothing about your data |
| Window | Measured duration plus a rollback trigger and a decider | Guessed at two hours because it 'should be quick' |
| After | Deprecation warnings tracked as work, not noise | Ignored until the next major, and the bill compounds |
- A major version removes what was deprecated — your code did not break, the floor moved.
- One abandoned plugin can hold a working shop on an old version indefinitely.
- A rehearsal on demo data proves nothing — the bugs are shaped like your production data.
- A stable shop may wait a quarter. It may not wait a major line.
Frequently asked questions
The command runs in minutes. The project runs from a week to a couple of months, and the spread is entirely explained by extensions and custom code. A near-standard shop with maintained plugins is a short, boring job. A shop with a heavily overridden theme, a custom ERP connector and four unmaintained extensions is a real project with analysis, rework and a rehearsal. Get the extension inventory first — until then, any estimate is fiction.
You have four options and no fifth: replace it with standard functionality, replace it with a maintained competitor, take over the code and maintain it yourself, or drop the feature. Ask the vendor for a dated commitment, not a friendly 'we are working on it'. If the plugin is small and does one thing, rebuilding is often cheaper than the meetings about it — if it is your pricing logic, that is a project of its own.
Plan it as a sequence, not a leap. Shopware's own upgrade guidance is written per major step, and skipping steps means you also skip the intermediate migrations and the deprecation warnings that would have told you what to fix. Go version by version on a staging copy, note what screams at each stop, and only then design the production run. It is slower to read and much faster to survive.
Not if your shop is close to standard, your plugins are maintained and someone in-house can restore a dump and read a stack trace. That case is genuinely a maintenance task and you should not pay project money for it. You need help when custom code touches the DAL, when the theme is heavily overridden, or when nobody can answer what a given plugin actually does — those are the shops where an unrehearsed upgrade turns a weekend into a fortnight.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer