NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: System → Packages → Check For Updates → pick the channel (stable/long-term) → Download&Install.
2. CLI: /system package update check-for-updates then /system package update install
3. Separately update the bootloader afterwards: /system routerboard upgrade then reboot.
4. Verify: /system package print and /system routerboard print

Gotchas & notes

• RouterBOOT firmware is a second, separate upgrade. /system routerboard upgrade is skipped by almost everyone, and a stale bootloader causes odd behaviour after major RouterOS jumps. Always do both.
• The RouterOS 6 → 7 upgrade is a major migration, not a routine update: OSPF, VLAN, and wireless configuration models all changed. Read the release notes, take an export, and expect to rework config.
• Downgrading needs /system package downgrade (not install), and a config saved on a newer version will not load onto an older one.
• The long-term channel is the right choice for infrastructure you do not want to think about; stable moves fast.
• Take a binary backup and an export before upgrading — the export is your only option if the binary turns out to be version-incompatible.

Steps

1. Check the upgrade path first at the Fortinet Upgrade Path tool — you often must step through intermediate versions.
2. GUI: System → Firmware & Registration (or *System → Firmware*) → choose a version → *Backup config and upgrade*.
3. CLI: execute restore image tftp <image.out> <tftp-ip> — the unit reboots into the new image.
4. Verify: get system status

Gotchas & notes

• You cannot jump arbitrary FortiOS versions. Fortinet publishes a required upgrade path (e.g. 7.0.x → 7.2.x → 7.4.x) and skipping steps can mangle the config silently — policies and VPNs come back wrong rather than the unit failing outright. Use the official Upgrade Path tool every time.
• The GUI's *Backup config and upgrade* option is the right choice; it saves the config first automatically.
• Read the release notes for removed features and changed defaults — FortiOS minor versions do change behaviour (e.g. SSL-VPN handling and NAT defaults have both shifted between releases).
• Entry-level models sometimes drop support for a feature in a newer FortiOS due to resources; check the model is supported by the target version.
• HA pairs upgrade with set uninterruptible-upgrade enable for a rolling upgrade — otherwise both units reboot together.

Steps

1. Controller software: Settings → System → Updates (self-hosted: update the package/host OS; UniFi OS console: *Settings → System → Updates*).
2. Device firmware: Devices → select devices → Upgrade, or *Settings → System → Updates → Auto-update*.
3. Order matters: upgrade the controller first, then the devices.
4. Verify each device shows the new version and returns to *Connected*.

Gotchas & notes

• Upgrade the controller before the devices. A device on newer firmware than the controller supports can become unmanageable or get stuck adopting.
• Device firmware downloads come from Ubiquiti's servers by default — an air-gapped site needs manual firmware upload per device via SSH (upgrade <url>), which is painful. Plan for internet access.
• Auto-update is on by default in some setups and will upgrade production APs overnight. Turn it off for anything you care about, and pin a maintenance window.
• A UDM/UDM-Pro upgrade reboots the gateway, which drops the internet for several minutes — this is the whole network, not just management.
• Take a controller backup first; UniFi releases have historically included changes that alter firewall-rule semantics (notably the zone-based firewall migration).

Steps

1. Check space and copy the image: dir flash: then copy tftp: flash:
2. Verify integrity: verify /md5 flash:image.bin <expected-md5>
3. Point the boot variable: configure terminal → boot system flash:image.bin (IOS) or use install add file ... activate commit (IOS-XE install mode).
4. copy running-config startup-config then reload.
5. Verify: show version and show boot

Gotchas & notes

• Always verify /md5 the image before rebooting. A truncated TFTP copy that looks fine in dir will fail to boot and leave you in ROMMON with a console cable and a bad afternoon.
• IOS-XE has two modes: bundle (boot system with a single .bin) and install (install add file ... activate commit). Mixing the two is a common source of a device booting the wrong image — check show version | include Mode.
• Clear old boot statements: leftover boot system lines are tried in order, so a stale first entry boots the old image.
• Free space is a real constraint on older platforms; deleting the running image to make room is a mistake you cannot undo remotely.
• On a stack, all members must run the same version — show switch after the reload to confirm no member is in Version Mismatch.

Steps

1. Device → Software → *Check Now* → Download the target version → Install.
2. You must install every intermediate feature release's base image on the way up (e.g. to reach 11.1.x you download 11.0.0 base, then 11.1.0 base, then the target maintenance release).
3. Install the required content/App-ID update first — PAN-OS versions have minimum content versions.
4. Reboot when prompted. Verify: show system info | match sw-version
5. CLI: request system software download version <v> then request system software install version <v>

Gotchas & notes

• The base-image rule is the big one: you cannot install 11.1.4 without having downloaded the 11.1.0 base image, and you cannot skip a feature release (10.1 → 11.1 requires passing through 11.0). PAN-OS will let you download but not install out of order, and the error message is not obvious.
• Install the minimum required content release before upgrading PAN-OS, or the install is refused.
• Take an *Export device state* and note the current version — downgrades are supported but the config from a newer version will not load onto the older one.
• Each upgrade needs a reboot, and dataplane restart drops all sessions. On an HA pair, suspend the passive, upgrade, fail over, then upgrade the other.
• GlobalProtect clients and content updates have their own version dependencies — check compatibility matrices, not just the firewall version.

Steps

1. System → Update → System Update → confirm the branch → Confirm to upgrade.
2. Set the branch under System → Update → Update Settings.
3. Take a config backup first (Diagnostics → Backup & Restore).
4. Console alternative: option 13) Update from console.
5. Verify: the dashboard shows the new version.

Gotchas & notes

• Back up config.xml before every upgrade and keep it off-box. pfSense upgrades are usually clean, but a failed upgrade on a bare-metal box means a reinstall plus restore.
• Packages are the risk, not the base system. An installed package that is not yet available for the target version is removed or breaks; check package compatibility before upgrading, especially for FRR, pfBlockerNG, and HAProxy.
• pfSense CE and pfSense Plus are different products with different version numbering and update channels — do not follow Plus instructions on CE.
• The upgrade reboots the firewall, so the whole network is offline for a few minutes.
• For major version jumps on ZFS installs, take a boot environment snapshot first so you can roll back at the loader.

Steps

1. Download the target firmware image from MySonicWall first (the appliance does not fetch it itself).
2. Device → Settings → Firmware and Backups → Upload New Firmware, browse to the downloaded image.
3. Choose the boot mode carefully: Firmware and Current Settings (keeps config — the one you almost always want) vs Firmware and Factory Default Settings (wipes config on boot).
4. Take an Export Settings backup immediately before uploading, regardless of which option you pick.
5. If the box fails to come up cleanly, power-cycle or use the reset button to enter SafeMode, which lists the Current / Backup / Factory firmware images stored on the unit, each bootable with or without its saved settings — this is your rollback path.

Changed across versions

• 7.3.2 / 7.3.3This is the current Gen7 General Release line for TZ/NSa/NSsp hardware. Newer Gen8 hardware (TZ80, TZ280+, NSa 2800+) runs a separate SonicOS 8.x codebase with its own upgrade rules — the guidance above applies to Gen7 7.x, not 8.x.

Gotchas & notes

• Upload is a browser file transfer in the GUI — there is no TFTP/SCP/CLI push path for a typical admin. This surprises people coming from MikroTik or Cisco where you can stage firmware over the network without opening the web UI.
• Gen6 (SonicOS 6.5.x) appliances cannot run Gen7 (7.x) firmware at all — it's a hardware/codebase split, not an in-place upgrade, so there's no version-skip risk there; the risk is entirely within the 7.x line.
• Within 7.x, SonicWall does not hard-block large minor-version jumps the way some vendors block multi-step upgrades — always read that release's upgrade path notes on MySonicWall, since jumping several releases at once has been known to mis-migrate VPN and DPI-SSL settings silently.
• Picking Factory Default Settings on the upload dialog (instead of Current Settings) is the single most common self-inflicted config wipe on this platform.
• SafeMode auto-triggers after repeated failed/hung boots, which is a firmware-corruption safety net — it is not a 'confirm my config change or auto-revert' mechanism.

Steps

1. Insight-managed routers, Orbi Pro APs, and Insight-managed switches: Insight Cloud Portal → Locations → select location → Settings → Firmware, or select one or more devices → Update → choose Update Now or set a maintenance window (Start/End date-time, optional recurrence) so the push only happens off-hours.
2. Insight app equivalent: device → Firmware Update, or toggle Automatic Firmware Update with a schedule window under the location settings.
3. Smart Switches, offline path: if the switch can't reach the Insight cloud, log into its local HTTPS UI directly → Maintenance → Firmware Upgrade → upload the downloaded .stk/.bin image manually. The Lite CLI has no firmware-upgrade command at all.
4. M4200/M4300 (real CLI, dual-image): check which image is active with show bootvar, then upgrade the *inactive* image: copy tftp://<tftp-ip>/<image-file> image1 (or image2, whichever is not currently active) → after it verifies, set the newly-loaded image as next-boot with boot system active image1 (or image2) → reload. If the new image fails to come up cleanly, you can boot back to the other image slot.
5. GUI equivalent on M4300: Maintenance → Dual Image, upload a file, then set the *Next Active Image*.

Gotchas & notes

• Routers and Orbi Pro APs have no manual/local firmware path at all — the push comes exclusively from Insight cloud. If the WAN or Insight connectivity is down, you cannot upgrade the device; there's no CLI or local file-upload fallback like the switches get.
• NETGEAR's own KB documents a real 'skip too far and it fails' case: some Insight-managed WiFi 6 APs on firmware 9.x or older must first be manually staged through a specific intermediate version (e.g. 9.6.2.6 for WAX610/610Y) before the cloud auto-update will succeed — Insight does not warn you, the push just errors out.
• The M4300's dual-image slots are the closest thing to a safety net in the whole NETGEAR lineup: you upgrade the *inactive* image and keep the old one bootable, so a bad image can be rolled back by reselecting the other slot — but this is a manual choice, not an automatic revert-on-failure.
• Lite CLI switches and cloud-only routers/APs have zero equivalent of that image-slot safety net — a failed or interrupted push on those is a support-ticket/RMA situation, not a self-service rollback.
• 'Firmware upgrade' is genuinely three unrelated procedures on three device classes here: a cloud-scheduled push (routers/APs/managed switches), a manual local-GUI file upload (unmanaged/offline Smart Switches), and a CLI dual-image copy+reload (M4200/M4300).