Forum Discussion
The Sentinel migration mental model question: what's actually retiring vs what isn't?
Something I keep seeing come up in conversations with other Sentinel operators lately, and I think it's worth surfacing here as a proper discussion.
There's a consistent gap in how the migration to the Defender portal is being understood, and I think it's causing some teams to either over-scope their effort or under-prepare. The gap is this: the Microsoft comms have consistently told us *what* is happening (Azure portal experience retires March 31, 2027), but the question that actually drives migration planning, what is architecturally changing versus what is just moving to a different screen, doesn't have a clean answer anywhere in the community right now.
The framing I've been working with, which I'd genuinely like to get other practitioners to poke holes in:
What's retiring: The Azure portal UI experience for Sentinel operations. Incident management, analytics rule configuration, hunting, automation management: all of that moves to the Defender portal.
What isn't changing: The Log Analytics workspace, all ingested data, your KQL rules, connectors, retention config, billing. None of that moves. The Defender XDR data lake is a separate Microsoft-managed layer, not a replacement for your workspace.
Where it gets genuinely complex: MSSP/multi-tenant setups, teams with meaningful SOAR investments, and anyone who's built tooling against the SecurityInsights API for incident management (which now needs to shift to Microsoft Graph for unified incidents).
The deadline extension from July 2026 to March 2027 tells its own story. Microsoft acknowledged that scale operators needed more time and capabilities. If you're in that camp, that extra runway is for proper planning, not deferral.
A few questions I'd genuinely love to hear about from people who've started the migration or are actively scoping it:
- For those who've done the onboarding already: what was the thing that caught you most off guard that isn't well-documented?
- For anyone running Sentinel across multiple tenants: how are you approaching the GDAP gap while Microsoft completes that capability? Are you using B2B authentication as the interim path, or Azure Lighthouse for cross-workspace querying?
I've been writing up a more detailed breakdown of this, covering the RBAC transition, automation review, and the MSSP-specific path, and the community discussion here is genuinely useful for making sure the practitioner perspective covers the right edge cases.
Happy to share more context on anything above if useful.
I went ahead and wrote up the full breakdown based on the framing above. If it's useful for anyone working through this: https://securingm365.com/defenderxdr/sentinel/sentineldefender-part1/
Covers the architectural distinction in more detail, the operational changes that actually affect day-to-day SOC workflows, and how to think about the planning horizon given the extended deadline. Written with the scale and multi-tenant crowd in mind rather than single-tenant simple environments.
Would genuinely welcome any pushback or edge cases people have hit that aren't in there.
6 Replies
Thanks for a great series! I will be following it closely, appreciated good sir.
As for edge cases - in some serious MSSP setups GDAP is not a solution, its a hassle - there are no isolation between you and the multiple environments and therefor its skipped (and should be, we have so many instances where 1 key unlocks to many doors). What seems to be missing in the pusselpieces aswell from all the current information regarding this migration from Microsoft is that MSSP (atleast those that understand sentinel) are separating the Security Operations (SOC) and the actuall management of Sentinel (Log analytics, building playbooks, automationrules, repo with config, connectors, content hub etc). They are rarely the same team.
So with that in mind, the management of Sentinel happens in Azure (you deploy resource in a RG and work on the sentinel layer for connectors and keeping that up to date - also jacking in github or devops to pusch analytic rules centrally (or "custom folders"-yaml - that was introduced 1-2 years back in devops integration).
My understanding, which was solidified by reading your blog, is that those parts stays the same - however, there are some troublesome points that might get answered in your future series - but the automation and correlation. Currently there is a drift where XDR comes in and updates incidents well after all automation in Sentinel has run. So XDR is working in a different timeframe (a lot slower) - which is not what we need and in some cases even a hard stop when looking for new solutions due to regulatory/sensitive matters. Sentinel automation was slow enough, but now we need parity rules for all automationrules that looks for "on incident updates" (on top of the "on incident creation") - becuse XDR comes in after all automation has run and changes status or updates a clustered incident, correlating some Analytic rule you have automation built to look for "on creation"... This is a current painpoint - maybe XDR will be a lot quicker on those actions once the full migration is completed, but it dosent look good in current state.
Something that im worried about as well, are all the playbooks that are running and doing custom actions (revoking sessions, populating watchlists, updating entra groups or firewall exclusions/blocks, enrichment in incidents (ip lookups, comments, VT) etc etc). Some MSSP would keep as IP (they will have a bigger problem), but most MSSP would build that up in the customers tenant, customer own it and the data (and have versioning through github/devops). Im worried that this will break, the people working with it needs two access now instead of 1 (XDR Rbac/Security Administrator AND Azure RBAC owner & Sentinel roles - Yes, you need owner to deploy Azure Policies for some connectors in tenant root, you need owner on subscription to modify the resource datalake (enable) and some other cost related items to subscription/deletion of items). How will this play out? We know almost nothing on this part from Microsoft, they have only posted about the Operational side (SOC) moving to XDR instead of Azure. But all management actually happens in Azure.
again, thanks for the blog, very good information!Thanks! I really appreciate the thoughtful reply and the kind words.
You’re spot on about the MSSP edge cases. GDAP can be a pain in real multi‑tenant setups where strict isolation is required; one broad access path that touches many customers is exactly what a lot of MSSPs try to avoid. I also agree with your separation of concerns: SOC operations (incidents, triage) and platform/management (Log Analytics, playbooks, connectors, CI/CD) are usually different teams with different access models, and that split matters a lot for how this migration plays out.
A few quick thoughts that line up with what you said and what I’ll dig into in the series:
- Management stays in Azure: for most MSSPs the platform work (deploying resources, maintaining analytics rules, CI/CD for content) will remain an Azure/ARM story. That’s where ownership, versioning, and deployment pipelines live, and Microsoft hasn’t signalled that part will move wholesale to Graph.
- Automation parity is essential: you’ll need automation that reacts to both on creation and on update events. Design playbooks to be idempotent and to handle out‑of‑order updates so XDR’s slower updates don’t break workflows.
- Delegation patterns matter: Lighthouse, least‑privilege service principals, JIT elevation, and separate principals for SOC vs platform tasks are the practical ways MSSPs keep isolation without losing manageability. GDAP helps in some scenarios but isn’t a silver bullet for strict isolation models.
- Inventory and CI/CD: map every playbook, connector, automation rule, and required RBAC. Use central CI/CD to push tenant‑scoped changes (GitHub/DevOps) but authenticate into each tenant with delegated, least‑privilege credentials or Lighthouse patterns.
Totally agree that the dual‑access problem (needing both XDR/Security Admin and Azure RBAC/Sentinel roles) is going to be an operational headache for many teams. That’s why clear role separation, dedicated principals, and careful CI/CD design are going to be the practical workarounds.
I’ll look to cover Lighthouse vs GDAP tradeoffs, CI/CD patterns for multi‑tenant Sentinel management, and concrete automation patterns (including on‑update handling and Graph bridging) in upcoming posts.
I went ahead and wrote up the full breakdown based on the framing above. If it's useful for anyone working through this: https://securingm365.com/defenderxdr/sentinel/sentineldefender-part1/
Covers the architectural distinction in more detail, the operational changes that actually affect day-to-day SOC workflows, and how to think about the planning horizon given the extended deadline. Written with the scale and multi-tenant crowd in mind rather than single-tenant simple environments.
Would genuinely welcome any pushback or edge cases people have hit that aren't in there.
And it's smart and runs like a clock 4 personalities for different jobs still work as one system is great
I definitely am looking forward to the future of the unified portal, but it's the process of getting into the portal for each unique business case that I want to try and cover off, so that companies are then able to get those personas to work! 😀
Wouldn't it be nice just to say one thing and not have to download something to be able to speak to it 🤔 but Alexis,Siri, and bing =🧞♀️ yes it works and you can change all their voices and all still works (as one).IBB
