Microsoft Sentinel to Defender Portal Migration Guide (2026-2027)

What's happening and when

Microsoft Sentinel is generally available in the Microsoft Defender portal at security.microsoft.com. Microsoft states that after March 31, 2027, Sentinel will no longer be supported in the Azure portal and will be available only in the Defender portal. If your SOC still works primarily from portal.azure.com, the migration is no longer optional planning work. It is a dated operational program.

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:

• 2026: Defender portal experience is generally available and recommended for Sentinel operations
• 2026-2027: both portal experiences may exist in parallel for many customers, but new and improved capabilities increasingly land in the Defender portal
• March 31, 2027: Azure portal support for Sentinel ends; customers are redirected to the Defender portal

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.

March 31, 2027 is the firm support deadline. 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.

Frequently Asked Questions

What is the deadline for migrating Microsoft Sentinel to the Defender portal?

Microsoft has announced that the Azure portal experience for Microsoft Sentinel will lose support after March 31, 2027. After that date, Sentinel management will be available only through the Microsoft Defender portal at security.microsoft.com. Workspace functionality (data ingestion, analytics rules, playbooks) continues running regardless of which portal you use; the deadline affects the management interface, not the underlying platform. Organizations should plan to complete their migration to the Defender portal well before that deadline to allow time for analyst retraining and runbook updates.

What changes for analysts when Sentinel moves to the Defender portal?

The main workflow changes are in incident management, investigation pivoting, and KQL querying. Incidents are now in the unified Defender XDR incident queue alongside Defender endpoint, email, and identity alerts rather than in a separate Sentinel incidents blade. Advanced Hunting now queries both Sentinel tables and Defender XDR tables in a unified workspace, expanding the available table catalog significantly. Alert tuning now encompasses both Sentinel analytics rule suppression and Defender XDR suppression rules in a unified interface. Entity investigation pivots (users, devices, IPs) now show cross-product context including Defender data. Analysts should expect 2 to 4 weeks to build fluency with the new navigation paths.

Does the Defender portal migration affect Sentinel RBAC and how should it be updated?

Yes. The Defender portal uses Microsoft Defender XDR roles rather than the Sentinel-specific roles (Microsoft Sentinel Reader, Contributor, Responder) that analysts may currently have. The unified roles are: Security Reader, Security Operator, Security Analyst, and Security Administrator. You must audit current Sentinel role assignments and map them to the equivalent Defender XDR roles. The migration is also an opportunity to apply least privilege more rigorously: Sentinel Contributor gave broad write access; the equivalent Defender XDR roles can be scoped more narrowly to specific functions. RBAC changes require careful communication to avoid locking out analysts on migration day.

What SOAR and playbook integrations need to be checked before migration?

Any SOAR platform or custom integration connecting to Sentinel via the Azure Sentinel REST API continues to work after migration, but some older API endpoints are being deprecated as part of the unified platform consolidation. Check your integration's API version against Microsoft's deprecation notices. Logic Apps playbooks connected to Sentinel analytics rules migrate with the workspace but should be tested in the Defender portal environment. Custom connector configurations referencing Azure portal URLs in webhook configurations may need updating. Integrations using the Microsoft Sentinel solution from the Defender portal's SOAR tab are typically unaffected.

What is the benefit of the unified Defender portal over managing Sentinel and Defender XDR separately?

The primary security benefit is correlated incident detection across signal types that were previously in separate products. Fusion detections in the unified portal combine Sentinel cloud and identity signals with Defender XDR endpoint, email, and identity alerts, catching attack chains that neither product detected independently when operating in isolation. The operational benefit is reduced context-switching: investigations that previously required pivoting between the Azure portal, Defender portal, and Entra ID portal now surface pre-correlated with full entity context in one interface. Security Copilot is context-aware across the full unified incident, providing summarization and KQL generation with complete cross-product context.