IBM QRadar upgrade guide:
planning, execution & validation

Scope and safety

This article is a planning and validation runbook for administrators upgrading an existing IBM QRadar SIEM deployment. It is not a substitute for the release-specific IBM Upgrade Guide, SFS/ISO release notes, or the applicable support advisories. File names, command options, minimum source levels, required free space, installer menus, and known issues vary by release.

An upgrade can affect event ingestion, searches, offenses, apps, integrations, HA synchronization, and the OS underneath QRadar. Schedule an approved maintenance window, ensure the people responsible for network, infrastructure, SOC operations, and recovery are available, and agree on success criteria before starting.

1. Confirm the supported upgrade path

Start by recording the exact installed version and fix level. In the UI, use Help → About. From the CLI, the QRadar version tool is documented as:

/opt/qradar/bin/myver -v

Record this output for the Console and each managed host as needed. Then review the current target release notes, the upgrade guide, known issues, and IBM's upgrade-path documentation. Check hardware/memory requirements, supported hypervisor or appliance model, required intermediate updates, OS migration prerequisites, HA constraints, application compatibility, and any product exclusions.

Useful starting points: QRadar 101 — Installs and Upgrades, QRadar 7.6.0 upgrade preparation checklist, and IBM Support — legacy upgrade paths.

2. Understand the upgrade media: ISO versus SFS

Do not pick a file based only on its extension or filename. IBM's upgrade checklist states that ISO files are used for major OS version upgrades and SFS files for updates that do not include a major OS version upgrade. The target release instructions decide which media and sequence apply.

3. Plan the change window

Build a short change plan before touching the Console. At minimum, it should contain:

• Source version and target version, supported path reference, release notes, and approved SFS/ISO filename.
• Impacted systems, expected outage/degraded-service window, upgrade order, responsibilities, and communications to SOC stakeholders.
• Backup location, restoration/recovery owner, decision points for aborting, and a recovery procedure that is actually viable for the source/target versions.
• Pre-upgrade health status and baseline measurements so post-upgrade results can be compared with a known-good state.
• Application, integration, custom content, certificate, network, HA, and log-source checks required after the update.

Do not estimate downtime only from installer progress. Some upgrades include database migrations or OS changes and can take many hours depending on database size, I/O performance, network performance, and hardware. Allocate a window with enough margin for validation and escalation.

4. Complete the pre-upgrade checklist

Before the change window, confirm the exact source version and fix level on the Console and managed hosts, then verify the supported path to the target release. Read the target package’s release notes, known issues, hardware/storage requirements, OS migration notes, and any intermediate-update requirements. Check application, DSM, WinCollect, authentication, and integration compatibility.

Health and deployment

• Run release-appropriate health checks and resolve critical failures before upgrading.
• Confirm the deployment is consistent, pending changes are deployed, managed hosts are reachable, and time synchronization is working.
• Review System Notifications, HA state/synchronization, disk space, storage/RAID or hypervisor health, and recent backup status.

Inventory and environment-specific requirements

• Record each host role and version. Check output from /opt/qradar/bin/myver -v and /opt/qradar/support/deployment_info.sh; use additional fleet-wide tools only with the options supported by the installed release.
• Preserve custom scripts, custom DSMs/rules, routes, certificates, support-provided fixes, and other local changes. Identify any nonstandard storage or mounts.
• Follow the target release checklist for HA mount state, external storage, older Event Collector prerequisites, physical-appliance firmware, and required OS migration pretests. Do not run fleet-wide unmount or cleanup commands unless the target procedure calls for them and the mount is confirmed stale.

IBM’s preparation checklist for the exact target release is the authority for final prechecks; this short list is a planning aid, not a replacement for it.

5. Backup and recovery planning

Do not start until a configuration backup has completed, the backup file is copied off the appliance, and the team has a workable recovery plan. Record the backup location, recovery owner, decision points, and support contacts.

• Configuration: use the supported QRadar Backup and Recovery workflow and confirm the backup is available outside the system being upgraded.
• Application data: back up persistent app data separately where required. IBM documents app-volume-backup.py for applicable deployments:

cd /opt/qradar/bin
./app-volume-backup.py backup
./app-volume-backup.py ls

The listing subcommand is ls. Follow IBM’s app-specific restore instructions; a QRadar configuration backup does not guarantee app databases are included.

• Custom content: export supported custom content and store the export off-host:

/opt/qradar/bin/contentManagement.pl --action export --content-type all

Preserve certificates, scripts, integration settings, routes, and support-provided artifacts as relevant. Do not treat a live copy of /store/ariel as a universal backup or rollback method; use an IBM-documented data migration procedure only when it applies. Backup restore compatibility is version-dependent, so confirm recovery constraints for the source and target releases.

6. Managed hosts, deployment order, and HA

Follow the upgrade order defined by the target release. IBM’s standard workflow upgrades the Console first, then managed hosts, and requires the deployment to finish on a supported, consistent version/fix level. Do not leave a known mixed-version deployment running without following IBM’s recovery instructions.

• Inventory the roles present—such as Event Collectors, Event Processors, Data Nodes, App Hosts, QRadar Network Insights, and Incident Forensics—and check their compatibility with the target.
• Upgrade hosts only in the order and concurrency pattern permitted by the package. Resolve unreachable or incompatible hosts rather than guessing or skipping them.
• For HA, confirm the intended Primary Active / Secondary Standby state and healthy synchronization before the window. Follow the release-specific HA upgrade process and check the documented /store and /transient mount state. Do not force a manual failover during patching unless IBM explicitly directs it.
• Afterward, verify host versions, HA roles, synchronization, storage/network behavior, and event processing.

Use the official IBM upgrade and HA references linked below for the exact release.

7. Download and validate the software

1. Download the exact SFS or ISO specified by IBM for the approved target path from IBM Fix Central.
2. Read the specific package's release notes and installation instructions—not an article for a different fix pack.
3. Verify the SHA-256 checksum against the value published by IBM. Where IBM provides a code-signature validation utility or requires a specific utility version, use the version listed in the target package notes.
4. Transfer the package securely to the supported staging directory. Do not rename the SFS file if the parallel patching workflow requires its original filename.
5. Use the package instructions to confirm free space. For example, the QRadar 7.6.0 Fix Pack 5 note requests at least 5 GB in the relevant temporary/store temporary space on the Console and documents a disk-space check.

Example precheck pattern documented in the 7.6.0 Fix Pack 5 instructions:

df -h /tmp /storetmp /store/transient | tee diskchecks.txt

This check is an example for that release's procedure, not a replacement for verifying required filesystems and free-space requirements on every host.

8. Execute the upgrade

Use the exact installation sequence for the approved SFS or ISO package. The following illustrates the checks—not a universal upgrade script. Replace placeholders with the actual target package and use the filenames, paths, and options documented for that release.

# Confirm free space and verify the exact target package
df -h /tmp /storetmp /store/transient
sha256sum /storetmp/<exact-target-file>.sfs

Compare the checksum with IBM’s published value. Do not continue if it differs. For an SFS path, mount and run the installer only as specified in the release notes. Where the package supports an installer pretest, run it and resolve any failure before upgrading:

# Only when supported and directed by the target release notes
mkdir -p /media/updates
mount -o loop /storetmp/<exact-target-file>.sfs /media/updates
/media/updates/installer -t
/media/updates/installer

Do not reuse a filename or command from another release. Read the installer prompts, use the supported host order, and keep a way to reconnect if SSH drops. Choose sequential or parallel patching only when it is offered and permitted for the target package; parallel mode does not bypass compatibility requirements. Do not interrupt the installer simply because a phase appears idle—check the documented logs and status first.

Special compatibility failures

If the installer reports an Incident Forensics compatibility error, stop and follow the procedure for the exact QRadar and Forensics versions. Do not bypass pretests or apply a workaround from another release. IBM states that Incident Forensics is not available in the QRadar 7.6.x release stream, so deployments using it need an explicitly supported product/version plan before choosing a target.

9. Monitor the upgrade; do not interrupt it casually

• Keep an active administrative session and a separate method to reconnect if the SSH client drops. If the installer uses a persistent session such as tmux, follow the package instructions for reconnecting.
• Monitor the installer output and status/report options where provided. Record the start time, prompts, warnings, host-by-host progress, and failures.
• Be aware that some upgrade phases—especially database migration or large ownership/permission changes—can appear idle for a long time. Check target release notes and logs before concluding the installer is hung.
• Do not reboot, kill processes, unmount update media, or start a second installer merely because there is no immediate progress message. Interrupt only under a documented recovery procedure or after an informed decision with IBM Support.
• Review the final summary for managed hosts that were skipped or not updated. Investigate each result; a success message from the Console alone does not prove every managed host is patched.

10. Post-upgrade validation

Do not close the change just because the installer exits. Compare the upgraded deployment with the baseline recorded before maintenance.

• Confirm the Console and every intended managed host report the supported target version/fix level, with no failed or skipped hosts left unexplained.
• Run the release-appropriate health checks (for example, drq -v where supported), review System Notifications, deployment status, managed-host connectivity, and HA state if applicable.
• Verify new events are arriving and searchable; check flows if used, then validate a known-good search or detection test.
• Check the critical apps, custom rules/DSM content, reference data, reports, authentication, and SOAR/threat-intelligence/API integrations used by your SOC.
• Complete only the release-specific finalization steps, such as unmounting update media after the installer has finished, and retain logs and backup artifacts until acceptance is confirmed.

Record any outstanding warnings with an owner and resolution plan. Keep the change open until core ingestion, critical applications, and key integrations have passed the agreed acceptance checks.

11. If an upgrade fails or a host is left behind

1. Pause additional manual changes. Do not attempt an improvised downgrade or rerun a different installer over the failed state.
2. Capture the full installer summary and exact error, timestamps, QRadar versions, host role, free-space output, relevant system notifications, and logs specified in the target upgrade guide.
3. Determine whether the Console completed and which managed hosts did not; do not assume a failed message on one host means all hosts failed—or that the rest are healthy.
4. Follow the version-specific IBM procedure for retrying or upgrading a skipped host. IBM release notes sometimes permit copying the package to the affected host and running the installer locally, but use that method only when the exact package documentation says it is supported.
5. For database migration stalls, service startup issues, HA/DRBD synchronization problems, or a suspected damaged upgrade, preserve evidence and escalate using IBM's documented troubleshooting or support process before risky repairs.
6. If recovery or rollback is required, use the recovery plan agreed before the change. Confirm version compatibility, supported restore sequence, and impact to event/flow data before acting.

For diagnostics, refer to Part 4 — QRadar Troubleshooting and Part 3 — QRadar Health Check. These are companion references, not substitutes for the release-specific upgrade instructions.

12. Copyable change checklist

• Source version and all host versions recorded.
• Supported target path verified in IBM release notes.
• Target-specific restrictions, known issues, OS, hardware, app, and HA requirements reviewed.
• Health checks passed; critical warnings fixed; deployment changes applied.
• Capacity, disk space, network/time sync, backup and replication status verified.
• Configuration backup completed, downloaded, and recovery plan confirmed.
• App data backed up separately where required; custom content export completed and copied off-host.
• Deployment inventory/version output saved; custom scripts, static routes, firmware, external storage, and previous update mounts reviewed.
• SFS SHA-256 verified against IBM's published digest; pretest passed where supported.
• Apps and integrations reviewed for target compatibility.
• Correct SFS/ISO downloaded, checksum/signature verified, and free space checked.
• Change window approved; SOC, IT, application, and recovery contacts available.
• Console and managed hosts updated according to the documented sequence.
• Failed/skipped host summary reconciled; every host on the required version.
• Health, HA, ingestion, searches, offenses, reports, apps, and integrations validated.
• Upgrade evidence, versions, deviations, and closure notes recorded.

Official IBM references

• QRadar 7.6.0 — Preparation checklist for upgrades
• QRadar 7.5 — Upgrading QRadar SIEM
• QRadar 7.6.0 Fix Pack 5 SFS: release notes and supported source versions
• QRadar 7.6.0 Fix Pack 1: upgrade sources from selected QRadar 7.5 versions
• QRadar 7.5.0 Update Package 16: upgrade-path notice
• QRadar 101 — Installs and Upgrades
• QRadar software update checklist for administrators
• Upgrading QRadar SIEM by using parallel patching
• IBM: Backing up and restoring app data
• IBM: Upgrade preparation checklist — version inventory, custom content, external storage, HA mount checks
• IBM Support: QRadar firmware list for supported xSeries appliances
• QRadar HA — Manual failovers
• IBM Support — Before, during, and after a QRadar upgrade

This guide was reviewed on 11 October 2026. IBM can add, replace, or withdraw release packages and upgrade paths. Re-check the currently published release notes and Fix Central package prerequisites immediately before performing an upgrade.