Migrating from Your SIEM to a New One

Many years ago, in 2011, I wrote this blog post on SIEM migration, called “How to Replace a SIEM?” I was a consultant at that time and I helped some organizations to get rid of their dying SIEM products and to deploy new ones. Of course, in 2011 we had dying MARS (yup, that’s the one that can “mitigate” by messing up your router configs) and now we have … ahem … other products in focus

I’ve been meaning to come back to this topic, and we sort of touched it in our recent SIEM papers (especially here), but we never did anything deep on this. Well, this post isn’t deep either – just some recent pointers I’ve been making to people who switch SIEMs in client inquiry.


  1. There is no “migration” of detection content. There is a process of rebuilding the detection content (rules, alerts, dashboards, models, etc) from scratch and using your old content as inspiration. In some happy future where Sigma rules, this may change – today, there is no way to “run a converter” on your “Vendor A” rules to turn them into “Vendor S” search queries. Also, even thinking of trying to do this makes you eschew new thinking in favor of old (what if I don’t need this rule, because today ML can do it better?), so please don’t obsess about content migration, but use your current content to inspire new thinking with your new SIEM+. As a summary: this takes a fair amount work!
  2. There is no migration of collected log data, in most cases. It is just not worth the effort. Prepare to keep the old SIEM running for 9-12 months (some choose to do so unsupported, but YMMV) as a “legacy data store.” Now, you can try to export/convert/import, but this is messy, labor intensive, annoying and, frankly, can just be avoided by keeping the old data in your old SIEM or in some independent log repository (this reminds us why separate SIEM and CLM has been a good idea for many)
  3. Do NOT migrate all the log sources blindly. This is your chance to be output-driven, use it! Pick the log sources that you have use cases for, and only migrate those, add new ones as you develop more use cases. Use this as a chance to clean house of the logs you don’t use – and the fact that you added these log sources 3 years ago and never added to a rule, alert or search serves as such proof that you do not.
  4. Use the migration as an opportunity to clean your SIEM game. Use the lessons you learned from your recent SIEM failure project, to run the new one better. This is an extension of the previous item re: log sources – so also learn to run alert triage and tuning better, for example. Also, use this as a chance to do things “the new SIEM way” and not just replicate what you did (the previous one is no more, right? so perhaps more change than the product is needed…) Overall, I see a lot more happier second marriages [to SIEM] 🙂
  5. If you migrate to a SaaS SIEM, then what? – Much of this actually stays the same, but it is very possible that your collection infrastructure is going to change. Prepare to do more collector re-architecting. Lots of things will become easier, but you bandwidth cost may go up, and you may need to think hard about routing some logs in a different manner before they get to your shiny new SaaS SIEM.
  6. Prepare to spend a lot more time on this then you think is likely. This is SIEM after all 🙂

As further reading, I will step away from my tradition and recommend this well-written series of 3 posts from a vendor:


Posts related to SIEM:

*** This is a Security Bloggers Network syndicated blog from Anton Chuvakin authored by Anton Chuvakin. Read the original post at: