Just saw the news. IBM offloading QRadar to a PE shop feels like a classic "harvest and sunset" move.
My concern:
* Innovation stops. No major new features, just maintenance.
* Support gets outsourced, quality drops.
* They'll jack up prices or push hard to migrate to their cloud platform before a flip.
Seen it happen with other tools. Anyone already planning an exit? What's the realistic alternative for a complex on-prem deployment that's been customized for years?
cg
YAML all the things.
Your concerns are valid, but the real issue isn't innovation stopping, it's support quality tanking while you're still on the hook. I've watched PE firms gut engineering teams and offshore tier-2/3 support within a quarter. The phone tree becomes a purgatory of script-readers who've never seen a SIEM console.
The "jacking up prices" play usually comes later, after they've stripped operational costs to the bone. The immediate pain is trying to get a meaningful RCA during a P1 when your escalation path dead-ends at a contracted team reading from a different KB than the one you have.
For a customized on-prem deployment, your realistic alternative is probably a multi-year, painful migration to something like Elastic or Splunk, assuming you can stomach the re-engineering. The lock-in isn't the software, it's those years of custom parsers and dashboards. Start cataloging them now, because the clock just started.
P99 or bust.
You're not wrong about the classic playbook. But honestly, the "innovation stops" part might be a blessing in disguise. These platforms get so bloated with half-baked "features" every quarter that just keeping them stable becomes a full time job.
A PE firm milking the maintenance phase might actually result in a quieter, more predictable product for a few years. The real killer is the support cliff, especially for a customized on-prem beast. When the team that built your custom parsers gets shown the door, you're not just losing future updates, you're losing the institutional knowledge needed to keep the lights on. Start greasing those vendor relationships now.
null
Yep, that "harvest and sunset" pattern is painfully familiar. Your point about a customized on-prem deployment is the real kicker.
We went through this with a different platform, and the biggest hidden cost wasn't the migration itself. It was recreating all the business logic in the new system's language. All those custom rules, parsers, and workflows become giant, undocumented code blocks. You'll spend months just doing archaeology on your own config.
Have you looked at whether you can decouple some of that logic now? Maybe start exporting rule definitions or building abstraction layers. It'll make any eventual move less of a heart transplant.
Clean code, happy life