How to export your data from IBM QRadar

QRadar offers documented exports for events, saved search results and custom content, but each path covers different data and stops short of others. Plan the export before the contract end date, not after.

Book a callTalk to us
On this page

How to export your data from IBM QRadar before you leave

If a renewal, a licensing change, a data residency requirement or a lock-in review means you need your QRadar data somewhere else, start by treating the work as three separate exports. Events, saved search results and custom content each have documented export paths in QRadar, but none of them moves everything in one step. Raw event history at scale and the configuration logic behind your detections need separate planning, because the tools for each are different and the effort for each grows with your data volume and the number of rules and reports you have built over the years.

For events, the Log Activity tab exports results as XML or CSV. IBM recommends exporting only the visible columns, since exporting all columns can take considerably longer. For saved search results, the QRadar /ariel/searches/{search_id}/results API returns JSON, CSV, XML or tabular text, but you first need the search ID for each saved search. Before you run any of these, confirm with your QRadar administrator how far back the event data is still retained on your appliances and whether the time ranges you need are still searchable. An export can only return what the platform still holds.

For rules, reports and saved searches, the contentManagement.pl script in /opt/qradar/bin exports custom content into a timestamped compressed file. Run it as root over SSH, and expect the bundle to hold more items than you selected, because dependencies such as the saved searches behind a report are exported too. Ask your IBM contact or review the IBM documentation on what the bundle does not include before you rely on it as a full record of your configuration. Plan to document the detection logic in a neutral format as well, so the knowledge survives the platform change.

Which QRadar data can be exported and in what formats

This table compares the three main QRadar export paths: Log Activity events, saved search results and custom content. Read each row for the format, the method and the limit that changes how much work the export takes. The main takeaway is that events and search results come out as flat files, while rules, reports and saved searches need the content script and leave behind a different kind of file.

DataExport format and methodLimits and what to check
Log Activity eventsXML or CSV from the Log Activity tab, with visible columns only or all columnsIBM recommends visible columns. An all-columns export can take considerably longer, so test the time on a representative time range first.
Saved search resultsJSON, CSV, XML or tabular text through the /ariel/searches/{search_id}/results API, after looking up the saved search IDRequires API access and the search ID. Confirm the API token scope and the result size you need before scripting the pull.
Custom content (rules, reports, saved searches)contentManagement.pl in /opt/qradar/bin with -a export -c all, producing a timestamped compressed fileMust run as root over SSH. Add -g to include accumulated data. Dependencies are exported too, so a report can bring extra saved searches.

Choosing between the Log Activity, Ariel API and content export paths

The Log Activity export is the simplest path. An analyst runs a search in the Log Activity tab, then exports the returned events as XML or CSV. It suits a security analyst who needs a specific incident window for a case file, or a reviewer who wants a readable extract for a manager. The export contains only the events the search returned, not the full stored history.

  • Who runs it: An analyst with access to the Log Activity tab, working in the console.
  • Format: XML or CSV. IBM recommends exporting only the visible columns, because exporting all columns can take considerably longer.
  • What it leaves behind: A flat file of matching events with no searches, rules or dashboards attached.
  • Scale limit: The file reflects the search filters at the time of export, so a broad time range may not complete in a single pass without planning.
  • Repeatability: A manual step that depends on the person running it, so it is hard to audit as a recurring process.

Before relying on this path for records, confirm with IBM documentation for your QRadar 7.5 release how large exports behave in your environment and whether the output includes the fields your retention rules require.

What does not export through the documented paths and how to work around it

The documented QRadar paths cover events, saved search results and custom content, but several things an analyst or auditor relies on sit outside them. Each card names one gap, what the documentation supports, and what to confirm with IBM before you depend on a path. Plan the workaround before the renewal date, not after.

Offense history and analyst notes

Offenses, their status changes, assigned owners and the notes analysts added during investigations are not described as part of the Log Activity export or the content export. Those exports carry events and rule definitions, so the case trail usually stays inside the console. Ask IBM whether offense data and notes can be exported and in what format. Until you have that answer, plan a documented export of offenses from the API or an inventory of open and closed cases kept in your ticketing system.

Reference sets and reference data

Reference sets hold the lookup values that rules and searches depend on, such as watch lists, asset lists and approved hosts. The custom content export is documented for rules, reports and saved searches, so confirm whether reference set contents and their metadata are included before relying on it. If they are not, export each set through the API or the console and store the contents with the rules that reference them, since a rule without its lists cannot be rebuilt.

Flow records

Flow data is collected and stored separately from events, and the documented event export does not cover it. Flows also consume a different license metric from events. If you need historical flows for investigations or retention, confirm with IBM which flow export options your version supports and how long flow data is retained. Otherwise, document the retention gap and decide whether the replacement platform needs its own flow collection for the same period.

User accounts and role assignments

The content export is scoped to custom content, so user accounts, passwords, roles and security profiles are not documented as exported by it. These settings define who could see which data and which tenant boundaries applied. Record every account, its role, its security profile and its authentication source in a screenshot or configuration inventory. Confirm with IBM what the console and API expose, and do not copy password material, which should be re-issued during migration.

Appliance and system configuration

Network hierarchy, log source definitions, device connections, system settings and deployment layout are part of the appliance, not the content package. Rebuilding them is usually a planning task, not an export. Build a configuration inventory from the console and your change records, and confirm with IBM which system settings can be backed up or restored. Treat the inventory as the source for rebuilding collectors and parsing on the new platform.

Content dependencies and script access

The contentManagement.pl script exports dependencies too, so a report can bring saved searches with it. The script also has to run as root over SSH, which many organizations restrict. Check that your change process allows the run, review the archive for items you did not expect, and confirm the export covers the content you rely on. Keep a copy of the archive with the change record, since it is the only packaged copy of that content.

The sequence for a complete QRadar export with verification

This sequence moves QRadar events, saved search results and custom content into an archive where each file can be counted, compared and checksummed, so the export can be defended later in an audit or an investigation. It follows the documented IBM paths in order, so the same run can be repeated and checked by someone else.

  1. Inventory custom content and retention needs

    The QRadar administrator lists the custom rules, building blocks, reports, saved searches and any log sources or retention periods that the archive must cover, and records which of them your own policies require you to keep. Note the time ranges for event exports and the owner who approves each one. The step is done when the inventory is a written list with owners and time ranges, stored with the change record for the export.

  2. Look up saved search IDs

    For each saved search that must be exported, the administrator looks up its search ID so the Ariel API call can reference it directly, as IBM documents in its support guidance on exporting saved search results. Record the name, ID, owner and the query text next to each ID. The step is done when every saved search in the inventory has a recorded ID that matches the name shown in the console.

  3. Run the content export as root and store the archive

    On the QRadar console, a root user over SSH runs the contentManagement.pl script from /opt/qradar/bin with the export-all option, which writes a timestamped compressed file. Add the accumulation option only if the accumulated data is part of the requirement. Because dependencies are exported too, a report can bring saved searches with it, so expect more items than the inventory lists. The step is done when the compressed file is copied to controlled storage and its item list has been reviewed against the inventory.

  4. Export events by time range and format

    Use the Log Activity tab to search the required time range and export the results in XML or CSV. IBM recommends exporting visible columns only, because exporting all columns can take considerably longer. Record the search criteria, time range, format, column selection and the operator who ran it. The step is done when each export file is saved with a name that carries its time range and its format.

  5. Export saved search results through the Ariel API

    Call the Ariel results endpoint for each saved search ID recorded earlier and request JSON, CSV, XML or tabular text, the formats IBM documents for this path. Keep the request, the response status and the output file together so the export can be repeated. The step is done when each saved search has one output file and a log of the API call that produced it.

  6. Verify each file by record count and sample

    Compare the number of records in each file with the count shown in QRadar for the same search and time range, and investigate any difference before continuing. Then pick a sample of records, such as the first and last rows and a few random rows, and confirm that the fields match the console. Record the counts, the sample rows and the reviewer's name. The step is done when every file has a matching count and a signed sample check.

  7. Generate checksums and archive with evidence

    Generate a SHA-256 checksum for each exported file and for the content archive, then store the files, checksums and the evidence record in write-once or access-controlled storage. Note the storage location, the retention rule your policy requires and who holds access. The step is done when a second person can recompute the checksums and get the same values, and the evidence record links every file to its inventory entry.

How to verify an export is complete enough to use

Start by reconciling counts. For every Log Activity export, write down the time range, the saved search or filter applied, and the number of rows the console showed when you ran it. Compare that figure with the number of data rows in the XML or CSV file. A mismatch usually means the export was run against a different time window, a filter changed between runs, or the file was truncated during transfer. For Ariel API result downloads, record the search ID and the search parameters, then confirm the row count in the returned JSON, CSV, XML or tabular text matches what the search reported. Choose visible columns only when you expect to reuse the file as an audit extract, and confirm that the header row lists the fields your analysts or examiners need, such as event name, source and destination addresses, log source and timestamps. If you exported all columns, check that the larger file opened completely and that no field was cut off.

For custom content, open the bundle produced by contentManagement.pl and confirm that each report you need is present with its saved searches, because IBM notes that dependencies are exported too and a report brings its saved searches with it. Count the items and compare them with your inventory of rules, reports and saved searches. Extra items are expected, but a missing dependency is a gap that will break the restored content. Keep a run log that records the command used (for example ./contentManagement.pl -a export -c all, and whether -g was added), the QRadar version, the host name, the operator, the start and end timestamps, and the file name and checksum of each output. Store that log with the export so the next person can repeat the run.

Treat verification as proof that the files are intact and match the scope you ran, not proof that every QRadar artifact is covered. Offenses, reference data, custom properties, building blocks and some configuration may sit outside the exports you ran, so compare against your own inventory. If the export will serve as evidence for an audit or legal hold, confirm with the relevant auditor or counsel what they will accept, how long the files must be kept, and whether they expect a hash or a signed record of the process. DeployOpen can help document and rehearse these checks, but the acceptance decision belongs to your assessor.

What to plan before the QRadar contract renewal or termination

Exports from QRadar depend on access that can end with the contract, so the decisions below need answers before the renewal or termination date. Each card is a planning item with the question to put to IBM or your reseller, and together they decide whether your data leaves QRadar complete and on time.

Appliance access window

Decide how long you need a working console and Log Activity access to finish every export. Large event exports can take considerably longer when all columns are included, so test a representative time range now rather than on the last day. Ask IBM or your reseller whether access continues for a defined period after the end date, and get that period in writing.

Post-termination licensing terms

Read the contract clauses that govern use of QRadar data and software after termination, including any read-only or archive rights. Confirm with IBM whether the license permits you to keep the appliance running for exports and whether the export tools are covered. Treat any answer that is not written into the agreement as unconfirmed.

Retention periods for archived events

Find out how far back your stored events and offenses go, and which retention settings apply to each. Events outside the retention window may already be gone, so the export scope is limited by what the appliance still holds. Ask IBM or your administrator to confirm the retention configuration and the oldest date you can still retrieve.

Root and SSH access for content export

The contentManagement.pl script in /opt/qradar/bin must be run as root over SSH, so identify who holds those credentials now. Plan for named administrators, a change record for the session, and a way to reach the appliance if the usual administrator has left. Confirm with IBM which access methods remain available after the contract ends.

Dependency review before content export

Expect the content export to include more items than your list of rules and reports, because dependencies are exported too. A report brings its saved searches along, so inventory those links before you run ./contentManagement.pl -a export -c all. Keep the timestamped output file and record which items it contains.

Destination readiness for received data

Confirm that the platform receiving your data can ingest the export formats, which include XML, CSV and JSON for saved search results, and has storage, indexing and access controls in place before the data arrives. Decide who owns the destination and who signs off on completeness. A destination such as Wazuh or OpenSearch needs its own planning, so start that work before the QRadar end date.

Questions buyers ask about exporting QRadar data

How much effort does a full QRadar export take?

Effort depends mostly on what you export and how much of it there is, not on a fixed amount of work. Event exports from the Log Activity tab are simple when you choose visible columns only, which IBM recommends, but choosing all columns can take considerably longer. Large event volumes, long time ranges and many saved searches multiply the work, because each search result set has to be pulled, checked and stored. Content exports add another layer, since a single report can bring its saved searches with it, so the output often holds more items than you listed. Ask your team or partner to inventory event volume by time range, saved searches and custom content before estimating anything.

Can our own team run the QRadar export without outside help?

A capable team can run the export in-house if it has the right access and skills. Content exports via contentManagement.pl require SSH access to the appliance and the script must be run as root, so the operator needs privileged access and change approval. Saved search exports through the Ariel API need API tokens, HTTP calls, and scripting to page through results and save them in JSON, CSV, XML or tabular text. Event exports from the console need only a user with Log Activity access. Confirm who holds root and API credentials, whether your change process allows that access, and whether someone can write and check the scripts.

How long should we plan for a QRadar export?

Plan the export around your QRadar support and licensing dates, not around a date you have not confirmed. Your contract window is unknown to this page, so confirm the end date with IBM or your reseller before fixing a schedule. Then work backward: inventory the data, test a small export, run the full export, validate the files and store them. Export time grows with event volume and column choice, so a pilot on one month of events shows how long the full run will take. Build in a validation step and a second run for any content that was missed.

Should we engage IBM Consulting or a partner for the export?

Engage IBM Consulting or a partner when your team lacks root, API or scripting capacity, or when the export must be validated for a compliance review. The choice depends on who has the skills, who signs off on the output, and how much of the destination work follows. Whoever you choose, ask for a written scope that lists the sources (events, saved searches, custom content), the export methods, the file formats, the storage location and encryption, the validation checks, the handover documents and the person accountable for each step. Also ask how dependencies such as saved searches inside reports are handled, and whether the scope covers rerunning the export if the first pass is incomplete.

What happens to QRadar data that never leaves the appliance?

Data that is not exported stays on the QRadar appliance and is governed by its retention settings. Once the QRadar licence or support ends, that data is only accessible while the appliance keeps running and remains under your control. Exports create copies that you must protect, so decide where they are stored, who can read them, and how long they are kept. Record what was not exported, the retention period of each data type, and the disposal plan for the appliance. Confirm with your compliance team how retained logs must be kept and whether any evidence must be preserved before decommissioning.

Does the export cover everything QRadar stores?

The export covers what the chosen methods can reach, so it rarely covers everything by default. Log Activity exports capture the events you select, while the contentManagement.pl script captures custom content such as rules, reports and saved searches. Accumulated data is only included when the -g option is used, and the script does not replace a full backup of the appliance. Ask for a list of each data type, the method used to export it, and any gaps that remain, such as configuration, network data or user accounts that the export does not include.

How do we confirm the exported data is complete and usable?

Confirm completeness by comparing the export against the source before you retire anything. Check record counts for each time range and search, confirm that all columns you need are present in CSV or XML files, and open a sample of files to confirm they are readable. For the content export, compare the list of items in the archive with your inventory, and note any extra items pulled in as dependencies. Keep a log of what was run, when, by whom, and with which options, so an auditor or a future migration team can check the work.

How DeployOpen scopes and delivers a QRadar data export

DeployOpen treats a QRadar export as a written, fixed-scope engagement inside your own infrastructure. We agree which event searches, saved searches and custom content leave QRadar, in which formats, and where the files are stored before any export runs.

How we scope

  • Inventory the Log Activity searches, saved searches and custom content that must leave QRadar, and record the owner of each item.
  • Confirm which export path fits each data set: Log Activity export, the Ariel API results download, or contentManagement.pl.
  • Agree in writing whether exports use visible columns only or all columns, and which time ranges and formats are in scope.
  • Ask for a written statement of what each path leaves behind, including dependencies pulled in by content exports.

How we build

  • Run exports on a copy or a test appliance first, and compare row counts and field values against the source searches.
  • Script the Ariel API calls to look up search IDs and download results in JSON, CSV, XML or tabular text, with logs of each run.
  • Run contentManagement.pl as root over SSH under change control, and review the timestamped archive before it is moved.
  • Check that exported files are encrypted at rest and access-controlled inside your environment.

How we hand over

  • Deliver an export inventory listing each file, its source search or content item, its format and its checksum.
  • Document the restore and reading steps so your team can open the XML, CSV, JSON and archive files without QRadar running.
  • Provide a record of dependencies found in content exports, so no item is retired by surprise.
  • Hand over runbooks for repeating the export before decommissioning any appliance.

How we support

  • Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
  • Ongoing support, upgrades and re-runs of exports are available as a retainer under a separate written scope.
  • Ask any provider, including us, to confirm in writing which QRadar version and export features apply to your environment.

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com