A practical readiness article for security operations, detection engineering, automation, governance, and AI-first SOC modernization.
Executive summary
Microsoft Sentinel’s transition from the Azure portal to the unified security operations experience in Microsoft Defender is more than a portal move. It is a shift toward a single operating model for SIEM, XDR, threat intelligence, AI-assisted investigation, automation, and cross-domain correlation. The immediate goal for SOC leaders is to preserve continuity while redesigning workflows around unified incidents, Defender correlation, custom detections, incident-driven response, modern governance, and AI-first operations.
Use this checklist as a transition article and working plan. It is organized by operational workstream so each owner can assess what changes, what carries forward, and what must be validated before Azure portal dependency becomes a risk.
1. Establish the transition strategy
The transition should be treated as an operating-model modernization program, not a single technical cutover. Microsoft’s guidance positions Defender as the convergence point for Microsoft Sentinel, Microsoft Defender XDR, threat intelligence, generative AI, and automation, with the Azure portal experience no longer supported after March 31, 2027.
• Confirm executive sponsorship and define the transition as a SOC modernization initiative.
• Name accountable owners for incident operations, detection engineering, SOAR, identity and access, data architecture, MSSP or multi-tenant operations, APIs, reporting, training, and change management.
• Document the current Azure portal dependency map: daily analyst workflows, KQL queries, analytics rules, automation rules, playbooks, workbooks, watchlists, notebooks, API integrations, ITSM connections, and reporting processes.
• Define success measures: reduced context switching, fewer duplicate investigations, faster triage, validated automation behavior, role clarity, cost predictability, and analyst adoption.
• Run a pilot with one workspace, one analyst group, one high-value detection set, and one automation pathway before broad rollout.
2. Reframe incidents, alerts, correlation, and data
In the unified Defender experience, incidents become the center of operations. Analysts move away from alert-centric triage and toward a connected attack story that groups related activity, evidence, assets, and timelines. Defender’s correlation engine replaces the legacy Fusion-centered mental model and correlates across Defender and Sentinel signals where supported.
• Review the unified incident queue and compare it with the current Azure portal incident queue for duplicate, merged, and renamed incident patterns.
• Validate how alerts from Microsoft Sentinel workspaces correlate with Microsoft Defender signals, especially where multiple Sentinel workspaces are onboarded.
• Identify playbooks, reports, and ITSM integrations that assume a one-alert-to-one-incident relationship.
• Update triage procedures so analysts investigate the incident attack story, related evidence, assets, and timeline before closing or escalating.
• Test manual incident merging and alert reassignment procedures in Defender and document any workflow differences.
• Verify that underlying Log Analytics workspaces, tables, connectors, and KQL access remain intact for investigation and hunting.
• Review any automation or reporting that reads incident descriptions, alert fields, provider names, product names, or schema-specific values.
3. Rework detection engineering
Detection engineering remains grounded in KQL and security data, but the operating model changes. Detection teams should compare existing Microsoft Sentinel analytics rules with Defender custom detections, advanced hunting capabilities, and cross-product signal availability. The objective is not to blindly port every rule; it is to decide which detections should remain as Sentinel analytics, which should become Defender custom detections, and which should be retired because Defender correlation or native detections now cover the scenario.
• Export and inventory analytics rules by severity, MITRE ATT&CK tactic and technique, data source, schedule, entity mapping, incident creation behavior, and automation dependencies.
• Classify each rule as keep, convert, tune, consolidate, or retire.
• Validate KQL compatibility in advanced hunting where rules query Defender XDR tables or cross-domain data.
• Review entity mappings and alert enrichment fields so incident evidence is useful in Defender’s investigation experience.
• Retest suppression, grouping, thresholds, and incident creation settings because incident behavior may differ from Azure portal assumptions.
• Map detections to the new incident-driven workflow so analysts understand why a detection exists and what response action it should trigger.
• Update detection engineering standards to include Defender portal validation, unified incident impact, and automation trigger behavior.
4. Move SOAR from alert-driven to incident-driven response
Automation must be validated carefully because unified incidents change how response logic should be triggered. In Azure portal-centric operations, many playbooks and automation rules are alert-oriented. In Defender, the stronger model is incident-driven SOAR: automation should evaluate the full investigation context, evidence, entities, severity, and related alerts before enrichment, containment, or ticket creation.
• Inventory automation rules, Logic Apps playbooks, connectors, managed identities, service principals, and API permissions.
• Identify playbooks that trigger on alerts and redesign them to operate on incidents where appropriate.
• Validate enrichment logic that depends on alert schema, incident title, incident description, provider fields, entity lists, or custom details.
• Confirm ticketing integration behavior for merged incidents so duplicate cases are not created.
• Define guardrails for automated containment, including approval steps for high-impact actions.
• Test automation across multiple incident scenarios: single alert, multi-alert, cross-domain correlation, merged incident, reopened incident, and manually created incident.
• Document fallbacks for automations that must remain in Azure RBAC or Logic Apps permission models during the transition.
5. Modernize governance, RBAC, URBAC, data lake, and MSSP operations
Governance is the transition dependency most likely to create friction. Existing Azure RBAC assignments can continue to function during transition, but Defender introduces Unified RBAC as the preferred model for unified security operations. The governance workstream should design least-privilege access for analysts, engineers, managers, automation identities, data lake users, and MSSP operators.
• Inventory all Azure RBAC assignments for Sentinel workspaces, resource groups, subscriptions, Logic Apps, automation accounts, and service principals.
• Map SOC personas to required capabilities: triage, hunting, rule management, content deployment, automation execution, data lake query, reporting, and tenant administration.
• Evaluate Unified RBAC readiness and decide when to import or recreate roles in Defender.
• Keep automation-specific permissions in the appropriate Azure role model where Unified RBAC does not cover the task.
• Design row-level, table-level, and data-scoped access for sensitive logs and multi-workspace scenarios.
• Review Microsoft Sentinel data lake retention, residency, access, and cost assumptions before expanding long-term storage.
• For MSSP or large enterprise operations, validate multi-tenant visibility, delegation, customer segmentation, and blast-radius boundaries.
• Document break-glass access, privileged role approval, access review cadence, and audit evidence requirements.
6. Build the readiness playbook
The readiness playbook should turn discovery into sequenced execution. Microsoft’s transition guidance emphasizes planning prerequisites, onboarding workspaces, reviewing settings and content, and then running operations in Defender. Treat the adoption helper or internal assessment as the baseline for a structured remediation backlog.
• Run a readiness assessment across workspaces, data retention, analytics rules, automation rules, workbooks, hunting queries, watchlists, connectors, APIs, and reporting.
• Prioritize findings by operational risk: analyst-blocking, automation-breaking, governance-critical, cost-impacting, and cosmetic.
• Confirm there is no additional cost simply for transitioning the Sentinel experience to Defender, while separately reviewing data ingestion, retention, data lake, automation, and Copilot-related licensing or consumption.
• Identify API consumers and decide whether they should continue using existing Sentinel APIs, move to Defender APIs, or support both during transition.
• Define a migration calendar with pilot, validation, staged rollout, hypercare, and Azure portal dependency retirement phases.
• Create a rollback and support plan for operational defects found during the pilot.
• Train analysts using real incidents, not screenshots, so muscle memory shifts to the unified queue and attack story.
• Track completion with a transition dashboard showing readiness score, open blockers, validated workflows, and remaining Azure portal dependencies.
7. Prepare for the AI-first SOC
The destination is an AI-first SOC operating model. In Defender, Security Copilot, UEBA, threat intelligence, advanced hunting, and SOC optimization recommendations become part of the same workflow. The transition team should identify where AI and behavioral analytics can reduce analyst toil without weakening governance or accountability.
• Enable or validate UEBA coverage for identity, endpoint, cloud, and hybrid signals where appropriate.
• Review entity pages and ensure analysts know where behavioral insights, evidence, and related activity appear in Defender.
• Pilot Security Copilot for incident summarization, KQL generation, script analysis, executive reporting, and investigation guidance.
• Define acceptable-use rules for AI-generated investigation notes, KQL, containment recommendations, and stakeholder summaries.
• Integrate threat intelligence into triage and hunting workflows so investigations move from raw indicators to actor, campaign, and exposure context.
• Review SOC optimization recommendations and convert them into an improvement backlog for data coverage, detections, automation, and posture.
• Measure AI-first outcomes: time to triage, time to contain, analyst handoffs, duplicate incidents reduced, false positive reduction, and report creation time.
Operational checklist by owner
| Owner | Checklist focus | Definition of done |
| SOC lead | Unified incident queue, triage workflow, escalation paths, training, and adoption metrics. | Analysts can operate daily incidents in Defender with documented procedures and measured adoption. |
| Detection engineering | Analytics rules, custom detections, advanced hunting, entity mapping, and rule rationalization. | High-priority detections are validated in Defender and mapped to incident response actions. |
| SOAR owner | Automation rules, playbooks, Logic Apps, ticketing, enrichment, containment, and approvals. | Critical automations work against unified incidents without duplicate tickets or unsafe actions. |
| Identity and governance | Azure RBAC, Unified RBAC, least privilege, access reviews, service principals, and break-glass roles. | Role model is documented, tested, and approved for analysts, engineers, automation, and partners. |
| Data architecture | Workspace strategy, data lake, retention, residency, KQL access, schema dependencies, and cost controls. | Data access and retention decisions support detection, hunting, compliance, and investigation needs. |
| MSSP or multi-tenant operations | Tenant delegation, cross-tenant visibility, customer separation, content distribution, and blast-radius control. | Operators can manage authorized tenants without overexposure or inconsistent customer workflows. |
| Platform and API owners | API consumers, reporting, dashboards, CI/CD, repositories, and integration contracts. | Integrations are tested against the future operating model and have documented ownership. |
30-day transition sprint
1. Days 1–5: Inventory workspaces, rules, automations, workbooks, API consumers, access assignments, and active Azure portal dependencies.
2. Days 6–10: Onboard or validate the pilot workspace in Defender and compare incident, alert, hunting, and automation behavior.
3. Days 11–15: Remediate high-risk detection and automation dependencies, especially alert-centric logic and schema assumptions.
4. Days 16–20: Validate RBAC, Unified RBAC planning, service principal permissions, data lake access, and MSSP or multi-tenant boundaries.
5. Days 21–25: Train analysts on unified incidents, attack story investigation, evidence review, advanced hunting, and escalation workflows.
6. Days 26–30: Run production-like exercises, publish updated runbooks, approve rollout waves, and track remaining blockers in a readiness dashboard.
Conclusion
The Sentinel transition to the Microsoft Defender unified security experience is an opportunity to simplify SOC operations and modernize how analysts investigate, detect, respond, govern, and optimize. The safest path is incremental: inventory first, pilot with real workflows, validate incident and automation behavior, modernize governance, and then scale adoption. Organizations that move early can reduce friction before the deadline and start gaining value from unified correlation, AI-assisted investigation, integrated threat intelligence, and SOC optimization sooner.