What this achieves: A unified SOC platform with a single incident queue, automatic multi-stage attack correlation, cross-platform Advanced Hunting, unified entity pages, and no additional cost.
Get sign-off on all of the following before touching anything technical:
Decision Item
Options
Recommended
Sign-Off Required From
Proceed with migration
Yes / No / Phased
Yes — full migration
Executive Sponsor
Migration window
Business hours / After-hours / Maintenance window
After-hours maintenance window
Change Advisory Board
Data privacy policy change
Accept Defender XDR policies / Defer
Accept — documented risk acceptance
DPO / Legal / CISO
CMK encryption scope reduction
Accept / Defer migration
Document as accepted risk
CISO / Data Owner
Primary workspace designation
One per tenant
Designate and document
Security Architect
Workspace Manager replacement
CI/CD Pipelines / Multitenant Portal
CI/CD (GitHub/Azure DevOps)
Security Architect
API migration strategy
Migrate all / Migrate incrementally
Incremental by integration priority
Security Architect + Dev Lead
IdentityInfo table-level RBAC removal
Accept loss / Design compensating control
Design compensating control first
Security Architect + IAM Lead
⚠️ CMK Notice: CMK-encrypted alerts and incidents will permanently lose CMK encryption after onboarding. Obtain written acceptance from your CISO or Data Owner before proceeding.
Phase Overview
#
Phase
Primary Audience
Estimated Duration
1
Read Official Guidance
Security Architects
1–2 Days
2
Pre-Requisites
Security Architects / Engineers
3–5 Days
3
Plan Component Migration
Security Architects
1–2 Weeks
4
Design
Security Architects / Engineers
1–2 Weeks
5
Implementation
Security Engineers
3–7 Days
6
Testing
Security Engineers / SOC Analysts
3–5 Days
7
Validation
All Roles
2–3 Days
8
Sign-Off & Completion
All Roles
Ongoing
Total estimated timeline: 4–6 weeks
Phase 1 — Read the Official Docs
Read and understand all five articles before planning anything:
Article
Purpose
Key Takeaway
Plan for unified security operations in the Defender portal
Architecture overview and role assignments
Microsoft Sentinel Contributor role auto-assigned to MTP and WDATP apps upon onboarding
Deploy for unified security operations
Step-by-step reference for new and existing customers
Use as deployment reference even for existing Sentinel customers
Connect Sentinel to the Defender portal
Onboarding prerequisites and procedure
Non-E5 customers need an extra manual step to trigger the connection
Data security and retention — Defender XDR
Defender XDR data governance policies
These policies replace Sentinel policies once the Defender portal is used
Alert schema differences: Standalone vs XDR connector
Schema changes when switching connectors
Critical for updating KQL queries, analytics rules, and workbooks
Phase 2 — Pre-Requisites (3–5 Days)
Identity & Permissions
Prerequisite
What to Check
How to Verify
Who
Subscription Owner or User Access Administrator
Onboarding user must hold one of these roles
Azure portal > Subscriptions > IAM > Check role assignments
Security Architect
Microsoft Sentinel workspace is active
Workspace must be in a healthy, active state
Azure portal > Microsoft Sentinel > Check workspace status
Security Engineer
All Sentinel users have Azure AD accounts
Users needing Defender portal access must have valid Azure AD accounts
Azure AD > Users > Verify accounts for SOC team
IAM Lead
Microsoft Threat Protection app exists in tenant
Auto-assigned Sentinel Contributor role on onboarding
Azure AD > Enterprise Applications > Search Microsoft Threat Protection
Security Engineer
WindowsDefenderATP app exists in tenant
Auto-assigned Sentinel Contributor role on onboarding
Azure AD > Enterprise Applications > Search WindowsDefenderATP
Security Engineer
Configuration Backup (Take Before Any Onboarding Step)
⚠️ This is your only reliable rollback point. Do not skip.
Component
Export Method
Storage Location
Analytics Rules
Sentinel API: GET /analyticsRules or export via Azure portal
Keep available in Azure portal; document in SOC runbooks
Latency-sensitive playbooks (under 5-min SLA)
Design retry logic in Logic App; update SLA documentation
ServiceNow incident sync (description field)
Build description string from title + severity + alert product names via Logic App Compose step
API Integration Migration Priority
Integration Type
Current API
Target API
Priority
Incident CRUD operations
SecurityInsights API
Graph API /security/incidents
High
Alert operations
SecurityInsights API
Graph API /security/alerts_v2
High
ServiceNow incident URL field
incidentUrl (Sentinel portal)
providerIncidentUrl for Defender portal deep link
High
Advanced Hunting queries
SecurityInsights API
Graph API /security/runHuntingQuery
Medium
Analytics rule management
SecurityInsights API
Keep SecurityInsights API — fully supported
Low / No change
Phase 5 — Implementation (3–7 Days)
⚠️ Schedule onboarding during an after-hours, low-activity maintenance window. Have a secondary analyst monitoring the Azure portal for 30 minutes post-onboarding. Steps must be completed in order — Steps 1 and 2 must happen before workspace onboarding.
Step
Action
Where
1
Configure Defender for Cloud connector deduplication
Azure portal > Sentinel > Data Connectors > Tenant-based Defender for Cloud
2
Opt legacy Defender for Cloud connector out of incident/alert sync
Azure portal > Sentinel > Data Connectors > Legacy connector
3
Enable Microsoft Defender XDR connector (incidents + alerts + all Defender product sources)
Azure portal > Sentinel > Data Connectors > Microsoft Defender XDR
4
Confirm connector shows Connected; test KQL against SecurityAlert table
Azure portal > Sentinel > Logs
5
Update all playbooks — replace Description field references with Compose step
Leave a Reply