Your readiness playbook: adoption helper, costs, APIs, and the checklist

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

The transition is not a project—it is a sequence of small, ordered decisions. Here is the readiness tool that scores your environment in minutes, the cost story you can take to finance, the API strategy that future-proofs your integrations, and the FAQ list that answers the questions your team is already asking.

Most transition anxiety comes from not knowing what you do not know. The Defender transition is mature enough that Microsoft has packaged the readiness work into a script, the cost work into an estimator, and the API work into a clear migration story—and the most common questions are already answered.

This part is the practical playbook. It does not introduce new architecture; it gives you the levers you can pull right now to know exactly where you stand, what it will cost, what to integrate with, and how to brief the people asking questions.

What this post covers

• Defender adoption helper: a free readiness assessment with a visual dashboard
• Cost story: identical Sentinel pricing, optional new capabilities, and the new estimator
• The API strategy: SecurityInsights for workspace, Defender APIs for SOC, Graph security for the long run
• FAQ list: the five questions every stakeholder asks, answered
• Persona implications, common misconceptions, and a do-this-week checklist

Defender adoption helper

Overview

The Sentinel-Defender-helper-script is a PowerShell-based assessment tool designed to evaluate the readiness of Microsoft Sentinel workspaces before onboarding them into Microsoft Defender. It automates the discovery of potential compatibility issues, configuration gaps, and behavioral changes that organizations should address prior to the transition. The tool generates a structured CSV output that feeds an interactive HTML dashboard, providing security teams with a clear, visual summary of findings and actionable recommendations.

Important: This script is not an official Microsoft product or supported solution. No Microsoft Customer Services & Support (CSS) ticket can be raised for issues related to this tool, and bug fixing is not guaranteed beyond the author's willingness to maintain it. No rights can be derived from this solution—incorrect or missing information generated by this script may lead to customer production disruption. Test it before using it in production environment.

How it works

The tool operates in three phases:

Authentication

The operator authenticates against Microsoft Entra ID using one of two supported modes. In User mode, the script initiates an interactive device code flow through the browser, leveraging the well-known Azure PowerShell first-party client ID — no app registration is required. In app mode, a pre-configured service principal with a client secret is used for unattended execution. In both cases, the account must hold the Microsoft Sentinel Reader role on each target workspace.

Analysis

For each workspace defined in the sentinelEnvironments.json configuration file, the script calls the Azure Resource Manager REST APIs to inspect five areas:

• Defender data – Queries the retention settings of 21 Defender tables (e.g., DeviceInfo, EmailEvents, IdentityLogonEvents). Tables with default 30-day retention do not need separate ingestion into Sentinel, whereas tables with extended retention (e.g., 730 days) must continue to be stored in the log analytics workspace.
• Analytics rules – Examines every analytics rule for conditions that may cause issues after onboarding: Fusion engine enablement (Fusion is automatically disabled post-transition), rules that do not generate incidents (alerts become invisible in Defender), incident reopening settings (not supported in Defender—new incidents are created instead), custom alert grouping (overridden by the Defender XDR correlation engine), and Microsoft incident creation rules (deactivated after onboarding). Disabled rules are flagged as informational only.
• Automation rules – Inspects automation rule triggers and conditions for deprecated or incompatible patterns: use of incident title instead of analytics rule name, use of incident provider instead of alert product name, dependencies on Fusion-generated incidents, reliance on the description field (removed from SecurityIncident after onboarding), the Updated By = Microsoft 365 Defender value (which becomes Other), and alert-based triggers (which will only fire for Sentinel-originated alerts post-transition).
• Data lake region – Verifies whether the workspace region supports the data lake (Auxiliary tier) capability, checking against the list of currently supported Azure regions.
• Table tiers – Enumerates all tables in the workspace and flags those using the basic tier, which must be converted to analytics or auxiliary before onboarding. Tables already on the auxiliary tier are noted as future data lake tables.

Output

All findings are collected into a flat CSV file (results.csv) with a consistent schema containing the row type (env, check, or score), workspace name, section, severity status, a human-readable message, and an optional sub-item identifier for grouping (e.g., the rule name). Per-section scores and a final readiness percentage are calculated automatically. The data lake checks are reported separately and do not affect the final readiness score.

Severity classification

 

Analyzing the findings

The generated CSV is loaded into the accompanying HTML dashboard (dashboard.html), which provides:

• A multi-workspace overview with readiness scores and pie charts for each environment
• Per-workspace detail panels that break down findings by section (Defender data, analytics, automation, data lake region, table tiers)
• Multi-select filters to isolate Ok (Passed), Warning, or Informational findings
• Grouped rule views—analytics and automation rules are grouped by name, with individual sub-checks shown underneath
• Items overview cards summarizing the count and distribution of findings per section
• Export to PDF—either per workspace or across all environments at once
• Direct Azure portal links for each section, allowing operators to navigate directly to the relevant blade
• A built-in knowledge base with recommendations mapped to official Microsoft documentation
• A multitenant guidance tab covering access models (GDAP, Azure Lighthouse, B2B collaboration), MSSP best practices, and known limitations

Project contents

 

Why this lands well: You go from “I think we are ready” to a percentage score and a list of named items in under an hour—with a knowledge base that links each finding to documentation. The hardest part of any migration is no longer the hardest part.

Cost story

Cost model

• The Microsoft Sentinel pricing remains same for analytics tier data. The cost advantage of Defender comes from flexible billing and features (data lake, graph, MCP) that don’t exist in the Azure portal.
• Use the new Sentinel cost estimator to analyze your data ingestion and retention cost.

Sentinel data lake can introduce variable cost, but in most environments, it reduces overall cost meaningfully—by letting you keep long-tail data in a cheaper tier instead of paying analytics-tier rates for data you rarely query.

Reference SKU table

 

Why this lands well: Same analytics tier price, plus new tiers and capabilities that let you do things you simply could not do before. Run the estimator before you guess—most teams find the data lake reduces total spend once long-retention data is moved off the analytics tier.

The API strategy

The SecurityInsights API remains operational, but its coverage is scoped to Sentinel-specific resources and data. It does not surface Defender XDR incidents, Advanced Hunting data, or unified SecOps capabilities - meaning integrations built on it will lack access to the core unified experience.

Organizations relying on the SecurityInsights API should plan to migrate to the Microsoft Graph Security API as soon as possible. The Graph API provides unified coverage across Defender XDR incidents, Advanced Hunting, cases, and all emerging SecOps capabilities—areas the legacy Sentinel-only API does not expose. Migrating now reduces integration debt as Sentinel capabilities continue to consolidate into the unified Defender portal.

Common tasks

• Create/update a Sentinel incident (workspace object): SecurityInsights incidents
• List/manage Sentinel analytics rules: SecurityInsights alert rules
• Integrate with unified incidents: Defender incidents API and Graph security incidents
• Run Defender hunting programmatically: Graph security runHuntingQuery

Sentinel versus Defender versus Microsoft Graph security

 

Microsoft Graph security API – Overview

The Microsoft Graph security API provides a unified interface and schema to integrate with security solutions from Microsoft and ecosystem partners; it federates queries to onboarded security providers and aggregates responses.

What you use it for (common SOC/platform scenarios)

• Consolidate and correlate security alerts from multiple sources
• Pull and investigate incidents and alerts from services that are part of or integrated with Microsoft Defender
• Automate security tasks/workflows/reporting and send threat indicators (where applicable) into Microsoft products

Advanced hunting through Graph (high-value capability)

Graph security supports advanced hunting through runHuntingQuery, allowing you to run KQL on Microsoft 365 Defender advanced hunting tables and use results to enrich investigations.

Quotas/limits to keep in mind

• Queries generally explore up to the past 30 days of data
• Results can return up to 100,000 rows
• You can make at least ~45 calls/min/tenant (varies by tenant size); requests can be throttled with HTTP 429 when resources are exhausted
• If a request runs longer than 3 minutes, it times out
• Query output has an overall 50 MB size limit

Why this lands well: You do not have to rewrite anything urgently. Keep using SecurityInsights for Sentinel workspace work, layer Defender APIs for operational SOC actions, and treat Microsoft Graph security as the strategic direction for anything new—a single endpoint that already federates across products.

FAQ list: Questions every stakeholder asks

“Is this transition mandatory?”

Yes, but you have time. After March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in Microsoft Defender. All customers will be redirected to Defender for Sentinel security operations.

However, starting your transition now is strongly recommended to immediately access exclusive capabilities like Security Copilot, Sentinel data lake, and SOC optimization—features only available in Defender.

“Do I need to migrate my workspace?”

Workspace migration is not required. This is a common misconception. Your Sentinel workspace, log analytics workspace, and all data remain in their current Azure location. The transition is simply connecting your existing workspace to Defender for management.

Nothing about your data storage, retention, or access changes. You are not moving data—you are adding a new portal interface to the same underlying workspace.

“Will my costs change?”

There isn’t a cost change from the portal transition itself. Your Microsoft Sentinel pricing and billing model remains identical regardless of which portal you use. Data ingestion costs, commitment tiers, and log analytics charges all stay the same.

The only new potential costs are optional features available exclusively in Defender:

• Security Copilot: Requires separate licensing if you want AI-powered investigation assistance
• Sentinel data lake: Only incurs charges if you enable long-term retention beyond standard 90-day analytics tier

Standard Sentinel operations (data connectors, analytics rules, automation, hunting) have zero cost change from transitioning.

“Can I still use Azure portal?”

Yes, until March 31, 2027. During the transition period, you can use both portals simultaneously:

• Azure portal for configuration management (data connectors, analytics rules, automation)
• Defender for security operations (incidents, hunting, investigations)

Many organizations adopt a hybrid approach during transition: security analysts work primarily in Defender for day-to-day operations, while SOC engineers use the Azure portal for configuration and rule development.

After the March 2027 deadline, Sentinel security operations will only be available in Defender. However, the underlying Azure infrastructure (log analytics workspace, logic apps for playbooks) will remain accessible through the Azure portal for resource management.

“What if I use multiple workspaces?”

Multiple workspaces are fully supported. Defender has robust multi-workspace capabilities:

How it works:

• Connect all your Sentinel workspaces to Defender (one-time setup per workspace)
• Designate a primary workspace that feeds the unified incident queue
• Use the workspace switcher in Defender to view or query other workspaces
• Advanced Hunting can query across multiple workspaces simultaneously using the workspace function

For MSSPs managing customer tenants:

• GDAP (granular delegated admin privileges) is now supported in Defender with MTO including Sentinel capabilities
• Azure Lighthouse continues supporting cross-tenant workspace management
• Each customer tenant’s workspaces can connect to Defender

Considerations:

• Only the primary workspace contributes to the unified incident queue
• Other workspaces are accessible for hunting, queries, and investigation but don’t merge incidents into the main queue
• This prevents overwhelming analysts with incidents from test/dev workspaces while maintaining access to all data

Why this lands well: Every objection your stakeholders raise has a clean, source-grounded answer—mandatory but with runway, no data move, no surprise cost, two portals during transition, and full multi-workspace support.

Persona implications

 

Clearing up common misconceptions

• “This is a workspace migration.”
  It isn’t. Your Sentinel and log analytics workspaces stay where they are—you connect them to Defender.
• “Costs will go up automatically.”
  Analytics tier pricing is unchanged. New cost only appears if you opt into Security Copilot or enable the data lake—and the lake often reduces total cost when long-retention data moves off the analytics tier.
• “My API integrations will break on day one.”
  SecurityInsights remains the API for Sentinel workspace operations. Defender APIs and Graph security extend the surface area—they do not replace what you have.
• “I have to pick one portal.”
  Until March 31, 2027, both portals are supported. Most teams run a hybrid model during transition.
• “My multi-workspace setup will not work.”
  It will. Multi-workspace is fully supported. Designate a primary for the unified queue and use the workspace switcher for the rest.
• “I need an app registration to run the adoption helper.”
  Not required. User mode uses the well-known Azure PowerShell first-party client ID through device code flow—no App Registration required. App mode is available for unattended runs.

Do this week

• Clone the Defender adoption helper and run it across at least one production workspace; open the dashboard and walk the findings with your SOC team.
• Take the warnings the adoption helper surfaces and create one tracking item per warning (analytics rule cleanup, automation rule cleanup, table tier conversions).
• Run the Sentinel cost estimator with your current ingestion + retention numbers—model the lake scenario for long-retention tables.
• Inventory which systems call the SecurityInsights APIs today; for any new integration starting this quarter, default to Microsoft Graph security.
• Circulate the FAQ list (or a one-pager version of it) to executives and security leadership before they ask.
• Confirm whether your primary workspace region supports the Sentinel data lake—it determines part of the tiering plan.
• Calendar a transition kickoff for the next two weeks—the readiness work above gives you exactly the right inputs.

Continue the series

Each part in this series stands alone—pick the angle that matters most to you or read them in order.

Part 1 – Beyond a portal move: The strategic shift to Defender

Why the transition matters at the architecture and program level—the executive framing, the deadline, and the analyst validation.

Part 2 – Anatomy of the change: Incidents, alerts, correlation, and data

The component-level mechanics: how the XDR correlation engine replaces Fusion, why incidents are no longer alert-centric, and what changes (and doesn’t) in your data architecture.

Part 3 – Detection and automation, reimagined

How analytics rules, playbooks, workbooks, and hunting evolve—and why the toolbelt doubled, not shrank.

Part 4 – The governance shift: RBAC, URBAC, data lake, and MSSP

The move from Azure RBAC to URBAC, the data lake operating model, and multitenant patterns.

Part 6 – The AI-first SOC: Copilot, UEBA, threat intelligence, and SOC optimization

The destination: how Security Copilot, UEBA, threat intelligence, and SOC optimization combine into a fundamentally different operating model.