Come April 2027 there is no Sentinel in the Azure portal. Nobody is recommending you move. There is a date.
Support for Sentinel in the Azure portal ends on 31 March 2027, and everybody still there gets redirected to the Defender portal. Every new capability already appears in the Defender portal first, with the old one now maintained for parity and nothing more. So the open question is when you move rather than whether. We plan and run that transition for American companies, remotely, on a schedule you choose.
- Mar 31, 2027Azure portal support ends
- No E5 requiredAvailable without Defender XDR or E5
- Unified queueOne incident queue for SIEM and XDR
- Maintenance onlyMicrosoft description of the Azure portal
Eight ways the two portals differ, and what each difference means once you are working in it.
The date, which is what ends the argument
Beyond 31 March 2027 Sentinel is supported only in the Defender portal, and anybody still using the Azure one is redirected there. The advice is to start planning now. Treat it as optional and the move still happens, except it happens on somebody else schedule, under a deadline, alongside everybody else who also left it late.
One incident queue instead of two
Today the Sentinel queue sits apart from the Defender one. In the new portal there is a single queue covering both, incidents arrive already enriched with Defender signals, and correlation across domains happens on its own rather than in somebody head. For a team currently working two queues and joining them up by hand, this is far and away the biggest change to the working day.
An attack story and a blast radius, rather than an investigation built out of logs
Investigating stops being an exercise in reading logs and becomes an attack story with a graph attached, where each device, person, address and Azure resource has one entity page combining data from both products. Blast radius analysis draws out how an attack could spread and what it would cost the business, which is a genuinely different question from what happens to be in the logs.
Hunting across SIEM, Defender, and the data lake together
Hunting in the new portal reaches across the SIEM, Defender and the data lake at once, works against the tenant and against workspaces, and reuses the queries and functions your team has already written. That last detail matters more than it sounds. Nothing your analysts have built over the past three years gets thrown away by moving.
Security Copilot, which does not exist in the Azure portal at all
Copilot is simply not available for Sentinel in the Azure portal. In the new one it writes incident summaries, walks somebody through a response, analyzes scripts and files, produces incident reports, and runs autonomous agents that triage alerts, brief on threat intelligence and hunt. There is included capacity for E5 and E7 customers, which is worth checking against whatever you already hold before assuming it is a purchase.
A data lake with tiered retention, and raw logs free for a month
The data model moves off Log Analytics and onto a central lake with tiered retention, easier onboarding and one schema spanning both products. Raw logs for hunting are free for thirty days with no ingestion charge at all. In companies where the cost of Sentinel has been an annual argument, this is the part genuinely worth modeling properly before the move.
Native multi-tenant, instead of Azure Lighthouse
Operating across multiple tenants stops depending on Lighthouse and becomes native, with delegation and management built in and incidents and alerts unified across every tenant. For a holding company, a private equity platform running several tenants, or anybody delivering security operations to clients, that is an architectural change rather than a change of screen.
One access control model across Defender, with row-level support
Permissions leave Azure role assignments behind and move into the unified Defender model, which supports row-level control. That is not cosmetic, and it is the single part of any transition most likely to catch a team out, because access that used to arrive through an Azure role has to be deliberately rebuilt on the other side rather than carried over.
Bring Sentinel over on its own and three capabilities arrive reduced.
Sentinel is generally available in the Defender portal even without Defender XDR or an E5 license, and it will run there with no other Defender service alongside it. What that costs you is also stated plainly.
- Exposure Management is limited or missing entirely, so the posture assessments and attack path recommendations that come with the full platform simply are not present.
- Custom detection rules, which come from Defender rather than from Sentinel, are limited or absent. Your Sentinel analytics rules carry on working exactly as before, so what this touches is authoring detections on the Defender side rather than anything you already own.
- The Action center, also a Defender component, is limited or absent. That is where remediation actions and their approval status are handled across the Defender products.
- None of that justifies delaying, because the deadline applies to you either way. What it does justify is being precise about what the destination actually looks like given your particular licensing, so that nobody hits week two, finds something missing, and concludes the whole migration went wrong.
Four things that decide whether this is a boring migration, which is what you want.
We rebuild permissions deliberately rather than assuming they carry
Access leaves the Azure role model and moves into the unified Defender one, which supports control at row level. Anything currently working through an Azure role has to be rebuilt deliberately on the other side. This is where surprises come from more than anywhere else, and it announces itself as an analyst who cannot open an incident during their first shift in the new portal.
We rewrite the analyst runbooks against the new navigation
Logs is now advanced hunting. Entity behavior is now entity pages under assets. Workspace manager, along with news and guides, has gone entirely. An analyst working an old runbook at speed, under pressure, concludes the capability was removed rather than relocated, and that is exactly how a migration that succeeded technically gets written off as a failure by the people living in it.
The unified queue is a change to how people work, not a change of layout
Going from a separate Sentinel queue to a single one carrying automatic enrichment and cross-domain correlation changes how triage is done and what an incident even contains. Walk a team through it using real incidents and they adapt within days. Move them overnight and they spend a fortnight not trusting the correlation, and a few of them start switching things off.
Before anybody buys anything, we check what is already covered
Copilot does not exist for Sentinel in the Azure portal and does exist in the Defender one, and there is included capacity for E5 and E7 customers. Companies routinely arrive at this transition assuming Copilot is a separate purchase when a portion of it is already paid for. Establishing that at the start changes what the destination looks like entirely.
Six US situations where the transition deserves planning now.
A regulated firm with a documented security operations process
Wherever a written process has been shown to an examiner, a SOC 2 auditor, an assessor under NYDFS Part 500 or a large customer, this transition changes both the interface those procedures describe and the permission model sitting behind them. Updating the documentation belongs inside the migration rather than after it, because a procedure that no longer matches reality is itself a finding.
A managed service provider or a group with several tenants
Multi-tenant operations move from Azure Lighthouse to native multi-tenant operations with unified cross-tenant incidents and alerts. That is an architectural change rather than a portal change, and for anybody delivering security operations across client tenants it deserves its own planning rather than being folded into a general migration.
An organization running Sentinel without Defender XDR
Entirely supported, and Microsoft is explicit that Sentinel is available in the Defender portal including for customers without Defender XDR or an E5 license. It is also the case where the three limited capabilities apply. Being precise about what the destination looks like on your licensing avoids the conclusion that something went wrong.
A team that has invested heavily in workbooks and queries
Reassuring news: advanced hunting in the Defender portal supports hunting in the tenant and in workspaces and the reuse of existing Sentinel workspace queries and functions, and workbooks move to a new location rather than disappearing. A transition is nonetheless a good moment to retire the ones nobody has opened in a year.
An organization where Sentinel cost is under pressure
The data model moves from Log Analytics-centric to a centralized data lake with tiered retention and a unified schema across Sentinel and Defender, and Microsoft notes advanced hunting raw logs are free for thirty days without ingestion. Where ingestion cost has been the recurring argument internally, modeling this properly during the transition is worth the effort.
An organization with a small team and no slack
The hardest case, because there is no capacity for a project and the deadline applies anyway. Here the answer is a staged transition with a clearly owned plan, or a managed arrangement covering the operations while the move happens. What does not work is deferring until the redirect happens automatically.
Where US organizations running Sentinel currently stand.
| Feature | Transitioned | Aware, not planned | Unaware of the deadline |
|---|---|---|---|
Working in the supported portal after March 2027 | Yes | Eventually | Not yet |
One incident queue for SIEM and XDR | Yes | No | No |
Cross-domain correlation automatic | Yes | No | No |
Attack story and blast radius analysis | Yes | No | No |
Security Copilot available | Yes | No | No |
Receiving new Sentinel capabilities first | Yes | No | No |
Permissions rebuilt in the new RBAC model | Yes | Not started | Not started |
Runbooks match the interface analysts use | Yes | Yes for now | Yes for now |
Transition happening on your schedule | Yes | Unlikely | No |
Frequency in the US market | Uncommon | Common | Common |
The navigation changes your team will run into inside the first hour.
Azure portal
Logs
- Defender portal
- Investigation and response, then Hunting, then Advanced hunting
Azure portal
Incidents
- Defender portal
- Investigation and response, then Incidents and alerts, then Incidents
Azure portal
Workbooks, Hunting, Notebooks, MITRE ATT&CK
- Defender portal
- Microsoft Sentinel, then Threat management
Azure portal
Threat intelligence
- Defender portal
- Threat intelligence, then Intel management
Azure portal
Entity behavior
- Defender portal
- Entity pages sitting under assets, each user or device carrying its Sentinel events
Azure portal
Data connectors, Analytics, Watchlists, Automation
- Defender portal
- Microsoft Sentinel, then Configuration
Azure portal
Content hub, Repositories, Community
- Defender portal
- Microsoft Sentinel, then Content management
Azure portal
Settings
- Defender portal
- System, then Settings, then Microsoft Sentinel
Azure portal
Workspace manager
- Defender portal
- Not available
Azure portal
News and guides
- Defender portal
- Not available
Five steps, ideally starting well before the deadline.
- 1
Assess the current environment and the destination
Workspaces, connectors, analytics rules, playbooks, workbooks, and integrations, plus what the Defender portal looks like on your specific licensing including whether Security Copilot capacity is included and whether the three limited capabilities apply to you.
- 2
Map the permission model
Every access path currently granted through Azure role-based access control, reproduced deliberately in unified Defender role-based access control, using row-level support where the current model depends on it. This is the step that most often causes a bad first day if it is skipped.
- 3
Onboard and run both in parallel
Onboarding integrates Sentinel with Defender automatically rather than requiring the Defender XDR connector to be enabled separately. Running in parallel lets the team work real incidents in the new portal while the familiar one is still there, which is what makes the change survivable for a small team.
- 4
Rewrite the runbooks, then sit the team down in front of the new queue
The navigation gets updated to reflect what moved and what disappeared, then a hands-on session covering the single queue, the attack story, entity pages and blast radius analysis, worked through using real incidents out of your own environment. Two hours spent here saves a fortnight of analysts quietly distrusting everything.
- 5
Adopt what the Azure portal never had
Copilot summarizing incidents and guiding a response, the assisted playbook generator, case management for investigations spanning several incidents, and the optimization recommendations. These are what make the move worth doing rather than merely unavoidable, and they land best once the team has stopped thinking about the interface.
What organizations ask about the Sentinel transition.
Fifteen questions worth answering first.
Scope
- How many workspaces are in scope?Workspace manager is not available in the new portal.
- Do you have Defender XDR, or Sentinel alone?Both are supported, with a documented capability difference.
- Are you multi-tenant or using Azure Lighthouse?Native multi-tenant operations replace it.
- Is Security Copilot capacity included in your subscription?Microsoft states included capacity for E5 and E7.
- When does your current Sentinel commitment renew?A useful anchor for planning the move.
What needs redoing
- How is access currently granted through Azure RBAC?It moves to unified Defender RBAC.
- Do you rely on row-level access control?Supported in the new model, and needs configuring.
- Which playbooks are in active use?Automation comes across, and it is worth reading rather than copying over unexamined.
- Are your workbooks still used, or historical?A move like this is the right moment to retire the ones nobody uses.
- Do integrations use Sentinel APIs?The API surface is unified.
Your team
- Who works incidents day to day?They meet the unified queue first.
- Are runbooks written against Azure portal navigation?Several items moved and two were removed.
- Is anybody trained on Defender portal investigation?Attack story and entity pages are a different model.
- Do you have after-hours coverage?Do not transition into an unstaffed window.
- Who owns the transition end to end?Without an owner it stalls at partially migrated.
The pages around this one.
Microsoft Sentinel
The platform underneath all this: connectors, analytics rules, automation, and what deploying a SIEM actually involves.
SOC as a service
The managed route, for companies without the capacity to run their own security operations through a change like this.
Microsoft Defender XDR
The Defender half of the same platform, and how the two halves fit together once they share a portal.
Get 31 March 2027 into the plan while it is still a project and not yet a deadline.
Every company still running Sentinel in the Azure portal is looking at the same date, and the help available will bunch up toward the end of it. Start now and you get parallel running, your own pace, and the chance to adopt what is new on purpose.
Related Services
Explore more solutions that work great with this service
Microsoft Sentinel SOC Optimization
Sentinel SOC optimization reviews for US organizations: ingestion
Learn moreMicrosoft Defender XDR Services
One incident queue across endpoint, email and identity
Learn moreMicrosoft Sentinel
Cloud-native SIEM and threat intelligence
Learn moreSOC-as-a-Service
24/7 security operations delivered as a service
Learn moreManaged Security Services
Managed security services (MSS) for US businesses, delivered remotely
Learn moreMicrosoft Security Services
The Microsoft security stack deployed and managed end to end
Learn more