Network Firmware Upgrade Checklist: Switches, Firewalls and Access Points, Step by Step

The short version: Upgrade network firmware like any other change: read the release notes, back up the configuration, keep the old image ready, upgrade in a planned window, and test against a written list before you declare it done. Do one device (or one half of a pair) first, never everything at once. The rollback decision is made before the window starts, not during it.

This checklist is for IT managers and engineers who look after a small or mid-sized network of switches, firewalls and wireless access points. After reading it you can run an upgrade with a written plan, a time limit for going back, and a test list you can hand to someone else.

The values below (time slots, wait times) are starting points. Adjust them to your environment and to your vendor's guidance.

Before you start: what to decide first

1. Why are you upgrading? A security fix, a bug that affects you, a feature you need, or end of support. If there is no reason, a device that works can wait for your next scheduled cycle.
2. What is the target version? Take the version the vendor recommends or marks as stable, not simply the newest file on the download page. Our patch management process guide covers how to set the cycle.
3. Which device goes first? Pick the least critical one that runs the same model and role. A spare switch or a branch-office access point is a good pilot.
4. Who approves and who is on call? Name the person who may call a rollback, and the person who tells users.

Pre-upgrade checklist

Complete items 1 to 10 the day before, not at the start of the window; send the notice (item 11) at least two working days ahead.

1. Read the release notes for the target version: known issues, changed defaults, removed features, minimum memory or storage, and required intermediate versions.
2. Check the upgrade path. Some products cannot jump from an old version to a new one in one step. Vendors publish this: Fortinet, for example, provides an upgrade path tool and advises following the validated path hop by hop and checking the release notes of each hop (checked 28 October 2026).
3. Confirm hardware support for the model and hardware revision, and that your licence or support contract is active where the vendor requires it to download.
4. Download the image from the vendor's official support site, signed in to the official portal, and check the file hash where the vendor publishes one.
5. Back up the running configuration and export it to a location off the device. For firewalls also export licence and certificate details if the vendor says they are separate.
6. Keep the current firmware image so you can reinstall it. Store it with the config backup, named with the version and date.
7. Record the current state: firmware version, uptime, number of active ports and links, VPN tunnels up, Wi-Fi clients per access point, and the list of VLANs. You will compare this after the upgrade.
8. Check storage and memory on the device. Many upgrades fail because there is not enough available flash space.
9. Check power and cabling: UPS in good state for the closet, console cable and console access working, and out-of-band access ready if you have it.
10. Find redundancy. Is there a stacked partner, a high-availability pair or a second uplink? Know how the upgrade of a pair is meant to proceed according to the vendor.
11. Notify users at least two working days before for core devices.

A useful hash check on Windows:

Get-FileHash .\firmware-image.bin -Algorithm SHA256

Compare the output with the hash on the vendor's download page, where one is published.

Choosing the maintenance window

1. Pick the quietest period from your own traffic and ticket history, often early morning on a weekday for offices, or a weekend for sites that run on weekdays.
2. Allow enough time. A plausible plan for one switch: 10 minutes preparation, 15 to 30 minutes for the image to load and the device to reboot, 20 minutes testing, and a stop point at which you roll back. Firewalls and wireless controllers usually need longer. Treat these as examples and use the vendor's stated times.
3. Set the go-back time in advance. For example: if the device is not passing traffic 30 minutes after the reboot, roll back. Write the clock time on the plan.
4. Avoid peak business events, month-end processing, and anything that overlaps another change.
5. Have a second person present or on the phone. One person changes, one watches the checklist.

Upgrade order

1. Pilot device first. Wait a day or longer before the rest if the pilot carries real traffic.
2. Follow the vendor's documented order. Where there is none, pilot a low-risk edge device first. For controller-managed Wi-Fi, upgrade the controller first, then the access points through it.
3. One half of a pair at a time. For stacked switches or HA firewall pairs, follow the vendor's documented procedure, and confirm the first member is healthy before the second.
4. Do not upgrade the device you use to reach the others until last, or have another way in.
5. Do not mix big changes. Do not change firmware and re-design VLANs on the same night.

During the upgrade

1. Set a maintenance flag in your monitoring, or take the device out of the alert path, so alerts do not flood your inbox.
2. Save the config again and confirm the backup file is readable.
3. Start a continuous ping to the device and to a host behind it, so you can see the exact outage time:

ping -t 10.0.0.1

1. Load the new image and set the boot image as the vendor describes. Keep the old image on the device as a fallback if it has room.
2. Reboot, and watch the console if you have it. Log the time of each step.
3. Do not interrupt a reboot or power off while it is writing flash.

Post-upgrade verification

Compare against the state you recorded earlier.

1. Version: the device reports the target version.
2. Interfaces: the same ports and uplinks are up; no new errors or flapping.
3. Layer 2: VLANs present, trunks carrying the right VLANs, spanning tree stable and the same root as before.
4. Layer 3: routes, default gateway and routing neighbours restored.
5. Firewall: policies loaded, NAT working, VPN tunnels up, and a test from an inside host to the internet and to a published service.
6. Wireless: clients associate on each SSID, roaming works, and the controller shows the access point as joined.
7. Services through the device: DHCP, DNS, authentication (RADIUS), and a business application.
8. Management: logs go to your log server, monitoring sees the device, and SNMP or API checks respond.
9. Configuration: save it, take a fresh backup, and compare with the earlier one for unexpected changes in defaults.
10. Monitor for 24 hours, looking at error counters, CPU and memory, and the ticket queue.

Rollback plan

Write this before you start.

1. Triggers: the device does not boot, does not pass traffic by the go-back time, a critical service fails, or the issue cannot be explained within the time you set.
2. Method: boot the previous image, or reinstall the saved image, then restore the saved configuration if the new version changed its format. Follow the vendor's procedure for downgrades, because some do not support downgrading without a configuration reset.
3. Access: console or out-of-band access tested before the window.
4. Spare: a spare device of the same model, pre-loaded with the old firmware, for the worst case.
5. After rollback: verify with the same test list, tell users, and record why it failed before you try again.

Common mistakes

1. Upgrading to the newest file without reading the release notes. Read the notes and take the vendor's recommended version.
2. Skipping intermediate versions the vendor requires. Follow the documented path.
3. No tested way back in. If the device does not come up and you have no console access, a short window becomes a site visit. Test access first.
4. Upgrading both members of a pair together. Do one, verify, then the other.
5. Backing up to the same device. A backup that lives only on the box you are upgrading is not a backup.
6. No record of the before state, so you cannot tell whether a problem is new.
7. Changing several things at once, which makes the cause of any fault unclear.

How to check it worked

1. The version matches the target and the hash of the image matched the vendor's.
2. Every item in the post-upgrade list passes, and the results are written down next to the before-state.
3. No new alerts or error counters rise over the following day.
4. Users report no change in speed, Wi-Fi roaming or VPN behaviour.
5. The backup taken after the upgrade is stored with the old one.

FAQ

What are firmware upgrade best practices?

Read the release notes, follow the vendor's upgrade path, back up the configuration, keep the old image, upgrade in a planned window with a set rollback time, start with a pilot device, and test against a written list afterwards.

What is firmware?

Firmware is the software stored on a device, such as a switch, firewall or access point, which controls how its hardware works. It is updated by loading a new image from the vendor.

What are the steps to upgrade a switch?

Back up the configuration, download and verify the image, check available flash space, load the image and set it as the boot image, reboot in the window, then verify ports, VLANs, spanning tree and uplinks. Use the vendor's own commands for your model.

Where should I download firmware from?

From the manufacturer's official support portal for your exact model and hardware revision, and check the published hash. Do not use copies from forums or file-sharing sites.

Next step

If you would rather have planned maintenance windows, backups and rollbacks handled for you, see our network hardware maintenance service.

Sources checked 28 October 2026: Fortinet Upgrade Path Tool (docs.fortinet.com/upgrade-tool).