Sentinel to Defender Portal Migration - my 5 Gotchas to help you

The migration to the unified Defender portal is one of those transitions where the documentation covers "what's new" but glosses over what breaks on cutover day. Here are the gotchas that consistently catch teams off-guard, along with practical fixes.

Gotcha 1: Automatic Connector Enablement

When a Sentinel workspace connects to the Defender portal, Microsoft auto-enables certain connectors - often without clear notification. The most common surprises:

Connector	Auto-Enables?	Impact
Defender for Endpoint	Yes	EDR telemetry starts flowing, new alerts created
Defender for Cloud	Yes	Additional incidents, potential ingestion cost increase
Defender for Cloud Apps	Conditional	Depends on existing tenant config
Azure AD Identity Protection	No	Stays in Sentinel workspace only

Immediate action: Within 2 hours of connecting, navigate to Security.microsoft.com > Connectors & integrations > Data connectors and audit what auto-enabled. Compare against your pre-migration connector list and disable anything unplanned.

Why this matters: Auto-enabled connectors can duplicate data sources - ingesting the same telemetry through both Sentinel and Defender connectors inflates Log Analytics costs by 20-40%.

Gotcha 2: Incident Duplication

The most disruptive surprise. The same incident appears twice: once from a Sentinel analytics rule, once from the Defender portal's auto-created incident creation rule. SOC teams get paged twice, deduplication breaks, and MTTR metrics go sideways.

Diagnosis:

SecurityIncident
| where TimeGenerated > ago(7d)
| summarize IncidentCount = count() by Title
| where IncidentCount > 1
| order by IncidentCount desc

If you see unexpected duplicates, the cause is almost certainly the auto-enabled Microsoft incident creation rule conflicting with your existing analytics rules.

Fix: Disable the auto-created incident creation rule in Sentinel Automation rules, and rely on your existing analytics rule > incident mapping instead. This ensures incidents are created only through Sentinel's pipeline.

Gotcha 3: Analytics Rule Title Dependencies

The Defender portal matches incidents to analytics rules by title, not by rule ID. This creates subtle problems:

Renaming a rule breaks the incident linkage
Copying a rule with a similar title causes cross-linkage
Two workspaces with identically named rules generate separate incidents for the same alert

Prevention checklist:

Audit all analytics rule titles for uniqueness before migration
Document the title-to-GUID mapping as a reference
Avoid renaming rules en masse during migration
Use a naming convention like <Severity>_<Tactic>_<Technique> to prevent collisions

Gotcha 4: RBAC Gaps

Sentinel workspace RBAC roles don't directly translate to Defender portal permissions:

Sentinel Role	Defender Portal Equivalent	Gap
Microsoft Sentinel Responder	Security Operator	Minor - name change
Microsoft Sentinel Contributor	Security Operator + Security settings (manage)	Significant - split across roles
Sentinel Automation Contributor	Automation Contributor (new)	New role required

Migration approach: Create new unified RBAC roles in the Defender portal that mirror your existing Sentinel permissions. Test with a pilot group before org-wide rollout. Keep workspace RBAC roles for 30 days as a fallback.

Gotcha 5: Automation Rules Don't Auto-Migrate

Sentinel automation rules and playbooks don't carry over to the Defender portal automatically. The syntax has changed, and not all Sentinel automation actions are available in Defender.

Recommended approach:

Export existing Sentinel automation rules (screenshot condition logic and actions)
Recreate them in the Defender portal
Run both in parallel for one week to validate behavior
Retire Sentinel automation rules only after confirming Defender equivalents work correctly

Practical Migration Timeline

Phase 1 - Pre-migration (1-2 weeks before):

Audit connectors, analytics rules, RBAC roles, and automation rules
Document everything - titles, GUIDs, permissions, automation logic
Test in a pilot environment first

Phase 2 - Cutover day:

Connect workspace to Defender portal
Within 2 hours: audit auto-enabled connectors
Within 4 hours: check for duplicate incidents
Within 24 hours: validate RBAC and automation rules

Phase 3 - Post-migration (1-2 weeks after):

Monitor incident volume for duplication spikes
Validate automation rules fire correctly
Collect SOC team feedback on workflow impact
After 1 week of stability: retire legacy automation rules

Phase 4 - Cleanup (2-4 weeks after):

Remove duplicate automation rules
Archive workspace-specific RBAC roles once unified RBAC is stable
Update SOC runbooks and documentation

The bottom line: treat this as a parallel-run migration, not a lift-and-shift. Budget 2 weeks for parallel operations. Teams that rushed this transition consistently reported longer MTTR during the first month post-migration.

microsoft 365 defender

microsoft sentinel

security

Forum Discussion