Upgrade FortiGate Firmware Without Losing Connectivity

Before you run this

This guide walks a standalone FortiGate through a firmware upgrade — checking the supported upgrade path, backing up config, flashing the new image, and verifying it — with the least possible disruption. A firmware upgrade reboots the unit. On a single (non-HA) FortiGate there is no way to avoid a short traffic outage during that reboot; "without losing connectivity" here means without locking yourself out and without losing your configuration, not zero downtime. Only an HA pair gives you a near-seamless upgrade, and that is a different procedure (noted at the end).

You need super-admin (prof_admin / full access) credentials on the FortiGate. There is no OS-level sudo here; the equivalent is an administrator account with write access to system settings.

Do this in a maintenance window, and before you touch anything:

Keep an out-of-band path open — the physical console port (RJ-45/USB console cable) or a dedicated OOB management interface. A bad firmware jump, a config that doesn't migrate cleanly, or a reboot that hangs can drop your SSH/HTTPS session. Console access is your lifeline.
Back up the running configuration first (Step 4). This is irreversible insurance: downgrading firmware often resets the FortiGate to factory defaults, so the only clean way back to your old setup is old-image + restored config.
Read the release notes for the exact target build. They list known issues, feature changes, and — critically — the supported upgrade path. Skipping intermediate versions can corrupt the config migration.
Test first where you can. If you run more than one FortiGate, upgrade a lab unit or a lower-tier site before your core firewall. If you have a VM (FortiGate-VM) of the same model family, rehearse there.

Rollback path on this platform: the FortiGate holds firmware in two partitions and keeps your previous image, but the reliable, documented rollback is to re-flash the prior firmware and restore the config backup you took — covered at the end.

Assumptions

A single FortiGate running FortiOS 7.4, managed over HTTPS (GUI) and SSH (CLI).
You have console access and an admin account with full rights.
You have (or will set up) a TFTP server reachable from the FortiGate for the CLI method, or you will use the GUI upload method — both are shown.
The unit is not in an HA cluster. (HA note at the end.)

Menus and CLI keywords move between FortiOS releases, so if anything below doesn't match your unit, check the FortiOS 7.4 Administration Guide on docs.fortinet.com rather than guessing.

Step 1 — Record what you're running

From the CLI:

get system status

Note the Version line (model, FortiOS version, and build number) and the Serial Number. You'll need the exact model and current build to plan the path and to download the right image — firmware is model-specific.

Step 2 — Determine the supported upgrade path

Do not jump straight to the newest release. Fortinet publishes an Upgrade Path Tool on docs.fortinet.com: enter your model, current version/build, and target version, and it returns the ordered list of intermediate builds you must pass through. Follow it exactly. If it says 7.0.x → 7.2.x → 7.4.x, you flash each step and let the config migrate at each hop.

Read the release notes for each target build in that chain (also on docs.fortinet.com) for model-specific caveats.

Step 3 — Download the firmware

Log in to support.fortinet.com → Download → Firmware Images, select your product/model, and download the image that matches your model exactly (for many mid-range models the file ends in .out). Verify the file's checksum against the value shown on the download page before you use it — a truncated image will brick the boot.

Step 4 — Back up the configuration (do not skip)

GUI: the configuration backup/restore controls live under the admin (top-right) menu in FortiOS 7.4; choose to back up the full configuration to your PC. If you're unsure where it is on your build, the Administration Guide → "Configuration backups" section has the current path.

CLI, backing up to a TFTP server:

# Replace the filename and TFTP server IP with yours
execute backup config tftp fgt-preupgrade-2025-05.conf 192.0.2.10

Save the backup file somewhere off the box. If your config is encrypted with a password, record that password — you cannot restore without it.

Optional but wise: also export a copy of your admin certificate/VPN details and note any interface IPs, so a factory-reset scenario doesn't leave you guessing.

Step 5 — Upgrade

Pick one method. The GUI is the mainstream path for a single unit; the CLI/TFTP method is the standard fallback and what you'll use from the console if the GUI is unreachable.

Option A — GUI (recommended for a standalone unit)

Go to System → Firmware.
Choose to upload firmware from your local disk, and select the image file from Step 3.
The GUI will show the version you're moving from and to. Confirm it matches your planned path step.
Start the upgrade. The unit uploads the image, writes it to the inactive partition, and reboots automatically. Expect a few minutes of downtime; do not power-cycle it during this window.

Option B — CLI over TFTP (console-friendly fallback)

With your console open and the image on your TFTP server:

# Pulls the image and installs it; the FortiGate reboots on its own afterward
execute restore image tftp <firmware-file.out> 192.0.2.10

Confirm at the prompt. The device flashes the image and reboots. Watch the console for the boot sequence.

If your path has multiple hops, complete Steps 3–5 for each intermediate build in order, letting the config migrate and the unit come fully up between hops.

Step 6 — Verify

After it reboots and you can log in again:

get system status

Confirm the Version and build number now match your target. Then sanity-check that the box is actually passing traffic and the config survived migration:

Interfaces are up and hold their addresses: get system interface physical
Routing is intact: get router info routing-table all
Sessions are being built: diagnose sys session stat
Spot-check that key policies, VPNs, and VIPs are present in Policy & Objects and VPN — a bad migration usually shows up as missing or disabled objects, not a total wipe.
Skim Log & Report (or the console) for boot-time errors.

If everything is green and traffic flows, you're done.

Rollback

If the new build misbehaves:

From the console, re-flash the previous firmware image using the same GUI (System → Firmware) or CLI (execute restore image ...) procedure, pointing at the old image you kept.
Because a downgrade commonly resets the config to defaults, restore your Step 4 backup afterward. GUI: the restore option next to backup under the admin menu. CLI:
```
execute restore config tftp fgt-preupgrade-2025-05.conf 192.0.2.10
```
The unit reboots into your pre-upgrade configuration.

The FortiGate does keep the prior image in its second partition and can boot from it via the console boot menu during startup; the exact keystroke and partition-selection command vary by model, so use the Administration Guide → "Booting from the alternate partition" section rather than a remembered command. Re-flash + config-restore is the method that works the same on every model, which is why it's the one I lean on.

If this is an HA pair

Don't follow the standalone steps. FortiOS can perform a graceful (uninterruptible) HA upgrade where cluster members upgrade and fail over one at a time, keeping traffic up. The behaviour is controlled by an HA upgrade setting under config system ha; consult the FortiOS 7.4 HA guide for the exact directive and the current recommended procedure before you start, and still take the config backup and keep console access to both members.