Migrating to Unified SecOps Without Breaking Detection
Agentic SOC Series
In Article 01, we covered the design decisions that define detection capability: what stays hot, what moves to the lake, what gets dual-ingested, and who owns the decision.
Now comes the uncomfortable part.
You have to move.
The migration to Microsoft unified security operations and the Sentinel data lake is not a rip-and-replace project. It is not a portal cleanup exercise. It is an operating model change that touches detection engineering, threat hunting, incident response, retention, cost, and ownership.
If you rush it, you can break the detections you already trust.
That is the risk most teams underestimate.
The target state
The target is simple to describe and harder to execute:
Microsoft Defender portal and Defender XDR become the unified SecOps layer for incidents, evidence, cross-domain correlation, and response.
Microsoft Sentinel remains the security data and analytics layer for custom data, KQL, longer retention, lake patterns, and advanced investigation.
The Sentinel data lake becomes the place for high-volume telemetry, historical context, hunting depth, and long-retention analysis.
Humans, playbooks, and agents operate on top of that substrate, with clear ownership and approval boundaries.
This is where Agentic SOC messaging matters.
The goal is not to move data because the platform changed. The goal is to give analysts, playbooks, and agents reliable evidence in the place where each workflow needs it.
The migration rule
Here’s what worked: move one telemetry family at a time.
Start with identity.
Identity data is usually the highest-value migration candidate because it touches initial access, credential abuse, lateral movement, risky sign-ins, cloud app activity, and blast-radius analysis. It is also where schema mistakes hurt quickly.
Here is what worked better than big-bang migration:
Assess. Inventory the detections, playbooks, dashboards, hunting queries, and reports that depend on the source.
Dual-write. Send the critical source to the old path and the new architecture during transition.
Validate parity. Confirm the same events produce the same detections before cutover.
Cut over deliberately. Move the workflow only after schema, latency, retention, and alert behavior are understood.
Document ownership. Record who owns the source, schema changes, retention decisions, and downstream detection impact.
That sequence is slower than “flip the connector.”
It is also how you avoid breaking the SOC.
What goes wrong
The failure mode is predictable.
A team moves identity logs over a weekend. The connector works. Data arrives. Dashboards look healthy. Everyone relaxes.
Then the analytics rules start returning zero results.
Not errors. Zero results.
The schema changed just enough to break the logic. Conditional access fields moved. Nested properties flattened. Token and authentication details landed differently. The query still runs, but it no longer detects the behavior it was written to catch.
That is worse than a failed deployment because it looks successful.
The lesson is simple: never cut over a telemetry family until every downstream detection has been tested against the new shape of the data.
SOAR breaks too, and quietly
Detection is not the only thing that breaks here. Automation does too.
When a Sentinel workspace is onboarded to the Defender portal, Defender XDR owns the incident. Sentinel automation rules that fired on incident creation may not fire the way they used to. Logic Apps playbooks attached to those rules can stop running, or run against an incident shape that no longer carries the cross-domain context Defender added. Tagging, severity, owner assignment, and ticket creation all drift.
Re-evaluate every automation rule and every playbook before cutover. Rebuild incident-trigger automation in the Defender XDR automated response model where it fits. Keep Sentinel-side automation only for workflows that depend on Sentinel-specific signals like custom analytics, watchlists, and entity logic. Update Logic Apps inputs to match the unified incident schema. Confirm the run-as identity has the right roles.
Skip this step and you ship a SOC that looks automated and is not.
Same failure pattern as zero-result detections, just one layer up.
The data lake is not a dumping ground
The Sentinel data lake changes the economics of retention, but it does not remove the need for design.
Hot-path detections still belong where they can alert quickly. High-volume, long-retention sources belong in the lake when their main value is hunting, forensics, trend analysis, and context. Some sources need both.
Data federation adds another option: query data where it already lives in places like Fabric, ADLS Gen2, or Azure Databricks instead of copying it again. That can be useful for historical archives, compliance-constrained data, and specialized datasets.
But treat federation carefully. Microsoft documents Sentinel data federation as preview. Custom graphs and Sentinel MCP are also preview-sensitive patterns. They are useful architecture directions, but they should not be baseline migration dependencies until feature status, licensing, region, and tenant readiness are verified.
The safe framing is this:
Use GA capabilities as the foundation. Use preview capabilities as optional acceleration paths with clear disclosure.
The operating model has to move too
Unified SecOps collapses old team boundaries.
An incident may include identity, endpoint, cloud, SaaS, email, and data signals. A detection may depend on Sentinel data, Defender XDR context, and Purview alerts. A future agent may need read access to evidence but no authority to execute response.
That means ownership has to change.
Before cutover, decide:
Who owns schema changes?
Who owns retention policy?
Who validates detection parity?
Who approves response actions?
Who reviews agent-accessible data?
If those answers are unclear, the platform may be unified, but the operating model is not.
Executive Summary for Security Leadership
Unified SecOps migration is an operating model change, not a portal move.
Move one telemetry family at a time, starting with identity.
Dual-write and validate detection parity before cutover.
Re-evaluate every Sentinel automation rule and Logic Apps playbook against the unified incident model before cutover.
Treat data federation, custom graphs, and Sentinel MCP as preview-sensitive unless verified for your tenant.
Assign ownership for schema, retention, detection parity, and agent-accessible data before migration completes.
What is next
Start with one telemetry family. I would start with identity.
Map where it goes today, what depends on it, where it needs to live in the target architecture, and what would break if the schema changed. Then dual-write, validate, and cut over.
Article 03 covers threat hunting with KQL and the data lake. Once the data is in the right place, the next question is how to use it.
This is Article 02 of “The Agentic SOC on Microsoft Sentinel” series on socautomators.substack.com.