Introduction
This guide covers upgrading a FortiSOAR™ enterprise instance, High Availability (HA) cluster, or a distributed multi-tenant configuration.
The FortiSOAR UI displays a notification when a new release (always the latest) is available. The notification includes a link to the release notes, where you can review details about the latest version. This feature helps you stay informed about new releases and decide whether to upgrade to the most recent FortiSOAR version.
Upgrade Framework Enhancements in FortiSOAR 8.0.0
FortiSOAR 8.0.0 introduces significant improvements to the upgrade framework to enhance reliability, visibility, and operational resilience.
Key enhancements:
- Strict separation between validation and execution
- Real-time upgrade visibility
- Enforced
tmuxsession for upgrade execution - SSH login notifications during active upgrades
- Improved log naming and rotation
Separation of Validation and Execution
In FortiSOAR 8.0.0, the upgrade workflow strictly separates system validation from upgrade execution.
check-readinessperforms validation checks only. It is read-only and does not modify the system.- All system changes occur only when you run the
executecommand.
This separation ensures safer pre-upgrade validation and prevents unintended system modifications.
Real-time Upgrade Visibility
When you initiate the upgrade using the execute command, the CLI streams upgrade logs and progress output in real time. Previously, the CLI did not display upgrade progress. You can now:
- Monitor upgrade progress continuously
- View logs directly in the terminal
- Identify the current execution stage
- Receive immediate feedback during long-running tasks
This capability eliminates ambiguity and improves operational transparency.
Enforced Execution Inside a TMUX Session
FortiSOAR upgrades are long-running operations that can terminate mid-process, potentially leaving the system in an inconsistent state due to disruptions such as network drops, SSH disconnections, or terminal closures. The upgrade process now runs within a tmux session, ensuring that:
- The upgrade continues even if SSH session disconnects
- Accidental session closures do not interrupt the process
- The risk of partial or interrupted upgrades is reduced
- Operational resilience is improved
SSH Login Notifications During Active Upgrade
If you disconnect and later reconnect via SSH while an upgrade is still in progress, the system detects the active upgrade session. Upon login, a clear notification indicates that an upgrade is running, which prevents:
- Accidental re-execution of the upgrade
- Misinterpretation of system state
- Duplicate upgrade operations
Log Naming and Rotation Improvements
Previously, upgrade logs were named 'upgrade-fortisoar-<version>-<timestamp>.log' and stored in the /var/log/cyops directory, where <version> represented the target upgrade version. This naming convention made it difficult to identify the active log file.
The active upgrade log is now always named upgrade-fortisoar.log. When a new upgrade starts, any existing log is automatically renamed to upgrade-fortisoar-<version>-<timestamp>.log. This approach provides clear identification of the active log, predictable log rotation, and simplified log collection.
Upgrade Process Overview
This document describes how to upgrade FortiSOAR to 8.0.0 and supplements the FortiSOAR Release Notes. It includes the following sections:
- Preparing to Upgrade FortiSOAR
- Upgrading a FortiSOAR Enterprise Instance
The "Upgrade Framework" improves the flexibility, usability, and efficiency of the FortiSOAR upgrade process. - Upgrading a FortiSOAR High Availability Cluster
- Upgrading a FortiSOAR Distributed Multi-Tenancy Configuration
- Upgrading FortiSOAR using the Offline Repository
- Upgrading your FortiSOAR Docker image and upgrading your FortiSOAR Docker on an Amazon Elastic Kubernetes Cluster
- Post-Upgrade Tasks
If you encounter issues during the upgrade, see the Upgrade Issues topics in the Troubleshooting Issues chapter of the “Deployment Guide.”
Important considerations before upgrading FortiSOAR
Release 8.0.0 introduces updates to FortiSOAR licensing, including security enhancements. As a result, licenses used with earlier versions are not compatible with FortiSOAR 8.0.0 or later. Before upgrading, download an updated license from Fortinet Support and deploy it to your FortiSOAR instance. FortiSOAR displays an error message, if you attempt to deploy an older license on version 8.0.0 or later.
Starting with release 7.6.5, the csadmin user’s sudo privileges are restricted to only the commands required to work with FortiSOAR, instead of providing full 'root' access. This enhancement aligns with the principle of least privilege and reduces exposure to sensitive system files. Therefore, commands such as yum, systemctl, csadm, etc, must be prefixed with sudo, for example, sudo csadm --help.
To open or edit a file, prefix the command with 'sudo' and specify the file’s full path (sudo vi <full path of file>).
For example, sudo vi /opt/cyops-auth/utilities/das.ini.
Additionally note that for security reasons, 'root' access is provided via the system console and is not available over SSH.
- Upgrading an HA Cluster from Versions Prior to 7.6.1: If you are upgrading your FortiSOAR HA cluster from releases 7.6.0 (or earlier) to release 7.6.1 or later, follow the steps in the Upgrading FortiSOAR High Availability Cluster for releases prior to 7.6.1 topic.
- Upgrading an HA Cluster from Version 7.6.1 onwards: If you are upgrading your FortiSOAR HA cluster from release 7.6.1 to release 7.6.2 or later, you can use the 'rolling upgrades' process. Steps for rolling upgrade are mentioned in the Upgrading FortiSOAR High Availability Cluster for releases post 7.6.1 topic.
- Post-Upgrade Action: After upgrading, log out from the FortiSOAR UI and log back in to complete the process.
- System Downtime: The upgrade procedure temporarily takes the FortiSOAR application offline. We recommend notifying users of the scheduled upgrade, as they will be unable to log in to the FortiSOAR during this time.