The upgrade path: why you cannot skip a version on FortiOS, GitLab or Proxmox

Going from FortiOS 6.4.9 to 7.6.4 takes six installs, not one. That is not an opinion — it is what Fortinet’s own Upgrade Path Tool returns for a FortiGate-60F: 6.4.9 → 6.4.11 → 7.0.12 → 7.0.14 → 7.2.10 → 7.4.7 → 7.6.4 (queried 19/08/2026). Two of those hops do not even leave the branch they start in. Load the target image directly instead and you have not saved a maintenance window — you have traded it for an incident with no scheduled date.

An upgrade path is the ordered list of versions you must install to get from where you are to where you want to be. It is not the same as “every version in between”: vendors validate specific point-to-point transitions, and the path is the shortest route through that tested graph. Fortinet is open about the trade-off — “Other paths may work, but only the shortest validated path is shown.” Anything outside the graph is not forbidden, it is untested, which in production amounts to the same thing.

Break one: the configuration is never translated

On a firewall the configuration is not an accessory, it is the product. Each FortiOS release ships schema changes and converts the previous release’s configuration on first boot. Fortinet’s pre-upgrade checklist in the Firmware Upgrade Guide spends exactly one sentence on it: “Skipping intermediate versions may cause configuration issues.” The uncomfortable part is that the device comes up anyway. It boots, it routes, the dashboard is green. What is missing is missing quietly, and the people who find it are users on Monday morning, not you in the maintenance window.

Break two: the migration is no longer in the package

GitLab moves large data changes into batched background migrations that run while the instance keeps serving. That only works if each migration is allowed to finish before the code depending on it arrives. Hence required upgrade stops — and since GitLab 17.5 they sit predictably on x.2, x.5, x.8 and x.11.

GitLab’s developer documentation says what happens afterwards: a background migration is finalised after the next required stop and its code is then removed. Skip the stop and you install a release that assumes a data state only the removed code could have produced. The documented consequence: “Dependent migrations may fail, or the application may not function, because a required migration was removed.”

Break three: the operating system moves with it

Proxmox VE is Debian. Proxmox VE 8 sits on Debian 12 (bookworm), Proxmox VE 9 on Debian 13 (trixie). So the jump from 8 to 9 is also a Debian release upgrade — and Debian’s trixie release notes leave no room: “Only upgrades from Debian 12 (bookworm) are supported.”

Proxmox states the matching prerequisite in its upgrade guide: “Upgraded to the latest version of Proxmox VE 8.4 on all nodes.” Anyone still on Proxmox VE 7 is not facing one upgrade but two distribution changes — 7.4 first, then 8.4, then 9. Hyper-converged Ceph adds a path of its own before that: Proxmox requires Ceph 19.2 Squid before the platform upgrade to 9.0 starts.

Three worked examples

The GitLab row lists the required stops the documentation names between those two versions; each one is a separate install followed by a wait. The FortiOS row is one model’s answer on one day. And the price of waiting is readable from the same tool: the same FortiGate-60F needs two installs to get from 7.4.12 to 8.0.0 (7.6.7, then 8.0.0), three from 7.2.11 (7.4.11 → 7.6.7 → 8.0.0), and seven from 6.4.9 — one more than to the older target 7.6.4. The path does not grow linearly with time, but it grows.

Downgrading is not a fallback

The reflex — “if it goes wrong I will just put the old version back” — holds for none of the three.

• FortiOS.The administration guide opens with “Downgrading the firmware is not recommended” and then adds the sentence that settles it: “After downgrading, you may be unable to restore the backup configuration.” You may well get the old firmware back. Getting the old configuration back into it is a different question.
• GitLab.A rollback requires “at least a database backup created under the exact same version and edition you are rolling back to”, and the restore “overwrites all newer GitLab database content with the older state”. In plain terms: every merge request, comment and pipeline run created since the upgrade is gone.
• Proxmox VE.There is no documented way back. The wiki only notes that migrating a guest from a newer Proxmox VE version to an older one “may work, but is generally not supported”.

So the fallback is not the previous version. It is the state you were in before the first hop: configuration backup, database backup, snapshot. On a six-step path you need that state before every step — otherwise a failure at step five throws you back to the beginning rather than to step four.

Reconstructing the path without a vendor account

Planning needs no customer account for any of the three. Only downloading the Fortinet images does.

• FortiOS. The Upgrade Path Tool is openly reachable: pick model, current version, target version, and you get the hops with build numbers plus an export as CSV, TSV or JSON. Your current state comes from get system status. For the firmware itself Fortinet’s checklist requires “an active Firmware & General Updates (FMWR) license to access firmware downloads” — so you can plan without a contract, but not install.
• GitLab. The required stops are listed in full in the public documentation, and the support team maintains an upgrade path calculator. Your current state comes from sudo gitlab-rake gitlab:env:info. The latest patch release of each branch is in the public package repository — and that is the one meant: “upgrade GitLab to the latest available patch release of the major.minor release rather than the first patch release.”
• Proxmox VE. pveversion shows where you are, pve8to9 --full checks the prerequisites, and the wiki pages for 7 to 8 and 8 to 9 are the path. All of it free, no subscription needed.

The rule underneath is the same for all three and works without any tool: before you leave a branch, take it to its last patch release. That is the state the vendor tested the transition against.

What has to happen between the hops

A six-station path is not one maintenance window with six steps. Something has to finish between the stations. Fortinet: “Wait for services to stabilize between hops; do not skip ahead.” GitLab: background migrations must complete, which you can read with sudo gitlab-rake gitlab:background_migrations:list (18.9 and later; :statusbefore that) — the documented rule is “All migrations must finish running before each upgrade.” Proxmox: a reboot into the new kernel after each step, and in a cluster one node at a time. That is why an upgrade path belongs in a quarter, not in a night.

Why the far end of the path keeps moving

A path depends on two numbers: where you are and where you are going. The first only changes when you act. The second changes on its own — often faster than it takes to plan a multi-stage upgrade. Three figures from our own dataset as of 19/08/2026: for FortiOS the newest release we track is 8.0 (vendor date 08/07/2026) while the 7.2 branch leaves support on 30/09/2026. For GitLab the newest tracked release is 19.2.4 from 14/08/2026, and the 19.0 branch runs out on 20/08/2026. For Proxmox VE 9.2 has been out since 21/05/2026 and the 8 branch ends on 31/08/2026. Fix a target in spring and by late summer you are planning towards something that is no longer current.

That is where patchletter fits, and only there. Tick the products you run and you get an email when a new release appears; the support cycles sit on each product page — FortiOS, GitLab and Proxmox VE, with the wider view on the end-of-life page. What patchletter explicitly does not do is compute hops. Which intermediate versions sit between your state and your target is answered by Fortinet’s Upgrade Path Tool, GitLab’s required-stop list and the Proxmox wiki — not by us. We only tell you when a new release has appeared at the target end.

The honest limitation

The three paths above are snapshots taken on 19/08/2026, and the FortiOS ones are model-specific — we queried a FortiGate-60F. Ask the tool with your model and your version, not with ours. Fortinet also shows only the shortest tested route, deliberately not every possible one. On the GitLab side not every required stop applies to every instance: 17.1.8, for example, is required only for instances with large ci_pipeline_messages tables. And a path that is correct on paper replaces neither reading the release notes for each station nor testing outside production.

Vendor documentation retrieved 19/08/2026: Fortinet Upgrade Path Tool and Firmware Upgrade Guide, FortiOS administration guide (downgrading individual device firmware), GitLab documentation on upgrade paths, required stops, rolling back and background migrations, Proxmox VE wiki for the 7-to-8 and 8-to-9 upgrades, Debian 13 release notes. Versions, vendor dates and support cycles for FortiOS, GitLab and Proxmox VE from our own dataset as of 19/08/2026; those figures are left standing as a snapshot — the continuously calculated values are on the product pages.