What you can export from Microsoft Sentinel and what you cannot
If a renewal, a pricing change, a residency requirement or a lock-in review is forcing an exit from Microsoft Sentinel, the short answer is that your data leaves through continuous Log Analytics data export and your detection logic leaves as analytics rule ARM templates. Neither path moves everything. The log records can be copied out in bulk, but the rules, workbooks, playbooks and connector configuration must be rebuilt on the new platform. Treat the export as a data transfer project and the rule inventory as a rewrite project, and plan them separately. Log data is the easier half. Data export rules write newline-delimited JSON to a storage account in the same region as the workspace, organized in 5-minute folders. Two limits matter for planning. Export is billed by bytes of JSON produced, so the exported volume is larger than the table size you see in Azure Monitor Logs, and a destination outage can lead to retries of up to 12 hours that may duplicate a small fraction of records. Confirm the exact export charges and retention behavior in your own tenant before you size a cutover, and check that the tables you need are supported for export.
Detection logic is the harder half. Sentinel can export analytics rules of any type to ARM template JSON, including the query, schedule, severity, grouping and MITRE ATT&CK settings. That feature is in preview and exports at most one page of rules at a time, so confirm completeness against your rule inventory. The exported KQL still has to be translated into Wazuh rules or OpenSearch detectors, and it does not carry over automation. Logic Apps playbooks, workbooks, watchlists, threat intelligence feeds, UEBA baselines and connector configurations stay behind, and the data connectors that feed them need agent or syslog replacements. Before you commit, ask for an inventory of every analytics rule, playbook and workbook, a list of which tables are in scope for export, and a written estimate of the storage needed for the exported folders. The sibling pages on the Sentinel to Wazuh and Sentinel to OpenSearch migrations cover the rewrite and cutover steps in detail.
Which Sentinel data types have a documented export path
This table lists the Sentinel data types that have a documented export route and the format, destination and limits of each. Read it to see which data you can move out with Log Analytics data export and which detection logic you can only export as ARM template JSON. Confirm each limit against current Microsoft documentation before you plan a cutover.
| Data type | Export route | Format and destination | Limits to plan around |
|---|---|---|---|
| Table data in the Log Analytics workspace | Log Analytics data export rule to a storage account | Newline-delimited JSON lines in folders by year, month, day, hour and minute, in 5-minute intervals | Up to 50,000 writes per blob before more blobs are added; destination must be in the workspace region |
| Analytics rules of any type | ARM template export from Sentinel | ARM template JSON files with query, schedule, severity, incident, grouping settings and MITRE ATT&CK tactics | Feature is in preview; exports at most one page of rules at a time |
| Cross-region copies of exported data | Storage redundancy chosen for the destination account | Same blob layout as the regional export | Microsoft suggests GRS or GZRS redundancy; confirm the options your region supports |
| Retried or delayed export records | Data export retry behavior | Records may arrive more than once after a retry | Retries run for up to 12 hours; plan deduplication on record identifiers in the target platform |
| Export charges | Billed per exported volume | Charged by bytes exported in JSON format, in GB | Exported size is larger than the table size shown in Log Analytics because each record carries property names |
| Incident, workbook and playbook content | No documented bulk export in the sources reviewed | Rebuild in the target platform from exported rule and query definitions | Confirm current export options with Microsoft before assuming a route exists |
What does not export directly and what to do about it
The documented export paths carry raw log tables and analytics rule definitions, but not everything that makes a Sentinel workspace work day to day. The items below sit outside those paths, so each needs a plan: rebuild it on the new platform, re-ingest it from the source, or record it by hand. Confirm the export status of every item with Microsoft for your own tenant before you assume a path exists.
Detection logic beyond ARM fields
The ARM template export keeps the rule query, schedule, severity, incident and grouping settings and MITRE ATT&CK tactics, but it does not give you a portable detection model. Rules that depend on watchlists, functions, entity mapping details or Defender portal-only correlation may need to be rewritten as Wazuh rules or OpenSearch detectors. Treat each KQL query as a specification to test against replayed events, not as code that moves unchanged. Confirm with Microsoft how your tenant's rule types export, since the export feature is in preview and returns at most one page of rules at a time.
Workbooks and dashboards
Workbooks are Azure resources built on KQL queries, parameters and Azure Monitor visuals, and they are not part of the table export or the analytics rule export. Each workbook has to be rebuilt as an OpenSearch Dashboards or Wazuh dashboard view, with queries translated and time parameters mapped to the new index layout. Inventory the workbooks your SOC and auditors actually open, because unused ones rarely justify rebuild effort. Ask Microsoft how to retrieve workbook definitions from your tenant before you decommission the workspace.
Playbooks and Logic Apps
Sentinel playbooks are Azure Logic Apps workflows with their own connections, managed identities and API keys. None of these travel with the log export, so their trigger logic, enrichment steps and ticket or chat actions must be recreated on the target, typically as workflows triggered by alerts. Credentials are not portable and must be issued again in the new environment, with secrets stored in a dedicated manager. Document each playbook's trigger, actions and downstream systems before you rebuild it.
Watchlists and reference data
Watchlists hold reference lists such as VIP users, approved IP ranges or asset owners, and analytics rules often join against them. Watchlist content can be uploaded from files, but confirm with Microsoft how your tenant exports watchlist items before you rely on that route. Where an export is not available, rebuild the lists from the system of record, such as the HR directory or CMDB, and load them into the new platform on a schedule. Keep a checksum or row count from each list so you can prove the copy is complete.
Incidents, comments and case history
Incidents, their comments, owners, status changes and the alerts grouped into them are records of how your team responded. Log data exports do not capture these records as incidents, so the case history needs its own route. Ask Microsoft whether your tenant's incident records can be retrieved through the API before the workspace is switched off. If they cannot, record the history manually into a case management system or an archive, and keep it with the retention period your audit or legal obligations require.
Data connector configuration
Data connectors define which sources feed the workspace, how they authenticate and which tables they write to. The connector settings do not move with the data, so the new platform needs its own collection path for each source, such as Wazuh agents, syslog or API polling. Record each connector's source, table, collection frequency and any parsing or filtering applied, because those details decide whether the replacement produces comparable events. Confirm with Microsoft which connector settings can be exported for your tenant.
How the JSON lines files are laid out in Blob Storage
The export writes files into a predictable folder tree, so a downstream loader can find a time window without listing the whole container. Each table is written under the destination storage account with folders for year, month, day, hour and minute, and each folder covers a five-minute window. Plan your loader around that structure: a job that ingests one hour of SecurityEvent or SigninLogs only needs to read twelve five-minute folders, and it should handle the folders in time order so late-arriving blobs are not missed. Confirm the exact path template in your own export rule before you write code against it, because the folder names are what your ingestion pipeline will depend on.
Within each folder, the data is stored as newline-delimited JSON, sometimes called JSON lines. Each line is one complete record as a JSON object, with no enclosing array and no commas between records. This matters for a loader because it can read the file one line at a time, parse each record independently and stop cleanly at a bad line, which suits most log loaders and Spark or Trino jobs. Export writes up to 50,000 writes per blob, after which additional blobs are added to the same folder. Your loader must therefore read every blob in a folder rather than assuming one file per window, and it should track processed blob names so that retries do not load the same records twice.
Size the storage and transfer budget from the exported size, not the table size. Microsoft states that the exported data is larger than the table size shown in Azure Monitor Logs, because every JSON record repeats its property names. The export is also billed by bytes exported in JSON format, measured in GB, so the same growth affects the export charge. Before you start, export a representative day from one high-volume table, compare the blob sizes with the table size in your workspace, and use that ratio to estimate the storage, egress and retention needs for the full table list. Ask Microsoft or your Azure account team to confirm current export pricing for your region.
The sequence for a complete Sentinel export, with verification
This sequence moves Sentinel log tables and analytics rules out in an order that keeps each export traceable, so you can prove what arrived in your storage and what detection logic was preserved before the workspace is retired.
Inventory tables and analytics rules
The security or platform engineer responsible for the workspace lists every table that holds data you need to keep, including custom log tables, and every analytics rule enabled in the workspace, noting its type, severity and owner. Record the current row counts per table and the rule count from the Sentinel analytics rules page so you have a baseline. The step is done when the inventory lists each table and rule, and the baseline counts are saved next to it.
Create the destination storage account
The cloud administrator creates a storage account in the same region as the Log Analytics workspace, because data export destinations must share that region. If you need a copy in another region, plan for a redundancy option such as GRS or GZRS, which Microsoft suggests for cross-region copies, and confirm the cost of that redundancy in your own subscription before you commit. The step is done when the account exists, its region matches the workspace, and access is limited to the people who will read the exports.
Configure data export rules per table
The workspace administrator creates one data export rule for each table in the inventory, pointing it at the storage account and leaving the destination in the same region. Log Analytics writes newline-delimited JSON into folders organized by year, month, day, hour and minute in five-minute intervals, so confirm the first blobs appear under the expected path before you rely on the rule. The step is done when every table in the inventory shows an enabled rule and the first blobs for each table are visible in storage.
Export analytics rules as ARM templates
The detection engineer uses the Sentinel import and export feature to save analytics rules as Azure Resource Manager template JSON files, which carry the rule query, schedule, severity, incident and grouping settings and MITRE ATT&CK tactics. This export feature is in preview and returns at most one page of rules at a time, so repeat the export until every rule in the inventory is covered. The step is done when the template files exist for every rule and each file opens with its query intact.
Wait for the export to backfill
The platform team leaves the rules running and checks storage at intervals rather than assuming the export is complete. If a destination lacks scale or availability, data export retries for up to 12 hours, so records may arrive late and some may appear more than once. Do not treat counts as final until that retry window has passed without new failures in your own environment. The step is done when the blob counts stop changing for each table and no retries are pending.
Verify record counts against the workspace
The analyst compares the row count for each table in the workspace over the exported time range with the record count parsed from the JSON lines in storage, using a script or a query tool you choose. Expect the exported size in bytes to be larger than the table size shown in Azure Monitor Logs, because each record carries property names, so compare record counts instead of sizes. Where counts differ, check whether duplicates from the retry window explain the gap, and document any remaining difference. The step is done when each table has a recorded reconciliation with the cause of any variance.
Verify rule counts and handle duplicates
The detection engineer counts the ARM template files and compares them with the enabled rule inventory, checking that each rule's query, severity and MITRE tactics appear as expected in the file. Duplicate records from the retry window should be removed or flagged in your target platform using a deduplication key, such as the event identifier and timestamp, before any counts are reported. The step is done when the rule count matches the inventory and the deduplication approach is written down with the reconciliation records.
Questions buyers ask before exporting Sentinel data
What does it cost to export data from Microsoft Sentinel?
Log Analytics data export is billed by the bytes it exports in JSON format, measured in GB (10^9 bytes). The export is a separate charge from the ingestion and retention charges already on your workspace bill. Expect the exported volume to be larger than the table size shown in Azure Monitor Logs, because every exported record carries its property names. Export costs also recur for as long as the rule runs, so a continuous export adds a steady line item rather than a one-time fee. Ask Microsoft's pricing page for current rates, and model the export against your actual daily volume per table before you turn it on.
How long does a full export from Sentinel take?
The duration depends on the daily volume you export, the number of tables in scope, the destination's throughput and whether the destination is in the same region as the workspace. Data export rules run continuously, so new records flow out as they arrive, but historical data is not replayed by the rule itself. Backfilling older records is a separate job that you size from the volume in each table. Confirm the expected throughput with your storage configuration and test with one table before scheduling the rest.
What does the export need from our team?
The work needs an Azure administrator to create the storage account in the same region as the Log Analytics workspace and to grant the export rule access to it. Someone must choose the tables to export, set retention and access policies on the blobs, and agree on the folder layout that downstream tools will read. An engineer must then write a parser for the newline-delimited JSON files and confirm that the schema matches what the target platform expects. Plan for ongoing ownership of the storage account, its redundancy choice and the access logs.
Can we export Sentinel data ourselves without a partner?
Yes, a capable Azure and data engineering team can set up data export rules, storage and parsing without outside help, because the configuration is documented and the output is plain JSON. The harder parts are the decisions that come before the export: which tables matter, how long each one must be kept, what the sensitive fields are and how the exported files will be protected. Rewriting analytics rules as ARM template JSON, which Microsoft describes as a preview feature, also takes detection engineering skills. If your team lacks those skills or the time to do the work alongside daily operations, a fixed-scope engagement with written deliverables is one option to evaluate.
Can we export historical Sentinel data after the fact?
Continuous data export rules only forward new records, so history is not included when a rule is first created. Historical data must be pulled with separate queries or jobs against the workspace, and those jobs have their own cost and time considerations. Check what retention your workspace has for each table, since records past that point may no longer be available to export. Ask Microsoft for the current documentation on query limits and export options for older data before you commit to a backfill plan.
How are duplicate records handled when exports retry?
If a destination lacks scale or availability, the export retries for up to 12 hours, and that retry behavior can duplicate a fraction of the exported records. Your downstream pipeline should therefore be idempotent, meaning it can receive the same record twice without double-counting it. Practical approaches include deduplicating on a stable event identifier, such as the TimeGenerated timestamp combined with the record's own key fields, before loading into the target. Test the deduplication logic with deliberately repeated files and document the rule so auditors can follow it.
Does the export keep the data in the same region?
Microsoft requires the export destination to be in the same region as the Log Analytics workspace. For a cross-region copy, Microsoft suggests Azure Storage redundancy options such as GRS or GZRS, which you should select with your data residency rules in view. Confirm where each copy lives and who can access it, since exported logs often contain user identifiers, IP addresses and other personal data. Record these decisions in your data inventory so the residency position is documented before the export starts.
What to plan before the Sentinel contract or subscription ends
Leaving Microsoft Sentinel is mostly a sequence of dated decisions: when the Azure portal stops being the place you manage Sentinel, how much history you keep, what the export costs, and where the data sits. Each card below is a decision or check to settle before the export pipeline is switched on, because the answers change the scope of the export and the budget for the target platform.
Azure portal retirement date
Microsoft Sentinel will no longer be supported in the Azure portal after March 31, 2027, and will be available only in the Microsoft Defender portal. Confirm which portal your team, runbooks and automation depend on, and whether your contract or subscription end date falls before or after that deadline. Plan the export window against that date, not against the end of the license term alone.
Defender XDR retention and privacy
If you move Sentinel into the Defender portal, Microsoft Defender XDR data privacy and retention policies apply instead of Sentinel's own settings, and the Fusion analytics rule is replaced by Defender XDR correlation. Microsoft says the move carries no extra cost. Check whether your current retention and data handling terms still hold under those policies, and whether any detection that relied on Fusion needs a replacement before you export its history.
Retention window to preserve
Decide how far back the exported history must reach, and who needs it: incident response, audit evidence, or regulatory retention. Record the table list and the date range for each, because the export rule only captures data from the time it is created forward. Historical data already stored in Log Analytics must be exported through a separate job or retained in the workspace, so confirm both options with your compliance owner before the workspace is reduced.
Export charges in the budget
Log Analytics data export is billed by the bytes it writes in JSON format, measured in GB (10^9 bytes). The exported size is larger than the table size shown in Azure Monitor Logs because each record includes property names. Estimate the export volume per table for the overlap period, add it to the Sentinel bill, and ask Microsoft for the current export rate in your region and billing plan, since the rate is not part of this page.
Storage redundancy and residency
Export destinations must be in the same region as the Log Analytics workspace. Microsoft suggests Azure Storage redundancy options such as GRS or GZRS for cross-region copies. Decide which regions and storage tiers hold the exported files, confirm that residency rules allow that location, and note that a destination that lacks scale or availability causes export retries for up to 12 hours, which can duplicate a fraction of records during the handover.
Target platform licensing
Before the exported data has a new home, confirm the license model of the target. Wazuh is distributed under GPLv2 with an OpenSSL linking exception, and OpenSearch is under Apache 2.0 with no paid edition described in its FAQ. Check whether any component you pick, such as a managed Wazuh service or an add-on tier, carries fees, and confirm the support scope you need from the vendor or your implementation partner.
Rewriting exported analytics rules for the new platform
Sentinel can export analytics rules of any type to Azure Resource Manager template JSON files, and each file carries the rule query, schedule, severity, incident and grouping settings, and the MITRE ATT&CK tactics. That makes the template the most complete written record of your detection logic, so treat it as an inventory to review before any rule is rebuilt. Export it, then check each rule for the settings that matter on the target: the schedule and lookback window, the severity mapping, the incident grouping, and the tactics tagged to it. The query language and runtime will change, so the KQL text is a specification of intent, not code you can paste into another platform.
Plan the rewrite in the target's own terms. In Wazuh, detections become decoders and rules, and in OpenSearch they become detector or alerting definitions, each with its own query syntax and execution model. Test every rewritten rule against sample events exported from Sentinel or drawn from your own data, and record which known-bad and known-good events fire it. Note also that the export feature is in preview and returns at most one page of rules at a time, so confirm with Microsoft which fields the preview export covers, whether it includes rule state and exclusions, and how to verify that every rule was captured before you rely on the files as your only copy. Current documentation is in Import and export Microsoft Sentinel analytics rules.
How DeployOpen scopes and delivers a Sentinel data exit
DeployOpen plans and delivers the export of Microsoft Sentinel data into storage you control, inside your own cloud account or data center. Engagements are fixed-scope, so the written scope sets which workspaces, tables, retention periods and analytics rules are covered before any work starts.
How we scope
- Inventory the Log Analytics workspaces, tables and retention periods that feed Sentinel, and record which ones must leave.
- Confirm the destination region and storage redundancy with your team, since export targets must sit in the workspace region.
- Agree in writing whether analytics rules are exported as ARM templates and whether rewriting them for the new platform is included.
How we build
- Configure continuous data export rules and the storage account layout, then verify JSON lines files appear in the expected folders.
- Estimate the export charges from measured table sizes with you, since exported JSON is larger than the table size shown in Azure Monitor Logs.
- Test duplicate handling after a destination outage, because export retries for up to 12 hours can duplicate some records.
How we hand over
- Document the export configuration, folder structure, file naming, retention settings and the checks used to confirm completeness.
- Deliver the exported analytics rule templates with an inventory showing which rules were converted, rewritten or retired.
- Walk your operations and detection teams through reading the exported data and reusing it in the target platform.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the handover is complete.
- Review export health and storage growth on the schedule agreed in the written scope, so gaps are caught early.
- Confirm current Sentinel preview features and Defender portal changes with Microsoft before each phase of the exit.
