Let’s talk about what it actually feels like to be the engineer handed a SIEM migration.
You get the news a few weeks after the budget decision. Maybe leadership decided the current platform is too expensive. Maybe the old vendor burned a bridge somewhere up the chain. Maybe someone saw a demo and liked the dashboards. Whatever the reason, it’s your problem now. You have to migrate to a new SIEM while keeping the existing security posture intact.
So you pull up the current architecture and start mapping out what’s sending data where. And pretty quickly the scope of what you’re actually dealing with starts to sink in. This isn’t really a migration. Your team is switching the engine that powers your security bus while it’s doing 80 mph on the highway. Any significant mistakes will cause a serious wreck.
Most SIEM platforms use a proprietary agent, which uses a proprietary protocol to ship telemetry to a proprietary data engine that saves it in a proprietary data format, which you query with a proprietary query language. Five layers of proprietary, and you agreed to all of them without really thinking about what that means long term when you look to use your data beyond your SIEM and when you need to migrate to another SIEM.
This is where most people start to realize the vendor didn’t just sell them a SIEM. They also sold them a dependency.
The trap was built on purpose
When you stood up the current platform, lock-in was not on anyone’s mind. You were focused on getting sources onboarded and detections tuned and the migration finished. Nobody stops in the middle of a deployment to ask what leaving would cost.
I want to be direct about this because it often gets framed as an industry inevitability or just the nature of enterprise software. It isn’t. Proprietary agents, connectors, query languages, storage formats, these are architectural choices made by the vendors deliberately. They’re not building lock-in because it makes the product better. They’re building it because it makes it harder for you to leave.
The math is simple. If the cost of migrating away is high enough, some percentage of customers will absorb a bad renewal rather than go through the pain. And it doesn’t have to be a majority. Even if only 30% of customers decide it’s too hard to leave, that’s a significant cushion on pricing power. Lock-in pays for itself many times over.
I know of one large company that spent months asking their SIEM vendor for a renewal quote. They finally got it six weeks before the renewal date. It was 25% more than the prior contract cost with very little meaningful product change. Leadership was furious. But after the sound, fury, and a lot of cursing faded, they realized they had no real choice. They couldn’t leave without risking a genuine posture gap, and the disruption to the SOC and security engineering was too big to risk a massive last-second change. So they paid up, but they also started a project to make sure it never happened again.
This is an old story. Vendors are going to vendor. The data ownership dependency builds quietly over months and years while your team is focused on writing detections and chasing alerts. Until one day you try to leave and realize how deep you’re in.
The only way to address this is to take a first principles approach and focus on data ownership as the priority, then pick vendors based on who will support this fundamental requirement. Every architectural discussion needs to be framed around decoupled data collection, open formats, and data lakes. Everything starts with data ownership.
How to get out and stay out
There’s no magic that fixes this virtual jail cell, but there is a set of practices, most of which you can start on right now, that will change the dynamic over time. This is a mix of quick and long term wins. Some of the core changes will take time. Your mental model for this kind of work is turning the ship one degree every day. Small changes over time will equal big wins over time because you are shifting the culture towards data and analytics. There is a difference between a program that’s reactive and perpetually at the mercy of its vendor and one that can make platform decisions based on actual value. For leaders, it is incredibly important to always have a plan for the future.
1. Decouple your telemetry collection from your SIEM
This is the single most important structural change you can make, and it’s the one most organizations skip because it feels like unnecessary work when everything is running fine. Why spend time and money on something that your SIEM vendor gives you for free? Every decision has tradeoffs and going with your vendor’s data collection tooling will eventually incur costs and not just at migration time.
Getting off proprietary agents means moving to open source or vendor-neutral collectors. Open source options like Fluentd, Fluent Bit, Vector or vendor supported options like Cribl Stream and Edge are all reasonable options. Every choice has a tradeoff, in terms of ease of use with Cribl or pure ownership with open source so think about what you really need and what you can staff to make the right decision.
I know what some of you are thinking. Cribl is a commercial vendor, so how is that different from the problem we just spent a thousand words describing? It is a fair question and the answer matters. Your SIEM vendor owns your data because it holds the storage, the format, and the only path to query it. A telemetry pipeline sits upstream of all that. It reads your sources and writes to destinations you pick in formats you choose. If you walked away from Cribl tomorrow, you would have real work to do rebuilding pipelines, but your data would still be sitting where you put it in a format you can still read. Nobody, including Cribl, is holding your data hostage.
That is the test I use for any tool in this space. Does it hold my data, or does it just move it? Tools that move data are a manageable dependency. Tools that hold data in proprietary formats are the ones that end up owning you.
The business outcome is a collection layer where your sources send data to a telemetry pipeline you own, that pipeline normalizes and routes to your SIEM, and anywhere else you want. Your SIEM becomes a consumer of your data. It doesn’t own it. You can collect and move data from anywhere to anywhere without having to ask your SIEM vendor if your data source or destination is supported. This is real freedom to make your own choices.
Freedom does not happen overnight. You cannot rip out every proprietary agent in a weekend. Get started with a small deployment so you can work out the people and process while keeping the blast radius manageable. Build your plan while you create the muscle memory to make the process repeatable. Start with new data onboarding and then expand to your existing data. Success is one step at a time towards a better future.
2. Normalize to a schema you control
Vendor data models (aka proprietary vendor specific schema) are another form of lock-in that’s easy to overlook. When all your parsing and field naming is done inside the vendor’s pipeline, your detection logic is implicitly tied to that model. Move to a different SIEM with a different schema and you’re not just rewriting queries, you are rewriting the data model those queries run against. It is yet another dependency.
The best answer is normalization at the collection layer, before data ever reaches the SIEM. The Open Cybersecurity Schema Framework (OCSF) is the right choice here. It’s open, well-documented, not owned by any vendor, and built for cross-platform interoperability from the start. Major cloud providers and security tool vendors have aligned on it, so it is increasingly likely to be understood on both sides of any migration you might face. Even if you cannot use OCSF with your SIEM, you can use it with your data lake. Standard data helps drive standard processes and predictable data. Moving your processes to a data lake is part of the plan anyway. Adopting even light normalization is a big step towards making sure your data lake is a usable platform and not just a data dumping ground.
You will also hear Elastic Common Schema (ECS) come up in these conversations. ECS is solid, but in practice it’s deployed almost exclusively in Elastic environments. If your SIEM is Elastic, it’s relevant. Mapping to ECS in your telemetry pipeline is a great way to take overhead and cost out of your Elastic environment while still using Elastic’s out of the box content. As a broader portability strategy, ECS is pretty limited. OCSF is the better long-term bet when vendor independence is the goal.
When your data is normalized to an open schema before it hits the SIEM, migrations become considerably less disruptive. Field names are consistent regardless of which platform is consuming them. Your data looks the same on the other side because you defined what it looks like, not the vendor. This is choice and control.
3. Build a data lake for analytics and retention
Data retention is where a lot of teams discover just how locked in they really are. You need 13 months of logs for compliance. They’re sitting in the vendor’s proprietary storage. The new platform can’t read them. So now you’re paying to keep the old platform alive just for data access. It sounds absurd until it happens to you, and then it’s just expensive.
Own your data lake. It is one system with tiers, and your archive lives inside it. Compliance data that nobody queries sits in the cheapest tier you have. Data your team actually works with sits somewhere faster. Same platform, same formats, different cost per gigabyte. Before data goes to your SIEM, it should go somewhere you control, such as an S3 bucket or whatever object storage fits your environment. Store it in an open format. Parquet is a good choice for structured log data: compressed, queryable with a wide range of tools, and not owned by anyone. JSON works too, though it’s bulkier. The point is that you have a copy that lives outside anyone’s proprietary system. The open format is the key focus.
I see this come up a lot and it is very frustrating. The legacy SIEM model forces teams to treat all the data the same, which is a problem when a material amount of your data is compliance data with little security value. Teams are putting low value data in high cost storage systems. The mental model for a data lake is to always match cost and value. A data lake enables teams to shift low value data to a low cost data lake while still keeping it accessible and searchable. Compliance requirements are met, and you free up space in your SIEM for higher value data.
This also lets you separate hot and cold storage from your SIEM pricing. Your SIEM doesn’t need to hold 13 months of everything. It needs to hold as much data as is genuinely useful for active detection and investigation, typically somewhere between 30 and 90 days. Older data lives in your archive tier, queryable when you need it, and out of the vendor’s billing model entirely.
Over time, consider moving processes that benefit from access to more data to your data lake. Threat hunt, DFIR, and IR come to mind as processes that need lots of data to be effective. A data lake is where you can make the economics of more and more data actually work while keeping your SIEM focused on detection and immediate response, which is what it is intended for anyway.
Yes, this adds complexity. You’re managing more infrastructure. But it is infrastructure you own, on your terms, that helps drive a more effective and efficient security program through the value of data. These tradeoffs are worth it.
4. Add dependency mapping as a roadmap item to your solution architecture practice
The worst time to figure out your SIEM dependencies is when you’re already mid-migration. But that’s when most teams do it, because there’s no obvious reason to do it sooner. This is common for many tools, which is why I highly recommend adding this item to your yearly solution architecture review process to move towards being proactive and not feeling trapped when a dependency is discovered.
Start now. Document every log source and how it is being collected. Document every element such as parsing logic, timestamps, data formats, and so on. Expand to where data is stored across your environment and document gaps in your process and data to help build a backlog that is prioritized on risk. Be sure to include building a backlog around data quality as well so your team has a list to fix as time allows. It is not glamorous work, and it won’t feel urgent until it is.
This is not a one time exercise. The map has to be maintained as the environment changes. But having it means that when someone asks what it would actually take to migrate away from the current vendor, you have a real answer instead of a guess. Also use this process outside of the migration question to improve your data as well. Do not treat dependency mapping as a one off just for migrations.
The bigger picture
None of these changes individually solves the problem. But when done together over time, they shift the value in your security program away from the vendor relationship and into your own data and security processes. That’s the goal. That is the key business outcome.
For most organizations right now, the SIEM vendor is the center of gravity. It is the monolith that exists because all of your data is in the same place. The vendor supplied pipelines route to them. Parsing and field naming follow their model. Analyst institutional knowledge is about their platform. When prices go up or the relationship sours, there aren’t many options.
The programs that handle migrations best aren’t the ones that planned the migration perfectly. They’re the ones that had already done the work to make themselves less dependent. They’d moved to open collection tooling not because they anticipated a migration, but because it was the right architectural call. They normalized to OCSF because they didn’t want their data model tied to a vendor. They built a data lake because paying SIEM prices for compliance data made no sense, and because analytics at scale is affordable when your storage is not priced by a vendor.
When those teams got the call that they were switching platforms, they had real options. They could negotiate from a position of some strength because leaving, while still hard, was genuinely feasible. That’s a different conversation than the one where you absorb a 25% renewal increase because you both know you can’t afford to leave. This advice pays off in a number of ways outside of migrations. Your team can take real control of its data, improve processes that need more data, and do it for less. It is rare to get more effective and more efficient at the same time. This is one of those cases.
None of this is fast, and if you’re mid-migration right now, some of it won’t help you this cycle. Do it anyway. The migration you’re in the middle of is not the last one you’ll ever do. Replacing proprietary agents, normalizing sources to OCSF, and storing logs in your own data lake instead of theirs saves effort for future migrations. The teams that eventually get out of this cycle are the ones who started building before they had a reason to.
But data ownership only gets you halfway. You can decouple every pipeline and still watch a migration fall apart because your team has spent four years becoming experts in one vendor’s query language and nobody has the bandwidth to learn a new platform while keeping the SOC running. That’s the next problem, and it’s the one that takes the longest to fix. We’ll get into it in the next post.
Next in the series: Building platform fluency. How to develop real SIEM expertise so your team owns the migration
