Hi,

Does anyone have experience with migrating QRadar from a single-tenant setup to a multi-tenant environment?

Question:
Is it possible to migrate data in this scenario, where client A was previously using an QRadar all-in-one console?
We are planning to replace the existing all-in-one console with a dedicated Event Flow Processor and connect it to a centralized console.

The main question is:
How can we migrate log source keys, network hierarchy, historical events, and other related configurations?

When migrating from one all-in-one console to another, the process is relatively straightforward, but what about this case?

BR

Hello Vydenis,

There isn’t a standardized or officially supported method for this kind of migration, but it can be achieved through a combination of approaches. You'll need to consider configuration elements and historical data separately to determine how best to transition to the new environment.

Here’s a high-level overview:

1. Log Sources and Rules
   You can use Content Management to export configurations (log sources, rules, etc.) from the existing system and import them into the new one. Post-import validation will be necessary to ensure everything works as expected.

2. Historical Events (Ariel Data)
   These are stored as Ariel records. Once the new environment (including tenant setup) is ready, you can migrate data by moving the relevant files under:
   /store/ariel/events/records/aux/<tenantid>/Year/Month/Day/Hour/Minute

3. Network Hierarchy
   You can either manually recreate the hierarchy or use the following paid app to assist with the migration:
   Network Hierarchy App

4. Users
   Users will need to be recreated manually on the new console.

5. Security Profiles and Roles
   These must also be manually configured in the new environment.

In summary, this kind of migration involves several manual and technical steps. While some configuration elements can be exported/imported, most activities require careful planning and execution. I highly recommend involving IBM Expert Labs for a smooth and reliable migration.

------------------------------
Vishal Tangadkar
IBM INDIA PVT LTD
------------------------------

We used the Content Management Tool (CMT) to export all the non-system rules and CEP and import them on the new master system.  We did reports manually because there were not a lot of them.  For rules, you can also use the Use Case Manager, but it is a little less flexible in the export selections.

We usually export the network hierarchy via the API, combine all hierarchies in an excel spread sheet (from JSON) and once we get the domains and all done, export the spreadsheet as a JSON, then import on main console.  

Use a SAML source for ALL the authentications, it's much easier.  I've done federated before that was not too bad.  But even a small Google, AWS or Entra instance for the ID's make it easier, so you are not having your employees added to customer systems and don't have to keep up too much with customer user names.

Profiles and roles... You are on your own.  Have to do those I assume.  Perhaps some could come from SAML source for the roles, but the profile has to be done for each tenant.  

Copying the data is correct in the other answer posted.

Hardest part we had was integration with various ticket systems like Service Now or Jinga.  SOAR made it much easier.  

------------------------------
Frank Eargle
Senior Information Security Architect
GlassHouse Systems
Columbia SC
------------------------------

Be aware, if you do anything other than backup/restore then the identifiers in the Ariel data migrated will not match the identifiers in the QRadar configuration.  This means that, for example, an event linked to a log source with identifier X will be at best shown as an 'unknown' log source, and at worst, linked to the wrong log source entirely.

This is true for many configuration items (rules, etc...)

What this means is that although the data is there - and it is "migrated", it will look very strange and searching it may be very difficult indeed (depending on what you will be trying to search on).

Also, using CMT or other similar tools to migrate rules etc... can be very unpredictable as the tool may need to reconcile rules that have been modified differently in the source and target systems - how does it know which modification is 'correct'?

Finally, if you do use a tool like CMT - ensure you migrate everything you need to migrate at once - that way CMT has a fighting chance of modifying references that change between systems.  If you try to, say, modify the log sources separately to the rules - then any log source references in the rules will not be migrated correctly.

Super-finally - be very careful with Custom Log Source types - they can really trip you up.

Bottom line - this is really quite tricky and it is very easy the think you've done it - but actually the system you create is not migrated properly at all.