·10 min read

How to upgrade FortiGate firmware safely

Firmware upgrades are where small problems become outage problems. A FortiGate that's been quietly running for two years can absolutely brick itself on a botched upgrade — usually because someone skipped a step, missed a release note, or didn't have a rollback plan.

This guide walks through a pre-flight checklist used by network engineers who do this for a living, plus the most common failure modes that turn a 10-minute maintenance window into a 4-hour incident.

The five-step pre-flight checklist

Before you click "Upgrade":

1. Read the release notes

Specifically, look for:

  • Upgrade path requirements. FortiOS major versions often can't skip — going from 7.0.x to 7.4.x usually requires landing on a specific 7.2.x release in between. The release notes spell this out; ignoring it is the #1 cause of "the box won't boot" tickets.
  • Known issues. Fortinet publishes known regressions per release. If your deployment uses a feature listed as broken, wait for the next patch.
  • Removed features. Major versions occasionally deprecate or remove features. If you're using one, your config doesn't carry forward.
  • Changed defaults. Sometimes a default flips between versions (e.g., a session lifetime gets shorter). If your network depends on the old default, you need to set it explicitly before upgrading.

2. Back up the configuration

Two backups, two ways:

  • Encrypted backup with password (saves cleanly, restores cleanly)
  • Plain-text export (lets you diff and grep in a text editor when something's wrong)

Store both on a machine that is NOT this firewall. If the firewall is the only place the backup lives, the backup is useless.

3. Check current uptime and stability

If the firewall has been crashing, hanging, or showing kernel panics in the logs, don't upgrade yet. A flaky firewall mid-upgrade is more likely to corrupt itself. Stabilize first (often this means a clean reboot first, watch for 24-48 hours, then upgrade).

4. Plan the rollback path

For physical FortiGates, FortiOS keeps a backup partition with the previous firmware. You can fail back from console — but only if you have console access. Confirm console access works before starting, especially for remote or co-located gear.

For HA pairs, the rollback is "fail back to the secondary unit that's still on the old firmware." That requires upgrading the secondary first, monitoring, then upgrading the primary. Standard HA upgrade pattern.

5. Schedule a real maintenance window

A FortiGate upgrade involves:

  • 5-15 minutes of reboot during which all traffic is dropped
  • A brief period of "feature is back but tunnels are renegotiating"
  • A final period of "everything settled but let's watch for 30 minutes"

Plan for at least a 60-minute window. If users complain about being offline at 11 PM Tuesday, "the firewall was upgrading" is a fine answer. "The firewall was upgrading and that's why your demo to the customer at 11 AM failed" is not.

During the upgrade

Standard sequence on the web GUI:

  1. Connect via HTTPS and confirm you can also reach the box via SSH (have a second tab/terminal already authenticated — if the GUI hangs, you'll need it)
  2. Take a fresh config backup right before clicking Upgrade
  3. Upload the firmware image
  4. Confirm the firmware checksum if Fortinet publishes one
  5. Click upgrade — the GUI will warn you about the reboot
  6. Wait. Don't reload the page, don't power-cycle, don't get curious

If the box doesn't come back online within ~15 minutes, the rollback path is console-only: connect to the serial console, interrupt boot, switch to the backup partition, boot from the previous firmware.

Common ways this goes wrong

Upgrading from 6.x straight to 7.x. Most major version jumps require landing on the highest patch of the previous major first. Skip a step and you end up with a partial config migration.

Forgetting that VPN tunnels need re-key. Phase-1 IPsec tunnels usually survive; phase-2 can need a renegotiation. SSL-VPN sessions get dropped. Plan for VPN reconnects.

Upgrading both HA members at once. Always upgrade the secondary first, fail over, watch the secondary on the new firmware for at least 15 minutes, then upgrade the primary. Upgrading both at once = both rebooting = total outage.

Letting auto-update do it for you on production. FortiCare can auto-push patch releases. On critical hardware, disable auto-update. You want every upgrade to be a planned, supervised event.

Not retaining the previous firmware image. If you delete the prior image after upgrade and the new version is broken, your rollback path is broken too. Keep the previous version on hand for at least 30 days.

After the upgrade

In order:

  1. Verify the version (get system status from CLI, or check the dashboard)
  2. Confirm sessions are routing — both inbound and outbound
  3. Reconnect VPNs — manual reconnect for any that didn't come back automatically
  4. Re-run policy verification — pick 5-10 known good policies, confirm they still match
  5. Check logs for new errors that weren't there pre-upgrade
  6. Watch for 24-48 hours — most regressions surface in the first day

Document what you changed, when, and who approved it. A line in your change-management log of "FortiGate 60F upgraded from FortiOS 7.2.5 to 7.2.7 at 2026-06-09 23:00 UTC by [name], no issues" is the artifact that saves the next on-call.

When to call for help

Two scenarios:

  • You can't reach the firewall at all post-upgrade. Don't try to fix it remotely if you've lost all access — get hands-on console immediately, even if that means driving to the site.
  • Anything important is broken and you have a FortiCare Premium or Enterprise contract. That's what you pay the contract for. Open a TAC ticket as soon as you've stabilized.

For Firewall Junction enterprise customers on a bundle (-BDL-809 or -BDL-950), see our bundle primer for what your contract covers. For pre-upgrade quote questions, browse the Fortinet catalog or message your account manager.

Next steps

← More buyer's guidesBrowse the catalog