I’ve run this migration in tenants from single-workspace SMB through to multi-region MSSP delivery. The data plane stays put, in your Log Analytics workspace. The operator surface moves to security.microsoft.com, and the friction sits in RBAC, KQL scope, and incident schema. This is written for SOC engineers and platform owners who own the cutover, not the people who approve it.
What Actually Changes
The Azure portal Microsoft Sentinel blade gives way to security.microsoft.com. Onboarding is per-tenant via Microsoft Sentinel → Settings → Defender XDR, and selects one primary workspace. Sentinel surfaces as a left-rail node beside Investigation, Email & Collaboration, Endpoints, and Identities. Authoring still uses the Sentinel pages. The chrome around them is unified.
Incidents are the largest functional change. The SecurityIncident table is still the source of truth for Sentinel-origin alerts, but the incident object now correlates with Defender XDR alerts natively. The M365 Defender connector that previously bridged alerts is no longer required for correlation. Watch for duplicate IncidentName values during the first week. The unified engine suppresses duplicates by AlertId graph, not by name.
Hunting moves into Advanced Hunting. Sentinel tables (SecurityEvent, SigninLogs, AzureActivity) coexist with Defender tables (DeviceProcessEvents, DeviceLogonEvents, EmailEvents, IdentityLogonEvents, AlertEvidence). The data is federated, not co-located. Cross-estate joins use standard KQL, but Defender tables still cap at 30-day lookback regardless of your workspace retention.
APIs split. The Sentinel REST API is stable. The unified incident graph uses Microsoft Graph Security API, where alert and incident IDs are GUIDs. If your tooling persists Sentinel integer incident IDs, plan a schema change. Workbooks and Notebooks remain hosted in Azure and open in a new tab. Ingestion costs, commitment tier, retention, and Azure RBAC on the workspace do not change.
Things to Avoid
Wrong primary workspace selection. Onboarding is one-shot per tenant. Secondary workspaces remain in classic Sentinel only. If you pick the dev workspace, your production analysts lose the unified queue until you raise a support case in some toggle versions. Decide which workspace owns production identity, endpoint, and email correlation before clicking onboard.
Assuming RBAC inherits. Defender XDR Unified RBAC does not absorb Sentinel role assignments. A user with Microsoft Sentinel Responder sees Sentinel content only until you grant a Defender role. Plan the mapping: Sentinel Reader to Security Reader, Sentinel Responder to Security Operator, Sentinel Contributor to Security Admin or a scoped equivalent. Move to Defender XDR Unified RBAC rather than the legacy Defender role model so scoping is consistent across products.
Logic App and automation rule breakage. Two failure modes show up repeatedly. Webhook templates that embed portal.azure.com deep links route analysts back to the old surface. Playbooks that parse incident.Id as integer fail against Defender XDR GUIDs. Rebind triggers to the modern Microsoft Sentinel incident V2 schema, refresh managed identity permissions to include both SecurityIncident.ReadWrite and the Microsoft Graph Alert.ReadWrite.All scope, and retest adaptive card renders in Teams.
Implicit KQL scope. Custom analytics rules and hunting queries that call MyFunction() without an explicit workspace("name") prefix resolve fine in single-workspace tenants. In multi-workspace setups they miss data silently. Either consolidate functions into the primary workspace or qualify every reference. ASIM parsers behave the same way.
Lighthouse and MSSP delivery. Azure Lighthouse delegations still work from the Azure portal. The unified Defender portal does not expose delegated tenants in a single picker. For MSSP analysts, this means two windows during the transition or a B2B guest pattern into each customer tenant. Confirm with your delivery team before any customer-facing flip.
One-click connector enablement. The new portal makes enabling Defender for Identity, Defender for Cloud Apps, or Defender for Cloud feeds trivial. Each one drops billable data into the workspace without filtering. Stage connector onboarding, apply DCR transforms where available, and tune analytics rules before traffic flows.
No rollback rehearsal. Offboarding is reversible but produces a split workflow while it happens. If a hunting query, watchlist function, or playbook breaks at cutover, detection time is the cost. Plan a maintenance window and pre-stage the rollback runbook even though the platform does not require it.
Things to Confirm in Complex Environments
Hunting query parity. Run your top 20 saved queries and your top four to six analytics rules through Advanced Hunting under security.microsoft.com. Validate that _GetWatchlist() returns rows, ASIM normalisation tables resolve, custom functions inherit the right workspace context, and cross-workspace joins via workspace("x").Table still parse.
Incident correlation behaviour. Trigger a known multi-stage pattern: a synthetic risky sign-in followed by an endpoint alert. Confirm a single merged incident with both alert IDs in the graph. Inspect SecurityIncident for duplicate IncidentName rows during the first 24 hours. If you see them, the M365 Defender connector likely still has Create Incident enabled and should be set to Alert only.
Automation rule and playbook regression. Export every automation rule and Logic App. Validate trigger schema (Sentinel incident V2), webhook URL templates, managed identity permissions including the Graph Alert.ReadWrite.All scope, and adaptive card rendering in Teams with the new GUID incident ID. Re-run any playbook that touches comments, tags, or owner assignment.
Workbooks and dashboards. Each Sentinel workbook opens in Azure. Decide per workbook: rebuild as a Defender XDR custom report, keep in Azure with a documented deep link, or move to Power BI for executive distribution. Power BI templates against the Log Analytics endpoint do not change, but templates with portal.azure.com drill-throughs break.
REST API and SOAR consumers. Validate every external integration end to end. The Sentinel REST API is stable. Graph Security API alert and incident IDs are GUIDs. SOAR connectors (XSOAR, Tines, Torq) need the version that supports the unified incident schema. Re-test Azure ML notebooks that hydrate incident context.
Reporting and audit pipelines. SentinelHealth, LAQueryLogs, and SecurityIncident exports to Event Hub stay stable. Confirm Power BI templates, compliance exports, and any data-warehouse pipelines still parse the incident object. Audit your role mapping against the SOC 2 or ISO control set if you operate under one.
SOC runbooks. Update screenshots, escalation steps, and the click paths for triage, comment, assign, and close. Add a section on cross-portal jumps (workbooks, classic data connectors) so analysts know when they are leaving the unified surface.
The Pragmatic Call
If you’re single-tenant, single-workspace, with Defender for Endpoint or Office already live, onboard now. The unified incident queue removes a class of cross-portal correlation work, and the GUID schema is forward-compatible.
If you’re multi-tenant, multi-workspace, or MSSP-delivered, pilot in a non-prod tenant, codify the role mapping in PIM or IaC, refactor Logic Apps to the V2 incident trigger, and stagger the rollout. The platform is mature. Your KQL, your automation, and your runbooks are what survive or do not survive contact with the new interface.