Is this transition actually forced, and by when?

Yes, on a published date. Microsoft states that after 31 March 2027 Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal, and that remaining Azure portal customers will be redirected. Microsoft recommends planning now. The only real decision left is whether the move happens on your schedule, with parallel running and rehearsal, or on the deadline.

Do we lose any data, incidents, or history in the move?

No. Your Log Analytics workspace is not moved or copied, it is connected to the Defender portal. Historical logs, incident records, retention settings, watchlists, and workbooks all remain. Unified advanced hunting explicitly supports reuse of your existing workspace queries and functions. The things that need active work are permissions, automation validation, and navigation, not data.

Do our analysts need retraining?

Orientation more than retraining. KQL is unchanged, and detection logic is unchanged. What changes is navigation, several destinations moved and two disappeared, and the investigation model, a unified incident queue with automatic Defender enrichment, attack stories, and entity pages instead of a log-first workflow. We run working sessions on genuine incidents from your own environment; most teams are comfortable within days when it is rehearsed, and distrustful for weeks when it is not.

What happens to our playbooks and automation rules?

They carry across, and they are also the most common thing to break. Logic Apps playbooks run under managed identities and API connections that were authorised in the Azure RBAC world, and after the move a playbook can trigger but fail to act, or fail to trigger at all. We dry-run every active playbook against test entities and re-verify automation rule triggers before cutover, so this is caught in validation rather than during an incident.

We run multiple workspaces and multiple tenants. How is that handled?

With a mapping exercise before anything is onboarded. Each workspace connects to a tenant in the Defender portal, so multi-workspace estates need the workspace-to-tenant design and onboarding order fixed first. Workspace manager has no equivalent in the new portal, so central management practice needs a designed replacement. Cross-tenant access moves from Azure Lighthouse to native multi-tenant operations, which for MSSPs and group companies is its own planning track.

Does our billing change?

The commercial model keeps the same shape, you pay for ingestion and retention on your existing plan, and moving portals does not by itself change what you are billed for. What does change is the underlying data model, which moves toward a centralised data lake with tiered retention, and Microsoft notes advanced hunting raw logs are available for thirty days without ingestion applying to that tier. Those are new levers worth remodelling during the transition, and we review them with you without quoting numbers a webpage cannot responsibly quote.

We are an MSSP. What happens to our client access?

It changes architecturally. Azure Lighthouse delegation, the standard MSSP pattern in the Azure portal, is replaced by native multi-tenant operations in the Defender portal, with unified cross-tenant incidents and alerts. Every existing delegation needs an inventory and a designed equivalent, and unified RBAC has to be configured per tenant, including row-level access where client separation depends on it. We plan this track separately from, and before, the tenant-by-tenant migration.

What is limited if we use Sentinel without Defender XDR?

Microsoft documents three capabilities as limited or unavailable in that configuration: Microsoft Security Exposure Management, custom detection rules that are provided by Defender, and the Action center. Your Sentinel analytics rules, hunting, workbooks, and automation all continue to work, the gaps are on the Defender side of the unified platform. Sentinel is generally available in the Defender portal without Defender XDR or an E5 licence, so none of this blocks the move.

What genuinely improves after the move?

The unified incident queue with automatic Defender correlation, so analysts stop joining two consoles by hand. Attack story and incident graph investigation with entity pages and blast radius analysis. Advanced hunting across SIEM, XDR, and the data lake in one query surface. Security Copilot, which does not exist for Sentinel in the Azure portal. Case management for multi-incident investigations. And every new Sentinel capability from now on, because Microsoft ships them to the Defender portal first.

Can we run both portals during the transition?

Yes, until retirement, and we actively recommend it. Parallel running lets analysts work real incidents in the Defender portal while the familiar console is still available, which is what makes the change survivable for a small team. It also surfaces permission gaps and playbook failures inside a controlled window. The mistake is not using the window deliberately, drifting until the redirect makes the decision for you.

How long does a transition take, and is it disruptive?

Most Indian organisations complete it in 4-8 weeks, driven by workspace count, automation depth, and team size. Detection coverage never stops, the workspace keeps ingesting and rules keep firing throughout. The onboarding itself is quick; the weeks go into RBAC mapping, playbook validation, runbook rewrites, and analyst rehearsal, which is exactly where they should go. Done this way, cutover day is an anticlimax.

Can you run our SOC after the transition?

Yes. Many clients use the transition as the moment to move to a managed model, the same team that mapped your permissions and validated your playbooks then operates the unified portal day to day. Managed SOC clients get 24/7 monitoring, incident response on a 30 minutes response SLA, detection tuning, and monthly reporting suitable for CERT-In and SEBI CSCRF evidence, delivered remotely from Hyderabad across India.

Everything is delivered remotely?

Yes, remote-first from Gachibowli, Hyderabad. A portal transition is inherently remote work, assessment, RBAC mapping, onboarding, validation, and training all happen in your tenant over screen-share and scheduled workshops, wherever in India your team sits. Initial enquiries receive a reply within 4 business hours. If your governance requires on-site workshops for sign-off, we schedule them from Hyderabad.

Sentinel to the Defender portal, India

Microsoft is retiring Sentinel in the Azure portal. We move you to the Defender portal without losing a single detection.

After 31 March 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will run only in the Microsoft Defender portal, the unified security operations platform. Every new Sentinel capability already lands in the Defender portal first. We plan and execute the transition for Indian organisations so your detections, automations, watchlists, and incident history arrive intact, delivered remote-first from Gachibowli, Hyderabad.

Book a transition review See what actually changes

Microsoft

Sentinel

Cloud Solution Partner

31 Mar 2027Azure portal support ends
ZeroDetections lost in transition
One queueUnified SIEM and XDR incidents
Remote-firstDelivered across India

What actually changes

Eight differences between the two portals, and what each means for your SOC.

Microsoft describes the Defender portal as the long-term home for Sentinel and the primary innovation surface, with the Azure portal in maintenance and parity mode only. These are the changes a working Indian security team will actually feel, separated from the things that stay exactly where they are.

The retirement date removes the debate

Microsoft states that after 31 March 2027 Sentinel will no longer be supported in the Azure portal, and that every remaining customer will be redirected to the Defender portal. This is not deprecation-someday language, it is a published date. Organisations that plan now transition on their own schedule with parallel running and rehearsal. Organisations that wait transition on Microsoft's schedule, in the same crowded quarter as everyone else who waited.

One incident queue instead of two

In the Azure portal, Sentinel incidents live in a queue separate from Defender. In the unified platform there is a single incident queue for SIEM and XDR where incidents are automatically enriched with Defender signals and correlated across domains using machine learning. For a SOC that currently swivel-chairs between two consoles and joins alerts by hand, this is the largest day-to-day change of the entire move.

Attack story replaces log-centric investigation

Investigation moves from log-first workflows to an attack story and incident graph, with unified entity pages for users, devices, IP addresses, and Azure resources that combine Sentinel and Defender telemetry on one screen. Blast radius analysis visualises how an attack could propagate and what business impact it carries, which is a different and better question than what the raw logs contain.

Advanced hunting spans SIEM, XDR, and the data lake

Hunting in the Defender portal covers Sentinel workspace tables, Defender tables, and the data lake in a single query surface, and it explicitly supports reuse of your existing Sentinel workspace queries and functions. The KQL library your analysts have built over years is not thrown away by the move. It comes with you, and it gains new tables to join against.

Security Copilot only exists in the Defender portal

Microsoft lists Security Copilot as not available for Sentinel in the Azure portal. In the Defender portal it provides incident summaries, guided response, script and file analysis, generated incident reports, and autonomous agents for triage and threat intelligence. If your organisation is evaluating AI-assisted security operations, the portal transition is the prerequisite, not an optional extra afterward.

A data lake model with tiered retention

The data model moves from a purely Log Analytics-centric design to a centralised data lake with tiered retention and a unified schema across Sentinel and Defender. Microsoft also notes that advanced hunting raw logs are available for thirty days without ingestion charges applying to that tier. For Indian organisations where ingestion cost is a standing argument at renewal time, the new model is worth remodelling properly during the transition.

Native multi-tenant operations replace Azure Lighthouse

Multi-tenant and service provider access moves from Azure Lighthouse delegation to native multi-tenant operations built into the Defender portal, with unified cross-tenant incidents and alerts. For Indian MSSPs, group companies with several tenants, and global capability centres operating security for a parent organisation, this is an architecture change that deserves its own planning track, not a footnote in the migration.

Unified RBAC is the change most likely to bite

Permissions move from Azure role-based access control to unified Defender RBAC, with row-level support. Access that currently works because of an Azure role assignment does not silently carry across, it has to be deliberately reproduced in the new model. In our experience this is the single most common source of a bad first day, an analyst who cannot open the incident they are being paged about.

What does not change

Your workspace, your data, and your billing model all stay put.

The transition is a portal and operating-model change, not a data migration. Understanding what stays the same is what makes the project boring, which is the goal.

Your Log Analytics workspace stays exactly where it is. Onboarding connects the workspace to the Defender portal; nothing is copied, moved, or re-ingested.
Your historical data, incident records, and retention settings are untouched. Analysts can query the same tables the day after cutover that they queried the day before.
Your analytics rules, automation rules, playbooks, watchlists, and workbooks carry across. Some behave differently in the new surface, which is why we validate each class before cutover rather than assuming.
The commercial model keeps the same shape: you pay for ingestion and retention on your existing plan. Moving portals does not by itself change what you are billed for, though the data lake tiers give you new levers worth reviewing.
One honest caveat: if you run Sentinel without any Defender XDR services, Microsoft documents three capabilities as limited or unavailable, Security Exposure Management, Defender-provided custom detection rules, and the Action center. Your Sentinel analytics rules still work; the gaps sit on the Defender side of the platform.

Ask what the destination looks like on your licensing

Why GR IT for the transition

Four things that decide whether this migration is boring.

A portal transition with a fixed end date, a changed permission model, and a new interface for the people who answer pages at three in the morning. Each of those is a known risk, and each is manageable when it is addressed rather than discovered.

Permissions rebuilt deliberately

We map every Azure RBAC assignment to its unified Defender RBAC equivalent before onboarding, including row-level access where the old model relied on resource scoping. Nobody discovers a missing permission during a live incident, because every role walked through its own access before cutover day.

Runbooks rewritten, analysts rehearsed

Logs became advanced hunting. Entity behavior became entity pages. Workspace manager is gone entirely. We rewrite the operational runbooks against the new navigation and run working sessions on real incidents from your own environment, so the unified queue is familiar before it is mandatory.

Parallel running, tested cutover

The Azure portal stays available until retirement, and we use that window. Your team works genuine incidents in the Defender portal while the familiar console is still there, playbooks are dry-run against test entities, and an end-to-end detection test proves the pipeline before anyone commits.

Remote-first from Gachibowli, Hyderabad

The entire transition is delivered remotely across India from our Hyderabad base, workshops, RBAC mapping, validation, and cutover included. Initial enquiries get a reply within 4 business hours, and managed clients operate on a 30 minutes response SLA after go-live.

Who needs this

Six Indian situations where the transition deserves planning now.

Every Sentinel customer faces the same date, so in one sense the answer to who needs this is everyone still in the Azure portal. What differs is how much work sits between where an organisation stands and a clean cutover.

Regulated financial services

Banks, NBFCs, and SEBI-regulated firms whose documented security operations procedures are audit evidence under RBI guidelines or SEBI CSCRF. The transition changes the console and permission model those procedures describe, so updating the documentation is part of the project, not an afterthought.

MSSPs and multi-tenant groups

Indian MSSPs and group companies operating Sentinel across several tenants through Azure Lighthouse. Native multi-tenant operations replace that delegation model, which is an architecture change deserving its own planning track before any tenant-by-tenant migration begins.

Global capability centres

GCCs in Hyderabad, Bengaluru, Pune, and NCR running security operations for a global parent, often across multiple workspaces and regions. Workspace-to-tenant mapping and the loss of workspace manager make these the estates where sequencing matters most.

Sentinel without Defender XDR

Fully supported, and Microsoft is explicit that Sentinel works in the Defender portal without Defender XDR or an E5 licence. Three capabilities are documented as limited in that configuration, and knowing which three before cutover prevents the conclusion that the migration went wrong.

Teams with deep KQL and workbook investment

Years of custom analytics rules, hunting queries, watchlists, and workbooks. All of it carries across, and unified advanced hunting explicitly reuses existing workspace queries and functions. The transition is also the right moment to version-control the library and retire what nobody opens.

Small teams with no project capacity

The hardest case, a lean IT team running Sentinel alongside everything else, with no slack for a migration project and a deadline that applies anyway. A staged, remotely delivered transition with a named owner, or a managed arrangement that carries operations through the move, solves it. Waiting for the automatic redirect does not.

Three positions

Where Indian organisations running Sentinel stand today.

The middle column, aware of the deadline but planning to deal with it later, is the most common position we see in India. It is also the position that converts a manageable project into a rushed one, because every organisation that deferred will be moving in the same final quarters, competing for the same skilled help.

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
Automatic Defender signal correlation	Yes	No	No
Attack story and blast radius investigation	Yes	No	No
Security Copilot available to the SOC	Yes	No	No
Receiving new Sentinel capabilities first	Yes	No	No
Permissions rebuilt in unified RBAC	Yes	Not started	Not started
Runbooks match the console analysts actually use	Yes	For now	For now
Transition happening on your schedule	Yes	Unlikely	No

Where things moved

Navigation changes your analysts will hit in the first hour.

Reproduced from Microsoft's published navigation mapping. Two entries are not moves at all, they are removals, and knowing that in advance saves an afternoon of searching and a false conclusion that the migration broke something.

	Azure portal	Defender portal
Logs	Investigation and response, then Hunting, then Advanced hunting
Incidents	Investigation and response, then Incidents and alerts
Workbooks, Hunting, Notebooks, MITRE ATT&CK	Microsoft Sentinel, then Threat management
Threat intelligence	Threat intelligence, then Intel management
Entity behavior	Entity pages under Assets, with Sentinel events on each user or device
Data connectors, Analytics, Watchlists, Automation	Microsoft Sentinel, then Configuration
Content hub, Repositories, Community	Microsoft Sentinel, then Content management
Settings	System, then Settings, then Microsoft Sentinel
Workspace manager	Not available
News and guides	Not available

How a transition runs

Five steps from assessment to a settled SOC in the new portal.

Typically 4-8 weeks depending on workspace count, automation depth, and how many people need to come through the interface change. The technical onboarding is genuinely not the long part. The permission mapping, validation, and human rehearsal are where the time goes, and where it is best spent.

1
Assess the estate and the destination
1 week
Workspaces, connectors, analytics rules, automation rules, playbooks, watchlists, workbooks, integrations, and Lighthouse delegations inventoried. Licensing reviewed so you know exactly what the Defender portal looks like for you, including Security Copilot entitlement and whether the three documented capability limits apply.
2
Map permissions and design the target
1-2 weeks
Every Azure RBAC assignment translated to unified Defender RBAC, row-level access designed where needed, workspace-to-tenant onboarding order fixed, and multi-tenant operations designed for MSSP and group scenarios. This step existing is why cutover day is uneventful.
3
Onboard and run in parallel
1-2 weeks
Workspaces onboarded to the Defender portal, where Sentinel integrates with Defender automatically, no XDR connector to configure. Analysts work real incidents in the unified queue while the Azure portal remains available, surfacing permission gaps in a controlled window instead of during a live incident.
4
Validate everything that automates
1-2 weeks
Playbook dry-runs against test entities, automation rule triggers verified, Logic Apps managed identity and API connection permissions re-proven, custom connectors and ITSM integrations tested, and an end-to-end detection test from ingestion to automated response. Runbooks rewritten and rehearsed with the night shift.
5
Cut over and adopt what Azure never had
1 week plus adoption
Operations formally move to the Defender portal. Then the team adopts the capabilities that made the move worth doing, Security Copilot summaries and guided response, the AI-assisted playbook generator, case management, and SOC optimisation recommendations. Optionally, we stay on as your managed SOC with a 30 minutes response SLA.

Common breakages

The five things that actually break in Sentinel portal transitions.

The platform onboarding itself rarely fails. What fails is the surrounding plumbing that was built against the old portal and the old permission model. We test each of these explicitly before cutover.

Logic Apps playbook permissions. Playbooks run under managed identities and API connections that were authorised in the Azure RBAC world. After the RBAC translation, a playbook that triggers but cannot act, or cannot be triggered by an automation rule at all, is the most frequent silent failure.
Custom connectors and API integrations. Anything you built against Sentinel management APIs, ticketing sync into ITSM tools, custom ingestion via Logic Apps, CI/CD pipelines deploying analytics rules from a repository, needs revalidation against the unified surface.
Workbooks that render differently. Workbooks survive the move but live in a new location, and a minority that depend on Azure portal context behave differently. We inventory which workbooks are actually opened, migrate those deliberately, and retire the rest.
Runbooks written against dead navigation. An analyst following a documented procedure that says open Logs will not find it under that name. Procedures shown to auditors under CERT-In directions or SEBI CSCRF must be updated in the same project, because a procedure that no longer matches reality is a finding.
Multi-workspace assumptions. Workspace manager has no equivalent in the Defender portal, so organisations centrally managing many workspaces need a replacement practice designed, not discovered.

Straight answers

What Indian organisations ask about the Sentinel transition.

Pre-migration readiness

The readiness checklist we work through before anything is onboarded.

Three groups. Scope establishes what you are actually moving. Translation covers the parts that do not carry across automatically. Validation is what gets tested in parallel running before anyone commits to the new portal for live operations.

Scope

Workspace-to-tenant mapping
Which Log Analytics workspaces onboard to which Entra tenant, and in what order. Multi-workspace estates need this drawn before day one.
Defender XDR licensing position
Sentinel works in the Defender portal without XDR or E5, with three documented capability limits. Know which side you are on.
Multi-tenant and MSSP access inventory
Every Azure Lighthouse delegation that must be reproduced as native multi-tenant operations.
Security Copilot entitlement check
Establish what your subscription already includes before anyone proposes a purchase.
Integration inventory
ITSM sync, SOAR integrations, repository pipelines, custom API consumers.

Translation

RBAC mapping, Azure roles to unified Defender RBAC
Every role assignment listed, its equivalent designed, row-level access configured where the old model depended on resource scoping.
Automation rules and playbooks validation plan
Trigger conditions, managed identity permissions, and API connections each re-verified in the new surface.
Custom analytics rules review
Custom KQL rules carry across, but this is the moment to catalogue, version-control, and prune them.
Watchlists confirmed and owners named
Watchlists move with the workspace; the people who maintain them need to know the new path.
Workbook triage
Which are opened weekly, which are audit evidence, which are dead. Only the first two migrate deliberately.

Validation before cutover

Analyst access walk-through per role
Every SOC role opens an incident, runs a hunt, and triggers a playbook in the new portal before cutover day.
End-to-end detection test
A benign simulated signal traced from ingestion through analytics rule, incident creation, correlation, and automated response.
Playbook dry-runs on real incident shapes
Isolation, account disable, mailbox sweep, and notification playbooks each fired in anger against test entities.
Runbook rewrite and walk-through
Procedures updated for the new navigation and rehearsed with the people who work nights.
Rollback and parallel-running window agreed
The Azure portal remains available until retirement; use that window deliberately rather than by accident.

The pages around this one.

Microsoft Sentinel

The platform page: data connectors, KQL detection engineering, SOAR automation, and managed SOC operations on Sentinel itself.

Learn more

Microsoft Security Services India

The full Microsoft security stack for Indian organisations, Defender, Entra, Purview, and Sentinel, deployed and operated as one programme.

Learn more

Microsoft 365 Security Audit

A fixed-scope audit of your Microsoft 365 tenant, a natural companion to the transition if your last configuration review predates the unified portal.

Learn more

Next step

Put 31 March 2027 in the plan while it is still a project, not a deadline.

Every organisation running Sentinel in the Azure portal faces the same date, and skilled help will concentrate toward the end of it. Start now and you transition in parallel, on your own schedule, with your detections, automations, and history intact. Tell us your workspace count and licensing, and we will reply within 4 business hours with what the Defender portal looks like for you.

Book a transition review Explore Microsoft Sentinel

Related Services

Explore more solutions that work great with this service

Microsoft is retiring Sentinel in the Azure portal. We move you to the Defender portal without losing a single detection.

Eight differences between the two portals, and what each means for your SOC.

The retirement date removes the debate

One incident queue instead of two

Attack story replaces log-centric investigation

Advanced hunting spans SIEM, XDR, and the data lake

Security Copilot only exists in the Defender portal

A data lake model with tiered retention

Native multi-tenant operations replace Azure Lighthouse

Unified RBAC is the change most likely to bite

Your workspace, your data, and your billing model all stay put.

Four things that decide whether this migration is boring.

Permissions rebuilt deliberately

Runbooks rewritten, analysts rehearsed

Parallel running, tested cutover

Remote-first from Gachibowli, Hyderabad

Six Indian situations where the transition deserves planning now.

Regulated financial services

MSSPs and multi-tenant groups

Global capability centres

Sentinel without Defender XDR

Teams with deep KQL and workbook investment

Small teams with no project capacity

Where Indian organisations running Sentinel stand today.

Navigation changes your analysts will hit in the first hour.

Five steps from assessment to a settled SOC in the new portal.

Assess the estate and the destination

Map permissions and design the target

Onboard and run in parallel

Validate everything that automates

Cut over and adopt what Azure never had

The five things that actually break in Sentinel portal transitions.

What Indian organisations ask about the Sentinel transition.

Is this transition actually forced, and by when?

Do we lose any data, incidents, or history in the move?

Do our analysts need retraining?

What happens to our playbooks and automation rules?

We run multiple workspaces and multiple tenants. How is that handled?

Does our billing change?

We are an MSSP. What happens to our client access?

What is limited if we use Sentinel without Defender XDR?

What genuinely improves after the move?

Can we run both portals during the transition?

How long does a transition take, and is it disruptive?

Can you run our SOC after the transition?

Everything is delivered remotely?

The readiness checklist we work through before anything is onboarded.

Scope

Translation

Validation before cutover

The pages around this one.

Microsoft Sentinel

Microsoft Security Services India

Microsoft 365 Security Audit

Put 31 March 2027 in the plan while it is still a project, not a deadline.

Related Services

Microsoft Sentinel

Microsoft Security Services

Defender for Endpoint

Microsoft 365 Security Audit