If you've worked with Microsoft Sentinel over the past few days, you've probably seen the banners. The Sentinel Defender portal has left preview and became the default for onboarding as of July 2025. The Azure portal experience will be retired after July 1, 2026. In many of the tenants I work in, SOC teams are still firmly anchored in the Azure portal and keep pushing the switch back. After Microsoft's announcement, that's no longer an option if you want your Sentinel setup to stay current and supported.

The Defender portal changes how your SOC works, not just the UI

This is not a cosmetic refresh. The Sentinel Defender portal changes how your Security Operations Center (SOC) handles detection, response and automation. For all tenants created after July 2025, or when you explicitly opt in, new workspaces are onboarded directly in the Defender portal (→ Settings → Microsoft Sentinel). The "primary workspace" now plays a central role, because only workspaces that are connected and designated as primary can be managed from the Defender portal. You set this connection under Settings → Microsoft Sentinel, and I'd do it soon for every production workspace. I wrote about the preview phase earlier in Sentinel in the Defender portal: Unified security in preview.

Navigation is only part of it. Analytics rules and incident handling also work quite differently now. Detection rules, automations and incident management sit in one interface and follow one RBAC model, which Sentinel shares with Defender XDR and Purview. That can make user management simpler, but it takes some rethinking, particularly if your SOC has depended on Azure-specific roles. If you use custom detection rules, have a look at my post on that topic: Custom detection rules from hunting queries in Defender XDR.

Analytics rules and incidents now share one interface with automation

With the move to the Defender portal, processes that used to live in separate places come together. Analytics rules appear in their own tabs, and you can filter incidents by product or workspace. Automation rules, Logic Apps and playbooks are all still available, but you manage and monitor them in the Defender portal now. Permissions are affected too. Classic Azure roles (like Contributor, Reader) only matter for people who still work in the Azure portal, and that group will shrink over time.

In practice, I'd use the migration to review and clean up your RBAC assignments. Moving automations and hunting workflows usually goes without trouble, as long as every related resource (workbooks, playbooks, data sources) is tied to your primary workspace. Even so, test your core SOC processes in the Defender portal before Azure portal support ends for good.

Practical tip: Before you switch, create a dedicated test account in the Defender portal and run through all of your automation, hunting and incident-handling steps. You'll catch missing permissions or UI inconsistencies early, and you can train your team on real scenarios.

Workbooks and hunting queries move under Hunt in the Defender portal

Workbooks and hunting queries are still the core of the SOC toolbox, and in the Defender portal you find them under "Hunt". Things feel much more consistent here. Hunting queries are easier to share, and Defender and Sentinel now run on the same KQL workflow engine. For more advanced scenarios, such as custom workbooks built from templates, the resources have to be mapped to the primary workspace. Managing data sources through Data Connectors has also become clearer and easier to work with.

The following diagram shows how these pieces connect:

flowchart TD
    user["SOC analyst"] --> defenderportal["Defender portal"]
    defenderportal --> sentinelsettings["Settings: Microsoft Sentinel"]
    defenderportal --> detectionrules["Analytics rules"]
    defenderportal --> incidents["Incidents"]
    defenderportal --> automation["Automation rules"]
    defenderportal --> hunting["Hunting & Workbooks"]
    sentinelsettings --> workspace["Primary workspace"]
    workspace --> datasources["Data sources"]

Figure: Key flows in the new Sentinel Defender portal, with the primary workspace at the center.

As the diagram shows, many Sentinel features won't show up in the Defender portal at all until you assign a primary workspace.

Your SOC team needs training and change management for the switch

Flipping a setting won't cover this migration. Most SOC analysts and incident responders need time to adjust to the new layout, navigation and workflows. From what I've seen, workshops, hands-on walkthroughs and a short quick-reference guide for the team are essential. You should also look again at how teams collaborate on custom workbooks or playbooks, since permissions are now assigned across products and not only within Sentinel.

These are the planning steps I recommend:

  • Assign a primary workspace and test connectivity in the Defender portal
  • Check all automation and detection rules for compatibility with the portal
  • Hold focused training sessions for your SOC team in the Defender portal
  • Bring workbooks, playbooks and data connectors together under the primary workspace
  • Configure monitoring and permissions with the new RBAC model

Microsoft's documentation has more detail on the migration and its current limitations: Move to Defender portal, Sentinel-onboard in Defender portal, Sentinel in Defender portal.

I recommend starting the migration now rather than waiting

The sooner you begin moving to the Sentinel Defender portal, the fewer disruptions you'll have in 2026. The technical part rarely causes problems. RBAC, access and training are what decide whether the transition goes well. If you test now and let your SOC get used to the interface, you won't be caught out at the last minute. I honestly think the unified security portal is a real improvement, even if saying goodbye to the Azure portal will take the SOC some getting used to.