In my days there, Gartner had Maverick research (here is mine, from 2015 about social engineering AIs…. yes, really!) that “deliberately exposed unconventional thinking and may not agree with Gartner’s official positions.”

Here is a “maverick-ish” blog for you. DO NOT try this at home! DO learn and think about it.

I’ve been obsessing with SIEM migration since at least 2011, and many of my beautifully nuanced blogs, choke full of “it depends” covered things like “By taking the time to evaluate your log sources before you migrate them, you can streamline your SIEM and focus on the data that is most important” and “adopt the practice of testing your SIEM and detection content by regularly injecting data that will test your detections, check parsing, and validate data flow.”

So there.

How about … fuck nuance and fuck it all?! Enter SIEM migration by re-creation aka “scorched Earth SIEM migration.”

BTW, this is not “recreation” as such, even though this can be fun for some, and I don’t want to judge. But re-creation or creation from scratch, for sure!

Think about it: when we talk about SIEM migration, the usual mental image involves a meticulous, perhaps painful, process of porting everything from the old system to the new. But what if we considered a different path? Instead of carefully migrating old content, what if we used the opportunity to re-create everything from scratch, leveraging all the hard-won lessons from your previous environment? This isn’t merely a migration, not “transformation lite”; it’s a transformation+”.

It implies a fundamental rethinking of SIEM (and likely SOC around it) rather than just incremental improvements.

Made by Humans (i.e. Anton)

There are some compelling advantages to this seemingly drastic approach.

The Benefits of a Fresh Start

First, and perhaps most crucially, unnecessary content — particularly detection content that no longer serves your purposes — has a dramatically lower chance of making it into the new product, wasting your time for years to come. You’re much less likely to inadvertently copy existing detection technical debt into your shiny new modern SIEM.

Think of all those cumbersome old rules that have grown unwieldy over the years, or those that simply don’t align with the realities of modern threats or new SIEM capabilities (got AI?). A re-creation approach helps you avoid spending time converting them. It’s often possible to detect certain things far more efficiently in a new product than they ever could be with the convoluted logic of the old one (yes, really, I don’t even have a marketing hat anymore, this is just a fact).

Despite widespread acknowledgment that simply copying log sources is counterproductive and that they absolutely need “assessment”, many traditional migrations still begin by porting all existing log sources into the new product (yuck!). The ‘from scratch’ approach avoids that risk and cost, allowing you to use the valuable lessons from your previous SIEM experience (but not the stale content from the actual product) and your current risk posture and IT environment to identify and then integrate only the necessary log sources. Again, this avoids detection technical debt and the “lazy thinking” of simply porting everything over.

As a result, you avoid many of the painful elements of the classic migration approach, ultimately leaving you in a far better position.

You’re Not Worse Off (Seriously)

Moreover, you’re genuinely not worse off when it comes to migrating detection content. You might think, “But what about my existing rules and use cases?” Well, first, you get a chance to completely rethink them. Second, even in the classic migration model, as we’ve stated quite a few times, you’re not really migrating it.

Yes, with the current proliferation of LLMs, you can, in theory, convert well-formed language (e.g., rules, searches, etc) from one SIEM to another. However, we’re hearing that the track record of this is, at best, mixed. In fact, you’re often recreating, not simply modifying or tuning anyway. So, in many cases, you’d be doing similar work anyway.

A significant advantage of the ‘from scratch’ model is that you’re deploying the best possible SIEM for today’s realities and the best content for today;’s product. This unchains you from being guided by historical product limitations. All the mistakes you were willing to tolerate in the old product — perhaps because they ‘weren’t that bad’ or fell into the ‘we’ve always done it this way’ bucket — won’t make it into your new product. All the erroneous, inefficient, or simply tolerated ‘stuff’ now has a chance to be eliminated. Boom!

Instead of spending time converting, tweaking, refining, adapting and adjusting inefficient or expensive searches and reports that you have no use for, you can instead use that time to strategically design the reports and dashboards you genuinely need to communicate with stakeholders and leadership. Imagine, clean reports that actually mean something! And deliver value and not just “mementos” of the SIEM you had in 2008.

A Horse to a Car… or a Car to a Plane?

One reason this blog post was conceived is that the modern generation of SIEM products differs from the classics in more ways than many often care to admit. In essence, migrating from a horse to a car isn’t about asking, “But where do you store the manure for the car (also known as gasoline)?” It’s a fundamental shift.

But I believe the real metaphor, and the real change, is even bigger. You’re not just migrating from a car to a plane; you’re fundamentally changing how you travel, even if the end result — getting from A to B — is the same. I digress, but I suspect when flying cars finally become commonplace, we’ll realize they represent a fundamentally different form of transportation, not just a regular car that happens to fly. Thinking in three dimensions will do that to you. So, think 3D and burn your old SIEM to the crisp!

So, while I’m piling up ideas and metaphors, the real lesson for real-world SIEM deployments is this: People spend too much time thinking about the details of the migration, and but they can think about what they truly need and truly can get with a new product.

Engineering Your Way to a Modern SOC

This radical approach to SIEM isn’t just about deleting old baggage; it’s about building a future-proof modern SOC from a “blank sheet of paper.” The goal is an engineering-led SOC (like our ASO approach) capable of detecting the attacks you care about and embracing an “everything as code” mindset. This means codifying as much as possible for efficiency and continuous improvement, from infrastructure to detection rules.

Of course, the biggest hurdles in such a transformation are often mindset and skillset challenges (we got a class on it!). The solution involves creating a dedicated D&R team with cloud, AI, DevOps/SRE, etc and whatever else needed to boost your new SIEM into orbit, rather than drag it with a mule team :-)

For detection and response engineering, continuous testing, the adoption of “CD/CR” pipelines, and peer review of detection/response logic are paramount. This ensures all detection, alerting and response (playbooks!) mechanisms are thoroughly tested at “code speed” through automated pipelines before ever reaching prod. Naturally, this means using a version of agile methodology. This allows for quick course correction and continuous feedback (central in ASO thinking).

Now, let it all burn. Don’t evolve, don’t transform — re-create.

Don’t Actually Burn Your SIEM — But Think About These

OK, we promised controversy, but we also want to be sane … a bit. Don’t actually destroy your SIEM by fire, but keep the lessons while tossing the outdated crap out.

Made by AI (Gemini Deep Research, infographic mode)

So, the acknowledgment that operational inefficiencies and human factors contribute to SIEM underperformance suggests that a purely technical “lift and shift” migration, even if technically feasible, would likely perpetuate existing challenges.

The “from scratch” approach, by its very nature, compels a comprehensive re-evaluation of every aspect of the security operation. This fundamental shift in perspective ensures that the migration addresses the root causes of past limitations, rather than just their symptoms. You really want this in 2025!

By Anton Chuvakin (Ex-Gartner VP Research; Head Security Google Cloud)

Original link of post is here