Migrate MS Sentinel from one tenant to another tenant

There is no “one-click” migration option to move Microsoft Sentinel (including workspace, data, rules, playbooks, connectors, and workbooks) from one tenant to another.

Microsoft Sentinel is tightly coupled to the Log Analytics Workspace, and moving a workspace between tenants is not supported. In a tenant-to-tenant scenario, the supported approach is to deploy a new Sentinel instance in the target tenant and migrate the content using Infrastructure as Code (ARM/Bicep) and export/import methods.

Here is what you can and cannot migrate.

What you can migrate

Analytics Rules
You can export and import Analytics rules using ARM templates (JSON). This is supported and is the most efficient way to move detection content.

Automation Rules
Automation rules can also be exported and redeployed via ARM templates.

Workbooks
Workbooks are Azure Monitor resources and can be exported as JSON and redeployed in the new tenant. You will typically need to adjust workspace IDs and resource references.

Playbooks
Playbooks are Azure Logic Apps. You can export them as ARM templates and redeploy in the new tenant. However, API connections, permissions, and managed identities must be recreated or adjusted in the destination tenant.

Data Connectors
Data connectors generally need to be reconfigured in the target tenant. Credentials, permissions, and service integrations are tenant-specific and cannot simply be exported and imported.

Solutions from Content Hub
Solutions can be reinstalled in the new tenant, but configuration and permissions must still be set up again.

What cannot be directly migrated

Historical Log Analytics data
There is no supported method to directly move Log Analytics data between tenants. If historical data must be preserved, common approaches are:

• Keep the source tenant active for retention and audit purposes
• Export historical data to storage or Azure Data Explorer before decommissioning

Recommended step-by-step approach

Phase 1 – Prepare the destination tenant

1. Create a new Log Analytics Workspace in the target tenant.
2. Enable Microsoft Sentinel on that workspace.
3. Configure RBAC and identities.

Phase 2 – Migrate content as code
4. Export Analytics rules as ARM templates.
5. Export Automation rules.
6. Export Workbooks (JSON/ARM).
7. Export Playbooks (ARM templates).
8. Update all resource IDs, workspace references, and parameters.
9. Deploy to the new tenant using ARM, Bicep, or CI/CD pipeline.

Phase 3 – Reconfigure connectors
10. Reinstall necessary Content Hub solutions.
11. Reconfigure data connectors and permissions.
12. Validate ingestion, alert generation, and automation workflows.

Phase 4 – Parallel validation
13. Run both tenants in parallel during transition.
14. Validate incident generation and response processes.
15. Decommission the source tenant once validated.

Key takeaway

There is no native migration tool that moves everything automatically between tenants. The supported and scalable approach is to treat Sentinel content as code and redeploy it in the new tenant using ARM/Bicep and CI/CD practices.