Skip to content

Sentinel Migration and Portal Transition

Atlanta, USA

GitHub Cloud2BR OSS - Learning Hub

Last updated: 2026-07-27

References

Back to the documentation hub

Sentinel capabilities and portal experiences evolve. Treat a portal transition, security information and event management (SIEM) migration, or connector replacement as a controlled service change with an inventory, parallel validation, responder training, and rollback plan.

Build the migration inventory

Inventory workspaces, connectors, data collection rules, tables, transformations, retention, analytic rules, watchlists, threat intelligence, workbooks, notebooks, playbooks, managed identities, role assignments, integrations, incidents, and external runbooks. Map each item to an owner, dependency, test, target state, and rollback action.

Transition safely

  1. Confirm current product guidance, supported migration paths, and portal availability for your region and tenant.
  2. Export or version-control custom content and configuration before changing it.
  3. Pilot with representative data, alerts, entities, incidents, and automation.
  4. Run the old and new paths in parallel when the use case requires continuity.
  5. Compare data freshness, rule results, incident behavior, role-based access control (RBAC), and cost.
  6. Train responders on the selected portal and update runbooks before cutover.
  7. Decommission old integrations only after evidence, retention, and recovery requirements are satisfied.

Set up the transition

  1. Create a migration backlog mapping every workspace, connector, rule, workbook, playbook, identity, and responder runbook to an owner and target state.
  2. Export or commit custom Sentinel content and record the current portal configuration, role assignments, and incident-routing settings.
  3. Enable the target portal or migration path for one pilot workspace and grant a small responder group the required roles.
  4. Reconnect or validate each pilot connector, then test priority analytics, automation, and incident workflows against representative data.
  5. Run the existing and target paths in parallel for the agreed review period and compare coverage, freshness, access, costs, and responder outcomes.
  6. Approve cutover, train responders, update runbooks, and retain the rollback decision and evidence before decommissioning the old path.

Acceptance criteria

  • Required data reaches the expected tables with the expected schema and volume.
  • Priority analytics and hunting queries return equivalent or intentionally improved results.
  • Incidents retain correct entities, ownership, comments, and automation behavior.
  • Privileged access, break-glass access, and audit trails are tested.
  • Costs, retention, archive, exports, and legal obligations remain understood.

Business example

A security operations center (SOC) transitions Sentinel operations to the Defender portal. Before changing the responder workflow, it pilots high-severity incidents from Defender extended detection and response (XDR), Entra, and a third-party firewall. The team verifies that assignments, comments, playbook approvals, and incident status remain consistent, updates analyst runbooks, and retires the old queue only after a two-week parallel review.