6.8 moved to 2027: what the long 6.6→6.7 wave means for maintenance retainers

Shopware confirmed it in an official roadmap update: 6.8, the next major version, is now planned for 2027, not 2026. The stated reasoning is stability over speed — balancing progress against robustness and developer experience — and alongside the delay, the extended-support window for 6.6 is being prolonged to stay active until 6.8 actually ships. For any agency running a maintenance retainer on a Shopware fleet, that single scheduling decision changes the shape of the next year and a half of planning.

What doesn't change: there's still no 6.8 to plan around

A delayed major version doesn't mean a quiet year. Shopware has said it will keep shipping regular minor releases in the meantime — new features, accessibility improvements, bug fixes, stability work — which means the 6.6→6.7-class update wave agencies are already living through doesn't pause while everyone waits for 6.8. If anything, it runs longer: without a 6.8 cutover forcing a natural planning boundary, minor-version updates keep arriving on their normal cadence across a longer stretch of calendar time.

What that means for a retainer book

Picture a typical DACH agency retainer: EUR 500-3000 a month per client, with "plugin compatibility and update testing" folded into that line item rather than billed separately. Published agency update checklists put the actual manual audit cadence at something like two to three hours a month per shop, plus a heavier quarterly compatibility pass around each real update window. Multiply that across ten, twenty, fifty shops on the book, and it was already the least billable, most time-consuming part of the retainer relationship before you factor in that the wave isn't ending on any predictable near-term date.

A longer 6.6→6.7-class window, without a 6.8 milestone to plan the next big push around, means that audit cadence doesn't get a natural pause either. The agencies that come out ahead here aren't the ones waiting for the next major version to force a planning cycle — they're the ones who treat every minor-update window, however frequent, as routine enough to check quickly rather than dread.

The alternative — waiting for 6.8 as the moment to finally build a proper pre-flight habit — no longer has a near-term date attached to it at all. Whatever process an agency has for checking plugin compatibility today is the process it's going to be running, repeatedly, well into 2027.

Why this doesn't change the underlying gap

None of this is new territory for the actual problem agencies are solving: before any update, someone has to answer "will our installed plugins survive this" for every shop on the book. That gap has been sitting as an open feature request against Shopware itself, and the tools that exist around it today — rollback managers, monitoring dashboards — are reactive by design. They tell you what already broke after an update has shipped. None of them answer the question before the update window opens, which is the only point where the answer is actually useful for planning.

A longer, less date-anchored update wave makes that gap more expensive to leave open, not less. Waiting for a 6.8 milestone to justify building a proper pre-flight process was never a great plan; now there's no milestone in the near term to wait for at all.

It also reframes the absorption risk worth watching either way: if Shopware ever ships that feature request natively, a pre-flight tool's value shifts toward the parts core tooling still won't cover — fleet-wide reporting, history across a retainer book — rather than disappearing. That's a watch item, not a reason to wait on building the habit now.

What a pre-flight check actually buys you here

Upgrade Radar reads a shop's declared plugin constraints — composer.lock, custom/plugins, custom/static-plugins — against whatever the next target version is, minor or otherwise, and returns a verdict per plugin: compatible, conflicting (with the exact constraint that excludes it), or honestly unknown when nothing was declared either way. No composer run, no shop access, runs offline in seconds. It doesn't require a major-version milestone to be worth running — it's built for exactly the routine, frequent, unglamorous minor-update cadence that a delayed 6.8 makes the more relevant reality for the next year and a half.

That matters most for the part of the retainer that's hardest to bill cleanly: the audit itself. Every hour that check takes off a per-shop, per-window basis is an hour that stops competing with actual client work for calendar time — regardless of whether the update in question is a routine minor or eventually, in 2027, the major one everyone's been waiting for.

Check your own book against the current wave

If your retainer book has shops sitting on 6.6 waiting for a 6.7-class update — or anything in between — the fastest way to see where you stand is to check.