FortiOS 8.0 Upgrade Playbook: A Pre-flight Checklist

FortiOS 8.0 is the most ambitious FortiGate release in years — Sovereign SASE, post-quantum crypto, AI-aware policy, FortiAI Assist. Most existing customers should not rush to upgrade. The ones who do skip the seven pre-flight checks that determine whether the upgrade lands clean. This is the playbook Ogma's NSE7 engineers walk through before signing off any production FortiGate cluster for 8.0.

If you have not yet read our FortiOS 8.0 announcement deep-dive, start there — that post tells you what 8.0 ships. This post is about whether and how to put it on your hardware.

Why You (Probably) Should Not Rush

FortiOS major releases follow a predictable maturity curve. Every series — 6.0, 6.2, 6.4, 7.0, 7.2, 7.4, 7.6 — shipped with rough edges in early builds and stabilised over the first two or three maintenance releases. Fortinet eventually publishes a per-model recommended "gold" build. The pattern will repeat for 8.0.

There are also genuine technical reasons not all hardware will get all of 8.0. Older NPU and SP5 chip variants do not accelerate the new post-quantum SSL inspection primitives in hardware. On those models, enabling the same security policy on 8.0 that worked on 7.6 can drop NGFW throughput by 30–60% — invisible until your peak-hour traffic hits. The cure is either a hardware refresh or careful feature deselection.

The Seven Pre-flight Checks

None of the seven is optional for a production HA pair. Each is a 30-minute job; together they take a single engineer maybe one working day. Skipping any one of them is how an "easy upgrade" turns into a four-hour incident.

# What model am I actually running?
get system status
# For HA pairs — confirm both members
diagnose sys ha checksum cluster

# Which NPU / SP5 chip variant?
get hardware status
# Which UTM features are actually enabled per policy?
show firewall policy | grep -E "utm-status|ssl-ssh-profile|ips-sensor|application-list"

# Capture a full config snapshot before upgrade
execute backup config tftp pre-upgrade-7.6.x.conf 10.x.x.x
# Local copy via SCP also works:
execute backup config flash pre-upgrade-7.6.x.conf

# Confirm both partitions before upgrade
get system status | grep -E "Version|Branch|Partition"
diagnose sys flash list
# Switch active partition (use only as the rollback step!)
execute set-next-reboot primary | secondary

# Pre-upgrade HA health check
get system ha status
diagnose sys ha checksum cluster
# Synthetic failover post-upgrade (run from current primary)
execute ha manage 1
# Verify the other unit took over cleanly, then fail back.

Should You Upgrade Now? A Decision Matrix

A Realistic Project Timeline — One Week, Done Right

For a mid-size Indian enterprise with 5–15 FortiGate units across HA pairs, branches and a couple of cloud VMs, this is a one-week engagement when the prep is honest and the team is ready. The seven pre-flight checks still happen — they just compress into the front of the week instead of stretching across a quarter.

• Day 1 (Mon) — Inventory, eligibility, lab build. Pull model + version + HA topology of every unit. Cross-check against EoS dates and the 8.0 supported-models list. Sequence the rollout (lab → pilot branch → remaining branches → core HA pair). Stand up the lab unit on the same hardware family as your largest production cluster. Snapshot every config.
• Day 2 (Tue) — Lab validation + pilot site cutover. Walk all seven pre-flight checks against the lab unit. Capture before/after benchmarks. Same evening, upgrade one tolerant branch in a planned window. Watch traffic for 12 hours.
• Day 3 (Wed) — Branch rollout. Push the remaining branches in two waves with a 2–3 hour gap between waves. Each upgrade follows the documented runbook from the lab. Two engineers on the bridge throughout.
• Day 4 (Thu) — Soak day. No new upgrades. Engineers monitor the upgraded estate end-to-end: VPN tunnel state, IPS engine health, SSL inspection latency, BGP/OSPF stability, FortiAnalyzer log volume. Any anomaly buys a rollback decision before the core pair touches 8.0.
• Day 5 (Fri night → Sat morning) — Core HA pair upgrade. Out-of-hours window. Two engineers minimum. Synthetic failover validation post-upgrade. Documented sign-off. Customer-acceptance email before the team logs off.

This is aggressive but achievable if — and only if — the lab unit is ready before Monday and the team has done a FortiOS major-version upgrade before. If either is in doubt, push the window. A one-week upgrade with skipped lab validation is not a one-week upgrade — it's a one-week outage waiting for a trigger.

✅ Key Takeaways

1. Wait for the first maintenance release for production HA pairs. Lab and non-prod can move sooner.
2. Check hardware eligibility before anything else. If your model is past EoS or not on the 8.0 supported list, this is a refresh decision — not an upgrade decision.
3. Audit feature compatibility against your NPU / SP5 variant. Hardware-accelerated 7.6 features can drop to software-mode on 8.0 with the same chip — invisible until peak hour.
4. Lab on identical hardware family. Not a different model. Not a VM. Same chassis class, same NPU.
5. Use the alternate firmware partition for rollback. Flash-and-switch gets you a 3–5 minute rollback window. Keep the old image on disk for 30 days.
6. HA pair upgrade is a known-good procedure. Verify cluster health pre and post. Always run a synthetic failover before declaring success.
7. 72-hour soak before sign-off. Most subtle bugs surface in the first three days under real traffic.