IBM QRadar migration guide:
same or new IP address

1. Choose the correct migration path

IBM provides separate procedures for replacing a Console while keeping the existing IP address and replacing one with a new IP address. Both flows assume the managed hosts remain in the deployment and that the new Console is installed at a matching QRadar software version/fix level before the configuration is restored.

These procedures do not automatically migrate all QRadar app data, custom integrations, third-party application state, or every external dependency. Plan app data backup/restore separately, and inventory custom certificates, SSH keys, license state, WinCollect compatibility, managed hosts, and connections to external systems.

2. Pre-migration checklist

• Record the source Console version/fix level, hostname, IP/subnet, gateway, DNS, appliance type, license state, and connected managed hosts.
• Confirm /opt/qradar/bin/myver on source and destination. Use a compatible matching version/fix level before restoring configuration.
• Complete an On Demand Backup, download it, and keep a protected copy off-host.
• Back up persistent app data separately using each app’s supported process. Inventory certificates, SSH/key material, WinCollect, integrations, and relevant /store/ec data.
• Verify destination capacity and source-to-destination connectivity, and define outage/rollback criteria. Keep console or out-of-band access available for network changes.

3. Migrating to a new Console with the same IP address

Step 1 — Prepare and back up

Install the replacement Console on the same supported QRadar version/fix level and give it a temporary unused IP. Confirm the source version with /opt/qradar/bin/myver, confirm WinCollect compatibility where used, and create/download an On Demand Backup.

Step 2 — Stop the old Console services

During the approved cutover, run the service-stop sequence from IBM’s release-specific guide on the old Console:

systemctl stop hostcontext
systemctl stop tomcat
systemctl stop hostservices
systemctl stop tunnel_manager

Step 3 — Release the production IP

Identify the management interface/profile using cat /etc/management_interface and use the documented network-change method for this QRadar/OS release. IBM’s current guide may use NetworkManager (nmcli) to assign the old Console a temporary address. Confirm the values and interface before applying changes, and use out-of-band access so you do not lose the only management path.

# Illustrative pattern only; verify UUID and values first
nmcli connection modify <UUID> ipv4.addresses <temporary_ip>/<prefix>
nmcli connection modify <UUID> ipv4.gateway <gateway_ip>
nmcli connection up <UUID>

Verify the old Console no longer owns the production IP. On the new Console, run the supported setup utility to assign the original address:

/opt/qradar/bin/qchange_netsetup

Step 4 — Transfer required keys and certificates

Copy only the certificates and SSH/key material required by IBM’s procedure. Protect private keys and do not blindly overwrite destination material. For custom Console SSL certificates, use IBM’s certificate workflow (including install-ssl-cert.sh -i where the guide directs) rather than copying over the live HTTP certificate directory.

rsync -avz /opt/qradar/conf/trusted_certificates/ root@new_appliance:/opt/qradar/conf/trusted_certificates/
rsync -avz /etc/ssh/ root@new_appliance:/etc/ssh/

Step 5 — Restore configuration and deploy

Copy the backup into /store/backupHost/inbound/, restore it through Admin → Backup and Recovery, review any errors, then use Deploy Full Configuration when the migration procedure requires it. Reinstall or restore app data separately, and verify any license steps required for the replacement hardware.

Step 6 — Transfer historical data

Use the IBM-provided syncAriel.sh procedure to transfer Ariel event/flow data. Use a persistent shell session for a long transfer and follow the utility’s documented rerun behavior if interrupted:

chmod +x syncAriel.sh
tmux
sh syncAriel.sh -i <new_Console_IP>

Only if the deployment requires local Event Collector data from /store/ec, follow the separate IBM procedure to stop ingress on the correct hosts, create/remove the manual-stop marker, copy the required data, and restart the service. This is not part of the Ariel transfer.

4. Migrating to a new Console with a new IP address

Step 1 — Prepare the new Console

Install the replacement Console at the planned new IP using a compatible matching QRadar version/fix level. Verify /opt/qradar/bin/myver, host role, network reachability, and backup availability.

Step 2 — Restore configuration

Copy the On Demand Backup into /store/backupHost/inbound/ on the new Console and restore it through Admin → Backup and Recovery. Follow IBM’s release-specific procedure for managed-host access checks. If that procedure requires temporarily stopping the host firewall on managed hosts, do so only with change approval and a clear restoration step; App Hosts may also require handling docker_iptables_monitor.timer. Confirm all hosts pass the required access test before continuing.

Review restore results, complete the required configuration deployment, and verify license and application restoration steps. QRadar configuration backup does not automatically guarantee persistent app data is included.

Step 3 — Transfer Ariel data

Run IBM’s syncAriel.sh procedure from the old Console toward the new Console IP, using the target-release instructions and a persistent session. Confirm historical event/flow data is available after transfer.

chmod +x syncAriel.sh
tmux
sh syncAriel.sh -i <new_Console_IP>

Step 4 — Update dependencies

Update DNS, routes, firewall allowlists, monitoring, API clients, automation, certificates/SANs, and third-party integrations that reference the old IP or hostname. Validate managed-host connectivity, new event/flow ingestion, app status, and critical integrations before acceptance.

5. Important data-transfer distinctions

6. Post-migration validation and rollback

• Confirm the replacement Console has the expected QRadar version, hostname, IP configuration, and license state.
• Review Backup and Recovery restore results and complete a full configuration deployment without unresolved errors.
• In Log Activity, run a recent-time search and verify new events are arriving and searchable.
• In Network Activity, verify flows are being received and processed where flow collection is configured.
• Check managed-host status, log source health, event pipeline, deployment health, time synchronization, and relevant System Notifications.
• Verify certificates, custom trust, WinCollect, scanners, apps/extensions, API clients, and external integrations.
• Confirm the historical Ariel data expected by stakeholders is present, and verify any relevant /store/ec data was migrated when applicable.
• For a new-IP migration, validate DNS, routes, firewall allowlists, monitoring, and consumers of the old address.
• Record transfer duration, skipped/failed items, final checks, and any service interruption. Keep the old Console powered down or isolated but available for the agreed rollback period.

If validation fails, do not bring the old and new appliances online with the same IP address at once. Follow the rollback plan to isolate the replacement, restore the old appliance's network settings if required, and bring it back only after confirming address ownership and the risk of configuration/data divergence.

Official references and learning resources

• IBM QRadar 7.6 — Replacing a Console with the same IP address
• IBM QRadar 7.5 — Replacing a Console with a new IP address
• IBM QRadar 7.6 — QRadar SIEM hardware migration scenarios
• IBM Support — Non-HA Console replacement using the same IP/hostname
• IBM Security Learning Academy — Migrating a QRadar Console (same IP path)
• IBM Security Learning Academy — Migrating a QRadar Console (new IP path)

Use the IBM procedure for the relevant QRadar release. The linked new-IP migration guide covers QRadar 7.5, while the same-IP guide covers 7.6; select documentation that matches the system being migrated. Network tooling, firewall handling, data-transfer steps, and restore options can differ by release. Validate every command before production use.