A firmware upgrade on one access point and a VLAN move across a campus are both "network changes." One is reversible in ninety seconds and affects a hallway; the other can take a building offline and has no undo button.

Change management is mostly the discipline of noticing that difference before you start.

Estimate the blast radius

Four questions, in order:

Question Low risk High risk
Who is affected? One AP, one closet A building, a district
What depends on it? A single SSID DNS, DHCP, routing, authentication
How long is the exposure? Seconds Minutes to hours
Can it be reversed? One setting A restore from backup

A change that is high on any two of those deserves a written plan and a second pair of eyes. One that is high on all four should be scheduled like a construction project.

Four checkpoints: before, during, after, and the next day.

The plan, one page

What:      move 10.40.50.0/24 into the Guest zone
Why:       guest traffic currently reaches internal servers
Window:    Thursday 17:15–17:45
Affects:   guest Wi-Fi at MHS only (~40 devices)
Pre-checks: policy hits zero; test guest device on hand; config backup taken
Steps:     add allow rules → move network → verify → move remaining guests
Verify:    lease, DNS, browse, cannot reach 10.0.0.3; policy hits increment
Rollback:  move network back to Internal (one setting)
Tell:      John (director), help desk, campus tech

If you cannot fill in the rollback line, you are not ready.

Choose the window honestly

  • After 17:00 on weekdays works for most changes, and the district already uses it.
  • Avoid assessment windows. State testing is a no-change period, not a suggestion.
  • Avoid the night before the first day of school, and the week of device hand-out.
  • Prefer Tuesday or Wednesday over Friday, so a problem surfaces while people are working.

The window is not just about users; it is about having support staff awake if it goes wrong.

One change at a time

Bundling changes is the most common self-inflicted complication. If three things change and something breaks, you have three suspects and no way to isolate.

The exception is a change whose parts are meaningless alone — a policy and the network move it depends on — and even then, apply them in a defined order and verify between steps.

"Temporary" is a change with no owner

A rule added during an incident, a route to a test device, a port opened for a vendor: each is a change. Write it down with a removal date, or it becomes permanent configuration that nobody can explain in two years.

Verify with the service, then watch

Stage Action
Before Take a config snapshot and record the current state
During Change one thing, note the time, test immediately
After Run the service tests from the plan, not a ping
+1 hour Check error logs and policy hits
+24 hours Confirm no delayed failure (leases, sessions, certificates)

The 24-hour check catches the failures that only appear when a lease renews or a session re-establishes.

Worked example: firmware upgrade

Low blast radius if done per building, high if done everywhere at once.

  1. Read the release notes for behavior changes, not just security fixes.
  2. Upgrade one non-critical AP; verify clients reconnect and throughput is unchanged.
  3. Upgrade one building after 17:00; watch client counts for an hour.
  4. Schedule the rest in waves of one building per night.
  5. Keep the previous firmware available for rollback, and know the procedure before you need it.

The upgrade itself takes minutes. The plan is what makes it a maintenance task instead of an incident.

What breaks in production

  • No rollback. The change is applied and the previous configuration was not saved.
  • Bundled changes. Three fixes, one outage, three suspects.
  • Verification by ping. The service is broken and the network is "up."
  • No communication. The help desk learns about the outage from users.
  • Temporary changes without an expiry, which accumulate into a configuration nobody understands.
  • Changing during a testing window, which turns a technical problem into an administrative one.

Checklist

  1. Every change has a one-page plan with a rollback line.
  2. Blast radius is estimated on users, dependencies, duration, and reversibility.
  3. The window avoids assessments, first days, and Fridays.
  4. One change at a time, verified between steps.
  5. The help desk knows what is happening and when it will be done.
  6. A 24-hour follow-up is scheduled, not assumed.

Next

Operations continues with the multicast article already published. The next series is the one closest to daily work: UniFi Playbooks.

  • Change Control
  • Rollback
  • Risk
  • Communication