IBM QRadar migration from AWS to GCP

Context

A production IBM QRadar deployment running on AWS is moving to GCP. This is a cloud-to-cloud migration, not a disaster-recovery pairing: the aim is for the GCP environment to take over, with its configuration and historical data intact.

A SIEM is awkward to move because it is the thing watching everything else. Its historical events are what investigators search when they need to look back, and every log source has to find its way to the new destination. A migration that loses history or silently drops a source creates a blind spot that nobody notices until they need the data.

Where it stands

In progress. The historical data transfer milestone is reported complete. That unblocks the next stage; it does not mean the migration or the production cutover is done.

Migration architecture, simplified and sanitized

Log sources and event collectors Forward to the AWS deployment today. Re-pointed to GCP at cutover.

Source

AWS

QRadar deployment (current production)
Configuration
Historical Ariel event data

What moves, and its status

Destination preparation and configuration restoreWorked on
Data Synchronization app installationFailures investigated
Historical Ariel data transferMilestone reported complete
Collector connectivity and routingWorked on
LicensingCutover dependency
Production cutoverNot yet confirmed

Destination

GCP

QRadar deployment (prepared)
Restored configuration
Transferred historical data

Reported complete
Worked on, in progress
Pending or dependency

Simplified and sanitized. No hostnames, addresses, sizing, or component counts. Lanes show what moves between the environments and the status I can report for each.

My part

Prepared the destination QRadar environment on GCP.
Worked through configuration restoration and the setup problems that came with it.
Investigated installation failures of the QRadar Data Synchronization app.
Transferred historical Ariel data to the destination.
Accounted for differences between the source and destination storage layouts.
Worked on event collector connectivity and network routing towards the new environment.
Tracked licensing and the other dependencies that gate cutover.
Coordinated operational requirements so the move fits how the SIEM is actually used.

Constraints and dependencies

Most of this project is a dependency graph. Each item below has to be true before the next one can safely happen.

Destination readyThe GCP environment has to be built and its configuration restored before data or traffic is pointed at it.
History in placeHistorical data has to land correctly, which means accounting for how the destination lays out storage.
Collectors can reach itEvent collectors need working connectivity and routes to the destination before log sources can move.
Licensed for the loadThe destination has to be licensed for production before it can carry it.
CutoverOnly when the above hold does it make sense to switch production collection over.

Validation and rollback

Explanatory guidance, not a record of my work

How a SIEM cutover like this is usually validated

This is general practice for planning, written to explain the problem space. It is not a record of checks completed on this project.

Before cutover: compare the same time windows on source and destination (event counts for sample periods, spot-check searches) and confirm configuration objects such as log sources, custom properties, and reference data are present.
Version parity matters: IBM documents that a QRadar configuration backup restores onto a system at the same version. Check the backup and recovery documentation for the exact release in use.
During cutover: move log sources in stages and watch each one for drops in event rate or events falling into unknown categories.
After cutover: confirm every expected log source is reporting and parsing, and that offenses, searches, and scheduled reports behave as before.
Rollback: keep the source environment able to receive traffic until the destination is validated, so collectors can be pointed back if something is wrong.

What I am taking from it so far

A finished milestone is not a finished migration. Completing the data transfer changed which questions mattered next.
When an app install fails, the useful answer usually sits in service logs and dependencies, not in the error the interface shows.
Storage layout is part of planning a data transfer, not a clean-up step after it.