Microsoft Sentinel to Defender Portal Migration Guide (July 2026)

What's happening and when

Microsoft announced in late 2025 that the standalone Azure Portal experience for Sentinel — portal.azure.com → Microsoft Sentinel — will be retired in July 2026. Everything moves to the unified Microsoft Defender portal at security.microsoft.com, alongside Defender XDR.

More than a URL change: the unified portal changes how Sentinel and Defender XDR interact, with a merged incident queue, shared investigation graph, and an analytics engine spanning both products' signals.

Timeline:

• Q1 2026: unified portal GA, both portals available in parallel
• April–June 2026: Microsoft encourages migration, documentation updated
• July 2026: Azure Portal Sentinel experience retired; all access via security.microsoft.com

What changes in the unified portal

The incident queue is merged

Previously you had two queues: Sentinel incidents (from Log Analytics analytics rules) and Defender XDR incidents (from Defender for Endpoint, Defender for Identity, etc.). In the unified portal, all incidents appear in a single queue at Incidents & alerts → Incidents.

Microsoft's correlation engine can now link a Defender for Endpoint alert (suspicious process on a workstation) with a Sentinel analytics rule hit (anomalous Azure AD sign-in) and surface them as a single correlated incident, because both signals flow through the same pipeline.

Investigation experience

The investigation graph is unified. You can pivot from an Azure AD identity alert to endpoint artifacts (process trees, file events) to cloud resource activity (Azure Resource Manager logs) without switching views. Entity pages for users, devices, IPs, and cloud resources pull from both Sentinel and Defender XDR telemetry. The attack timeline spans identity, endpoint, cloud, and email. Alert evidence is consolidated in a single tab regardless of source.

Advanced hunting

In the Azure Portal, Advanced Hunting queried Log Analytics tables only. In the unified portal, it queries a superset:

Your existing KQL queries against Log Analytics tables still work. You can now extend them to join with Defender XDR tables (DeviceEvents, EmailEvents, IdentityInfo) in the same query.

Analytics rules

Existing analytics rules continue to work without modification — same Log Analytics workspace, same KQL, same schedule. The management UI moves from the Azure Portal to Microsoft Sentinel → Analytics within the Defender portal, nearly identical interface, re-homed.

Three new rule types in the unified portal: NRT (Near Real-Time) rules, now the recommended default for high-priority detections; Fusion rules, which now incorporate Defender XDR alert signals as inputs; and Threat Intelligence rules with improved matching against the merged Microsoft TI feed.

Workbooks

Workbooks are the most complex part. Workbooks stored in the Log Analytics workspace automatically appear in the unified portal under Threat management → Workbooks, but three things to check:

1. Deprecated controls: older workbook controls (legacy table visualizations, certain metric queries) may not render correctly. Update to the current ARM template spec.
2. Scope issues: workbooks saved at subscription scope may not appear automatically. Verify resource scope before migrating.
3. Broken deeplinks: any workbook links pointing to portal.azure.com/#blade/... will break after retirement. Update them to Defender portal equivalents.

Migration steps

1. Connect Sentinel to the Defender portal

1. Open security.microsoft.com, sign in as Global Security Administrator
2. Navigate to Settings → Microsoft Sentinel
3. Select your Log Analytics workspace and click Connect
4. Wait 10–30 minutes for initial data sync

Verify: Sentinel navigation items (Analytics, Incidents, Hunting) should appear in the left sidebar.

2. Audit your analytics rules

$WorkspaceName = "your-sentinel-workspace"
$ResourceGroup = "your-resource-group"

$rules = Get-AzSentinelAlertRule `
  -ResourceGroupName $ResourceGroup `
  -WorkspaceName $WorkspaceName

$rules | Select-Object DisplayName, Kind, Enabled, Severity, Tactics |
  Export-Csv -Path "analytics-rules-audit.csv" -NoTypeInformation

Review each rule: still relevant? KQL valid in the unified query editor? Severity and tactic mapping correct? This is also a good time to prune unused template-based rules — the unified portal can degrade noticeably with thousands of active rules.

3. Inventory and test workbooks

$WorkspaceId = (Get-AzOperationalInsightsWorkspace `
  -ResourceGroupName $ResourceGroup `
  -Name $WorkspaceName).CustomerId

Get-AzApplicationInsightsWorkbook -Category 'sentinel' |
  Where-Object { $_.SourceId -like "*$WorkspaceId*" } |
  Select-Object DisplayName, Location, TimeModified |
  Export-Csv -Path "workbooks-audit.csv" -NoTypeInformation

For each workbook: open in the unified portal, verify visualizations render, check queries return expected results, update any Azure Portal deeplinks.

4. Update RBAC assignments

Analysts who previously only needed Sentinel roles now also need Security Reader or Security Operator to use the unified investigation experience and Defender XDR features. This is the step that gets missed most often.

$GroupId = (Get-AzADGroup -DisplayName "SOC-Analysts").Id
$SubscriptionId = (Get-AzContext).Subscription.Id

New-AzRoleAssignment `
  -ObjectId $GroupId `
  -RoleDefinitionName "Security Reader" `
  -Scope "/subscriptions/$SubscriptionId"

5. Update automation rules and playbooks

Logic App playbooks using the Azure Sentinel connector continue to work. Microsoft is maintaining backward compatibility through 2026, but plan to update playbooks to the new Microsoft Sentinel (unified) connector by year-end.

6. Migrate custom parsers and data connectors

The Codeless Connector Platform (CCP) auto-migrates. The Log Ingestion API works without changes. Legacy agent-based connectors still function but Microsoft recommends moving to AMA (Azure Monitor Agent).

7. Update SOC runbooks and training

The hardest part of this migration isn't technical. SOC analysts have muscle memory for the Azure Portal — incident queue location, entity pivots, hunting workflows — and switching that takes real time, not just a lunch-and-learn. Plan a two-week parallel-portal period before the switchover.

What analysts need to relearn: incident queue location and filtering, entity pivot paths (now cross-product), the expanded Advanced Hunting table catalog, and where alert tuning lives (it now includes Defender XDR suppression rules).

Gotchas worth knowing

Multiple Sentinel workspaces each need to be connected to the Defender portal separately — there's no bulk connection.

The Defender portal routes some telemetry through Microsoft's US data centers for correlation. If you have GDPR or data sovereignty requirements, verify the data flow with your compliance team before migrating, not after.

Custom Fusion rules may conflict with the unified Fusion engine's built-in patterns and generate duplicate detections. Review them before connecting.

Check that your Conditional Access policies allow security.microsoft.com. This is a surprisingly common blocker on migration day.

SOAR platforms connecting via the Azure Sentinel REST API continue to work, but verify API versions — some older endpoints are being deprecated.

The upside

Correlated incidents that used to require 20 minutes of cross-portal pivoting now surface pre-correlated with full entity context. Fusion detections combining Sentinel cloud and identity signals with Defender XDR endpoint and email signals catch attack chains that neither product found independently. Security Copilot is embedded and context-aware across the full incident — summarization, KQL generation, suggested next steps. And instead of managing Sentinel roles and Defender roles separately, it's one role assignment.

July 2026 is a firm date. The technical work is the straightforward part. RBAC changes, runbook rewrites, and analyst retraining take longer than most teams budget for. Start with the audit scripts this week.