MicrosoftMicrosoftNice article, but let’s be candid: the “unified portal” currently feels more like a frontend consolidation than true backend integration.
This is especially visible in Advanced Hunting, which remains unreliable after the Sentinel + Defender XDR integration. The underlying Log Analytics backends are still separate, so the exact same query may run against Advanced Hunting Log Analytics or Sentinel Log Analytics depending on the selected time range. That creates inconsistent behavior and results.
There are also schema mismatches between the two environments. For example, the AdditionalFields column in the DeviceInfo table is a string in XDR, but dynamic in Sentinel. Issues like this create constant friction for daily investigations, threat hunting, and detection engineering.
From a customer perspective, this is directly affecting operational efficiency. Unfortunately, despite multiple support cases and escalations, product team is not interested in providing improvements in those matters.
It is also worth noting that Sentinel Data Lake is still unavailable in many Azure regions, including major ones such as West Europe.
Not only the Operational aspect of it. But also the managed aspect of it. For MSP that managed cutomers sentinel (in the customers tenant as the data lives there, gdpr etc) always had to have Azure RBAC permissions to deploy, modify, view and adjust resources in azure created by sentinel. Other resources aswell such as azure policies for activity logs or deploying AMA agents and DCR rules etc. So all these news about the great shift is very missleading for such envoirments. Sure, the security operation teams will work in XDR portal (but 98% of all SOC providers have their own tools ingesting the alerts from both XDR and Sentinel already, they dont work in XDR portal) but for the managing part you now have to doublecheck features and settings in both portals, having additional XDR roles assigned to you on top of the Azure RBAC roles. The cost will always remain under the subscription.
And, most MSP deploy sentinel analytic rules, workbooks, automationrules etc through Github and Devops - these integrations (specially devops) have not gotten any updates in years, so the powershellcode that is created for such integration cant even support the "new" /customfolder/ that was introduced a few years back for such repository syncs. We had to rebuild it completly ourselfs. So, they are hinting that these existing integrations WILL handle "custom detections" aswell, meenwhile, in this article it mentioned something completly diffrent, that analytic rules etc will be managed in XDR instead which is also then missleading. I belive we will have to re-authenticate ALL existing github/devops integrations and revisit ALL these powershell/action scripts to get it working with custom detections to, or we might not be able to deploy custom detections at all (alltho, they did say its comming to sentinel -> content hub).
So, for each of these posts about migrating to sentinel to XDR it only gets more confusing. First news was "unified portal for SOC" (so we enabled it for ALL our customers immediately ) but it has now turned in to a operational mess (XDR correlation breaks all sentinel automations that have been build over the yeras). XDR correlation comes in 1-2 min after all automation and reopens incidents or take actions, even if you have a sentinel automationrule reacting on "when status change to new" on "incident update" - it will NOT run as XDR action happens 1 min after automation ran (it dosent run every single second, so the XDR action was to close to the previous automationrun, breaking all automations when XDR correlation is involved). So the whole SOAR functionally is being GUTTET before our eyes, all the work we built so far. In favor for what? maybe "agentic soc" in the future? (which real SOC providers have in their own platforms to be able to provide the service to all customers, not only microsoft customers).
MicrosoftYou're right that Advanced Hunting currently surfaces behavioral differences depending on time range and which backend resolves the query. The schema inconsistencies (like AdditionalFields being string in XDR vs. dynamic in Sentinel tables) add friction for detection engineers who work across both. These are real gaps, and I understand the frustration — especially when support escalations don't move the needle. Will raise this up.
On the "frontend vs. backend" point — the article's thesis is specifically about what's coming through the unified platform that doesn't exist in standalone Sentinel at all: the 2-tier Data Lake architecture, Sentinel Graph for relationship-based investigation, and MCP-based AI agents. These are new backend capabilities, not UI consolidation. The correlation engine that links incidents across Defender XDR + Sentinel and others is also a backend integration that standalone Sentinel can't replicate.
Sentinel Data Lake is available in West EU with some capacity issues but it has been rolled out incrementally.
The opportunity for partners is in helping customers navigate exactly the kind of complexity you're describing.
