Hi  @Tintronic 

Thanks for posting here. Sorry to hear about the unsatisfactory upgrade experience. Below are some explanations and suggestions regarding the issue you mentioned.

1. “Global” centralized upgrades are meant for multi-site control and risk reduction
   In multi-site, multi-model environments, a purely “click a device to upgrade” workflow can easily lead to selecting the wrong site/model, pushing an incompatible build, or saturating a site’s limited bandwidth—causing widespread outages.
   Centralizing the entry point in Global and requiring model/version/ selections is intended to reduce errors and enforce consistent rollout policies.

2. Upgrade concurrency (queue) limits are there to prevent self-inflicted outages
   Firmware upgrades usually reboot devices and can interrupt links. If too many switches/APs are upgraded at once, the controller may lose network connectivity mid-upgrade, resulting in a worst-case “half-upgraded, site offline, hard to recover” scenario.
   A low concurrency limit (e.g., the “4 devices” you observe) is commonly used to:

• reduce controller CPU/IO/storage load (package hashing, distribution, polling)
• prevent simultaneous reboots on the same topology path from breaking the management plane
• Avoid consuming WAN uplink bandwidth when many sites share one controller

3. The old “topology-aware batch upgrade” is harder to guarantee in complex topologies
   In environments with multi-hop wired links, bridging, mesh, and multiple sites under one controller, topology discovery can be incomplete or change dynamically (especially with mesh/bridged links).
   If the controller cannot reliably confirm dependencies, an “auto topology batch upgrade” is more likely to reboot an upstream device first, interrupting downstream upgrades—which shows up as “batch upgrade failed.”

4. “Not upgrading straight to the latest, only to the next version,” is often due to upgrade-path requirements
   Some devices/firmware trains require step upgrades due to bootloader changes, configuration database migrations, or security module updates. Skipping required intermediate versions can risk bricking or losing configuration.
   So the system may intentionally choose the “next recommended hop,” which keeps the device appearing “upgrade pending” afterward.

Recommendations

1) Split upgrades into “site windows + groups + low concurrency.”

• Use a maintenance window per site (off-peak). Avoid pushing all sites globally in one run.
• Within each site, upgrade in layers:
  1. edge devices / APs / downstream access switches
  2. distribution/aggregation switches
  3. gateway / upstream core last
     This manually recreates a safer order even if the “topology-smart batch upgrade” behavior isn’t available.

2) Plan for staged upgrades: align to an intermediate recommended version first

• If a model is several versions behind, first bring it to a recommended/stable intermediate release, then move to the latest.
• Practically: pick the Recommended/Stable build for that model (if shown), not necessarily the newest one, as the first step.

3) Improve the success rate by removing controller-to-device blockers

Even on local sites, many “mass failures” come down to these:

• consistent routing/ACL/firewall rules between controller and device management subnets (especially across VLANs/subnets)
• DNS and time sync health (can affect downloads, validation, logs)
• controller storage space and overall health (firmware cache/log/database growth can slow task scheduling)
• for mesh/bridged devices: upgrade only when links are stable/good quality, and prioritize nodes closer to the wired backbone

4) Use a “small validation → rolling rollout” rhythm

• Upgrade 1–2 devices per model first to confirm:
  • they come back online/adopted properly
  • VLAN/SSID/ACL behavior is unchanged
• Then expand to rolling groups at the allowed concurrency (e.g., 4 at a time). It’s tedious, but it’s also the safest approach from a risk-control standpoint.