One version per model; pilot one unit for 24 hours
Export the config and keep the rollback image ready
Never upgrade during peak; major versions may need reconfiguration
01 Upgrade process
-
1 ① Back up configuration
Export the running configuration; most models support a config file so you can roll back quickly.
-
2 ② Match version to hardware batch
Different hardware revisions may need different images; flashing the wrong one bricks the unit. Follow the vendor compatibility table.
-
3 ③ Pilot a single unit
Upgrade one non-critical unit and watch it for 24 hours: uptime, speed, roaming, reboot count.
-
4 ④ Roll out in batches
Do it floor by floor or zone by zone so the whole site never reboots at once, and verify between batches.
-
5 ⑤ Record and regression-test
Record version and date, then re-test roaming, rate limiting and portal authentication.
02 Three hard rules
- One version per model per project — mixed versions break roaming and central management.
- Do not upgrade just because it is newest — stay on the stable release unless a fix affects your traffic.
- Schedule outside peak hours and keep the rollback image ready.
03 Common risks
| Risk | Prevention |
|---|---|
| Power or link loss mid-upgrade | Confirm stable PoE and power; avoid remote upgrades on wireless backhaul units |
| Wrong hardware revision | Confirm the correct image by serial number with the vendor |
| Configuration lost | Export the config or screenshot key pages first |
| Performance regression | Pilot for 24 hours and re-test before rolling out |
Questions
Q1 Should firmware be updated regularly?
As needed: apply security fixes promptly and plan feature updates in a window. Do not chase new releases on a stable production network.
Q2 Does an upgrade require reconfiguration?
Within a major version the configuration usually survives; across major versions it may need rebuilding. Check the release notes.
Related knowledge
Need firmware and release notes for a specific model?