Planning 30 shop updates without opening 30 shops

Ask an agency tech lead what a Shopware 6.6→6.7-class update window actually costs, and the honest answer is rarely "the update." It's the audit before it: opening every client shop on the retainer book, one at a time, to see whether this update is even safe to schedule. Ten shops, twenty, fifty — the hours add up fast, and most of them are unbillable or awkwardly billed, because "checking if we can update" doesn't map cleanly to a client line item.

This is the piece of the job Upgrade Radar is built to remove: not the update itself, but the thirty separate trips into thirty separate shops just to find out where the landmines are.

What "opening a shop" actually means today

For most agencies it means logging in, or pulling a checkout, then manually reading through composer.json for every installed plugin, cross-referencing each shopware/* constraint against the target version, and writing down which ones look safe. It's the kind of task that's simple enough to explain in one sentence and tedious enough to eat an entire afternoon per shop when you have real plugin counts and real constraint syntax to deal with — caret here, tilde there, a hyphen range somebody wrote three years ago.

Do that across a retainer book sized EUR 500-3000/month per agency client — the band DACH Shopware agencies with 10-50 shops actually operate in — and the audit itself starts to compete with the update for calendar time. The economics only work if the audit gets fast.

What Upgrade Radar replaces it with, today

Point Upgrade Radar at a shop's checkout — or just its composer.lock plus the plugin directories — and it reads the declared state (composer.lock entries typed shopware-platform-plugin, custom/plugins/*, custom/static-plugins/*) and evaluates every plugin's constraint against your target version. No composer run, no vendor tree, no shop access at all. That's one shop, audited in seconds instead of an afternoon, with a verdict per plugin instead of a gut feeling.

The v1.1 layer goes one step further on exactly the question agencies plan a window around: for every CONFLICT, does a compatible release of that plugin actually exist? Upgrade Radar checks Packagist and the Shopware Store and splits the answer three honest ways — "fixable by plugin update" (a release admitting the target is named), "genuinely blocking" (the channel was checked and nothing admits the target), or "availability n.a." when it genuinely can't tell (no network path, plugin absent from both sources). That third bucket matters as much as the other two: a tool that guesses "probably fine" when it can't check is worse than one that says so plainly.

That distinction is the difference between an audit result and a plan. "CONFLICT" alone tells you where to worry; "CONFLICT, but 3.11.1 on Packagist already fixes it" tells you what to do about it — bump the plugin first, then update the core, no surprises on window day. Across a whole retainer book that's the difference between a list of problems and an actual update order.

The fleet piece — where this is headed, not where it is yet

Today, running Upgrade Radar across a full client book still means running it once per shop — fast per shop, but still a loop you drive by hand. The natural next step, and the one that actually answers "can I plan thirty shop updates without opening thirty shops," is a fleet sweep: point the tool at the whole book in one pass and get a single readiness report back, sorted by which shops are clear to update, which have fixable conflicts, and which need a real look before the window opens. That's on the roadmap, not shipped yet — worth being upfront about, because a tool that overclaims what it does today isn't one worth trusting with your update calendar tomorrow.

What's shipped now already changes the arithmetic, though. If the per-shop audit drops from an afternoon to a couple of minutes, running it across ten or twenty shops back-to-back stops being the bottleneck it used to be — even before the fleet report exists as a single run. The ROI story agencies actually plan against is straightforward: replace N shops times hours times an agency's own hourly rate with N shops times a couple of minutes each, and the audit line on a maintenance retainer stops being the part nobody wants to bill for.

Until the fleet sweep ships, the loop looks like this: run the check once per shop, note the verdicts, move to the next one. Slower than a single fleet-wide run, still an order of magnitude faster than opening each shop by hand and reading composer.json line by line — and it's honest about which of those two things it is today.

Try it on one shop first

The best way to judge whether this fits your update workflow is to run it against a shop you already know the answer for — see whether the verdicts match what you'd have found by hand, and how long it actually took.