The problem
SIEM migrations are six-month, high-risk projects.
Re-onboarding every source, rewriting every parser and detection, and praying coverage holds — most teams put it off for years because the cutover is terrifying. There's simply no safe way to compare old and new.
Without Derwent Labs
Re-onboarding hundreds of sources from scratch
No parallel period to validate the new SIEM
A cutover with no rollback if coverage breaks
What you get
With Derwent Labs in front of your stack
Dual-write routing
Send the same normalised, enriched OCSF stream to both SIEMs simultaneously. No new agents, no new parsers.
Replay for validation
Replay historical events through the new SIEM's detection stack and compare results before you switch.
Cut over on your terms
Flip the destination when you're confident — no re-onboarding, no rewrite, no blind leap of faith.
Common questions
FAQ
- How do I migrate from Splunk to Sentinel without losing detections?
- Derwent Labs dual-writes the same normalised OCSF stream to both Splunk and Microsoft Sentinel simultaneously. Your detections run on both platforms during the migration period — so you can validate coverage on Sentinel before you cut Splunk off. No parsers to rewrite, no re-onboarding of sources.
- What is a dual-write SIEM strategy?
- Dual-write means routing the same data to two SIEMs in parallel during a migration. Rather than a hard cutover — where you go blind on the new platform until everything is re-onboarded — you run both SIEMs side-by-side, confirm detections fire correctly on the new one, and flip the switch when you are confident.
- Can I do a SIEM migration without losing detections?
- Yes. Because Derwent Labs normalises every source to OCSF before either SIEM sees it, detections written against OCSF data work on any destination. The dual-write period lets you replay historical events through the new SIEM's detection stack and compare results before you cut over.
- How long does a SIEM migration take with Derwent Labs?
- Most teams complete the parallel validation period in four to eight weeks rather than the six to twelve months a traditional migration takes. The time saving comes from eliminating re-onboarding: sources are already flowing through Derwent Labs, so adding a second destination is a single routing change.
- Does vendor lock-in affect SIEM migrations?
- Vendor lock-in is the core reason SIEM migrations are painful — detection rules written in Splunk SPL don't run on Sentinel KQL, and parsers built for one SIEM's ingestion pipeline have to be rebuilt from scratch. Normalising to OCSF before ingestion removes that dependency: your detection logic targets the schema, not the vendor.