Your boss is making a classic enterprise mistake: choosing a vendor name over technical merit and operational reality. You're already a 100% Elastic shop. Adding QRadar isn't an integration, it's building a parallel, expensive, and likely redundant security stack.
Here's the blunt assessment. QRadar is a legacy appliance model at its core. You'll be paying massive licensing for compute and ingestion, then fighting with it to parse your existing Elastic data. Meanwhile, Elastic SIEM (now part of Security) uses the infra you already have. Your team already knows how to manage it. The cost difference will be staggering when you factor in IBM's licensing plus the operational drag.
The security angle is worse. You'll now have two data stores for logs, meaning your correlation breaks down. You'll never get a single pane of glass. Alert fatigue will double. From a compliance perspective, maintaining two separate ingestion and retention pipelines for the same data is an audit nightmare. It introduces inconsistency in parsing and enrichment.
If your boss is sold on IBM for "enterprise support," run a POC. Load a month of your logs into both. Compare the time to build a custom parser, create a complex correlation rule, and generate a compliance report. The numbers don't lie. You're choosing between leveraging existing skills and infrastructure or starting from zero with a closed system.
— geo
— geo
You're so right about the two data stores being a nightmare. I've seen that movie before, and the ending is always teams wasting months building custom connectors that break after every vendor update. The "single pane of glass" dream turns into a juggling act between browser tabs.
Your POC idea is perfect. But I'd add one specific metric to track: mean time to value. Time how long it takes to onboard a new, obscure log source and build a usable detection rule from it on each platform. With your existing Elastic skills, that time will be near zero for Elastic SIEM. With QRadar, you're starting from scratch, and that's where the real cost in analyst hours and frustration piles up.
The "enterprise support" argument is funny, because you also get support from Elastic. And your own team's deep knowledge of the stack is arguably the best support layer you could have. Maybe frame the POC as a cost-efficiency test for the boss?
test everything twice
The "enterprise support" angle is the usual trap. IBM's support is just as likely to involve months of ticket ping-pong before suggesting a costly professional services engagement.
A POC will miss the long-term tax, though. That second data store isn't just a technical nuisance, it's a permanent drag on every investigation. You'll be paying for the duplicate infrastructure and the wasted analyst hours forever.
—EB