Microsoft Sentinel leaves the Azure portal on March 31, 2027: what breaks and what to do first

Microsoft Sentinel stops being supported in the Azure portal after March 31, 2027. After that date every customer is redirected to the Microsoft Defender portal and uses Sentinel there only.

That date moved. Microsoft first announced July 2026, then extended it in February 2026. An earlier version of this post said July 1, 2026. That was the old date, and we have corrected it. The source of truth is the retirement timeline in Microsoft's Sentinel overview.

The extension buys time. It does not change the work. Here is what actually changes when a workspace moves, based on Microsoft's transition guide and what we see on client tenants.

What does not change

Start here, because it calms a lot of nerves.

• Cost. Moving to the Defender portal is free, even without E5. You keep paying for Sentinel consumption as before.
• Storage. Your data stays in the same Log Analytics workspace. Tables, KQL queries and functions carry over and show up in Advanced hunting.
• Third-party connectors. Non-Microsoft data connectors keep running without interruption.
• Analytics rules. Rule creation, editing and management work the same, through the wizard, repositories or the Sentinel API.
• Workbooks. Azure workbooks remain the main visualization tool and work as they did.

What breaks: automation first

Automation is where we see the real breakage. Check these before you onboard a production workspace.

The incident provider condition is gone. Every incident now has Microsoft XDR as its provider. An automation rule that was scoped to "Microsoft Sentinel" incidents now runs on Defender XDR incidents too. Scope rules by analytics rule name instead.

SecurityIncident loses its Description field. Any automation rule that uses Description as a condition stops matching. ServiceNow and other ticketing integrations that copy the description get an empty field.

Incident titles can change. The Defender correlation engine may rename or merge incidents. Rules keyed on incident title are fragile. Use analytics rule names and tags.

Timing gets looser. Microsoft documents up to 5 minutes for Defender incidents to reach Sentinel, and up to 10 minutes before an automation rule runs. Several changes to one incident within 5 to 10 minutes arrive as a single update with only the latest change. Any playbook that depends on seeing each state change in order needs rework.

Some manual actions are missing. You cannot run a playbook manually on an alert or an entity in the Defender portal. You also cannot create an automation rule directly from an incident there.

What changes in detection

Fusion is switched off. The Fusion multistage rule is disabled when you onboard. The Defender XDR correlation engine takes over. You do not lose correlation, but incidents will group differently than your analysts are used to.

Alert grouping is no longer yours. Grouping settings still show in analytics rules, but the Defender engine decides grouping and merging. Rules set to one incident per alert may still merge.

Alerts-only rules disappear from view. Analytics rules configured to create alerts with incident creation turned off produce alerts you cannot see in the Defender portal. Turn incident creation on or accept they are invisible.

Microsoft incident creation rules are deactivated. They would create duplicates of Defender XDR incidents, so onboarding turns them off.

What changes in access and data handling

Unified RBAC. The Defender portal uses unified role-based access control. Map your existing Sentinel roles before cutover so analysts do not lose the incident queue on day one. Microsoft's RBAC mapping guide is the reference.

IdentityInfo loses table-level RBAC. It becomes a native Defender table. If you restricted it with table-level RBAC, that control is gone after the move.

Privacy policies switch. In the Defender portal, the Defender XDR data privacy policies apply, even to Sentinel data. Your compliance team should read them.

Customer-managed keys. Existing workspace data stays CMK-encrypted. Alerts and incidents do not after onboarding, and data lake storage uses Microsoft-managed keys.

Multi-workspace and MSSP setups

In the Defender portal you pick one primary workspace per tenant. The Defender XDR connector attaches to the primary only. Standalone Microsoft security connectors are disconnected in secondary workspaces to avoid duplicate alerts. Only primary-workspace alerts correlate with Defender XDR data.

Workspace Manager is not available in the Defender portal. Use repository deployment (content as code from GitHub or Azure DevOps) or the Defender multitenant portal instead.

The order we run it in

1. Inventory automation. List every automation rule and playbook. Flag any that use incident provider, Description, incident title, or manual alert and entity triggers.
2. Map RBAC. Build the unified RBAC role map and test it with a real analyst account, not an admin.
3. Pick the primary workspace. Decide this before onboarding. It controls which alerts correlate.
4. Onboard a non-production workspace first. Run it for two weeks. Compare incident counts and grouping against the Azure portal view.
5. Fix the automation you flagged. Then onboard production.
6. Retrain the triage process. The unified incident queue mixes SIEM and XDR alerts. Tier 1 and tier 2 boundaries usually move.

New customers onboarding their tenant's first Sentinel workspace with Owner or User Access Administrator rights, and not through Azure Lighthouse, already go straight to the Defender portal. If you are an existing customer, the work above is yours to schedule. Doing it in a quiet quarter beats doing it the week of March 31, 2027.

If you want a second pair of eyes on the automation inventory, our detection engineering practice can run it with you. Request a review.