UniFi's default update behavior is convenient in a home and dangerous in a school: devices update themselves, usually early in the morning, and the first report is a classroom where nothing connects.
Firmware is a change like any other. It deserves a window, a test device, and a rollback path.
Release channels
| Channel | Meaning | Use |
|---|---|---|
| Stable | Vendor-tested, slower cadence | Production |
| Early access | Newer, less tested | Lab, never a classroom |
The controller lets you choose a channel per device class. Set stable everywhere, and keep one spare AP and one spare switch on early access if you want to see what is coming.
Version compatibility
Two version relationships matter:
- Controller vs device. A controller can manage older firmware, but a device may require a minimum controller version. Upgrading devices ahead of the controller is how you get "adoption failed."
- Upgrade path. Some major versions require an intermediate step. Read the release notes for the path, not just the target.
Record the controller version and the per-model device versions in the same place as the backups.
Staging a rollout
1. Read the release notes: behavior changes, known issues, fixed CVEs.
2. Update one non-critical AP. Verify clients reconnect, throughput unchanged.
3. Update one building after 17:00. Watch client counts and retries for an hour.
4. Update the rest in waves of one building per night.
5. Keep the previous firmware file for each model.
The upgrade itself takes minutes per device. The waves are what keep a bad release to one building.
Auto-update at 07:00 is a change during class
If updates are scheduled by the controller, set the window to something like 01:00–04:00 and exclude the first week of school and assessment windows. An update that runs at 07:40 is indistinguishable from an outage you caused.
Rollback
UniFi supports manual firmware upload per device. The mechanics:
| Step | Note |
|---|---|
| Obtain the previous firmware for that exact model | Vendor download page, archived |
| Upload via the device's manage panel | Requires the device to be reachable |
| Expect a reboot and a brief loss of adoption | Do it in a window |
| Verify the version and the config | Some settings are version-specific |
Downgrades across major versions are not always supported, and a device that downgrades may not accept a newer configuration. That is why the previous firmware is archived before the rollout, not looked up during the incident.
Worked example: an AP fleet update
197 access points, a new stable release, and one known issue in the notes about 6 GHz.
- Notes review: the 6 GHz issue affects the Wi-Fi 7 models only.
- Pilot: two Wi-Fi 6 APs in the admin building. No issues.
- Wave 1: one elementary, all APs, after 17:00. Client counts recover within ten minutes.
- Wave 2–4: one building per night, checking the controller's client count each morning.
- Wi-Fi 7 APs held back until the vendor publishes a fix.
Holding back a subset is not failure; it is the reason to read the notes.
What breaks in production
- Auto-update enabled globally, so a release lands during a school day.
- Controller upgraded first, leaving devices unsupported until they catch up.
- No archived firmware, so rollback becomes a support ticket.
- Mixed firmware across a roaming domain, producing association failures that look like RF problems.
- Early-access builds in production, which is how a district becomes the vendor's test lab.
Checklist
- Every device class is on the stable channel.
- Automatic updates are scheduled outside school hours, or disabled.
- The previous firmware for each model is archived.
- Release notes are read before any rollout, not after.
- Rollouts go pilot → one building → waves.
- Controller and device versions are recorded with the backups.
Next
That completes the UniFi playbooks. The next series in the queue is Packet Analysis, where the controller stops being the source of truth and the capture starts.