Migrate from Microsoft Sentinel to OpenSearch: what the move involves
Moving from Microsoft Sentinel to OpenSearch is a re-platforming of log storage, hunting and alerting, not a lift-and-shift. Sentinel's tables, KQL queries, analytics rules and workbooks do not carry over as files, so each one has to be exported, translated or rebuilt on the OpenSearch side. This applies whether the trigger is a renewal, the Azure portal retirement after March 31, 2027, a data residency requirement or a lock-in concern. Teams that treat it as a copy of data will find the detection gap only after cutover. In most cases, internal platform engineers and SOC engineers do the work, with an implementation partner covering architecture, hardening and integration. The internal team owns the detection logic, because only they know which alerts drive response. The partner typically handles cluster design, TLS and authentication through the OpenSearch Security plugin, and the ingest path. Ask the partner for a written scope that lists which Sentinel tables, which analytics rules and which workbooks are in and out, since that list drives the effort more than the data volume does. The effort and risk sit mainly in two places: streaming history and live events out of Sentinel during cutover, and proving that rebuilt alerts fire on the same activity. Run both platforms in parallel for a period you agree in advance, and compare alert output rule by rule before retiring the Sentinel side. Confirm with your own team and vendors how long you need to keep Sentinel data for legal hold, and whether the OpenSearch version you choose is still in maintenance for the period you plan to run it. Do not set a cutover date until both checks pass.
Which Sentinel capabilities map cleanly to OpenSearch and which need rework
This table maps the main Sentinel capabilities to their closest OpenSearch equivalents and marks each as clean, needs rework or gap. Read the status column as an effort signal: clean items move with configuration, rework items need their logic rewritten, and gaps need a replacement or an accepted loss. The main takeaway is that OpenSearch covers storage, search, dashboards and access control, but Microsoft's built-in connectors and Fusion do not carry over.
| Sentinel capability | OpenSearch equivalent | Status |
|---|---|---|
| Log storage | Indices on nodes you size and operate, with index lifecycle policies (confirm the feature in your version) | Clean |
| Hunting queries (KQL) | Discover for search and Query Workbench for SQL or PPL; KQL queries must be rewritten by hand | Needs rework |
| Workbooks | OpenSearch Dashboards visualizations and dashboards, rebuilt panel by panel | Needs rework |
| Analytics rules | Alerting plugin monitors and triggers, plus Security Analytics detectors; each rule is rewritten and tested | Needs rework |
| Fusion correlation | No built-in equivalent; correlation must be designed as custom rules and reviewed findings | Gap |
| Data connectors | No Microsoft first-party connectors; ingest through pipelines, agents or syslog that you build and maintain | Gap |
| Role-based access | Security plugin roles with document-level and field-level security and field masking | Clean |
| Sign-in | SAML or OpenID Connect through the Security plugin; confirm the identity provider setup with your team | Clean |
| Retention and archive | Retention set through lifecycle policies and snapshots to storage you control; sizing is your responsibility | Needs rework |
What data and rules move, and which export paths are documented
A Sentinel move to OpenSearch splits into three streams: historical log data, detection logic and the access model around them. Each stream has a different export path and a different rebuild effort, so it helps to inventory them separately before any cutover date is set. Confirm each export method against current Azure documentation for your specific tables.
Historical data from Log Analytics
Sentinel stores events in Log Analytics tables in your workspace, and history can be pulled out with queries or the Log Analytics export mechanisms. Export volume and format depend on the table and the retention tier, so check which tables hold the data you need to keep for investigations and audits. Plan a bulk backfill into OpenSearch indices separately from live ingestion so the two do not overlap in time. Confirm current export charges and limits with Microsoft before you size the job.
Continuous export and Event Hubs streaming
For cutover, the question is whether logs can keep flowing to OpenSearch while both platforms run in parallel. Azure documents continuous export of Log Analytics data and streaming paths through Event Hubs, but the supported tables and delivery details can change. Confirm the exact method for each table you plan to stream, and test that event ordering and timestamps survive the trip into OpenSearch ingest pipelines.
Analytics rules as ARM templates
Sentinel analytics rules can be exported as Azure Resource Manager templates, which gives you the query text, severity, schedule and entity mapping in a file you can review. The KQL inside each rule must be rewritten by hand as OpenSearch queries or Security Analytics detectors, so the export is an inventory, not a working detector. Tag each rule as keep, rewrite or retire before translation starts.
Hunting queries and workbooks
Saved hunting queries and workbooks live in Sentinel and do not move as working objects. Export the query text, then rebuild each one as an OpenSearch Dashboards visualization or saved search, because the dashboard layouts and parameters will not carry over. Workbooks with many dependent queries usually need the most rework. Keep a record of which investigations depended on each workbook so analysts know what to validate.
Watchlists and reference data
Watchlists hold lookup data such as VIP accounts, asset owners or allowed IP ranges that analytics rules reference. Export each watchlist as a file, then load it into OpenSearch as an index or lookup source that your detectors and enrichment pipelines query. Watchlist changes made in Sentinel will not sync automatically, so assign an owner for the new source and document the update process.
Identities and roles in the Security plugin
Sentinel access is governed by Azure role assignments scoped to the workspace, so each analyst's rights need a matching role in OpenSearch. The Security plugin supports SAML, OpenID Connect and LDAP sign-in, with role-based access, document-level and field-level security and field masking. Map each Azure role to a backend role, test that restricted analysts cannot see masked fields, and confirm audit log coverage before production access is granted.
How logs stream out through Event Hubs during cutover
The cutover pattern for this move has two parts that must run together: Sentinel data is streamed out of Azure through Event Hubs into an ingest path that feeds OpenSearch, and every log source is dual-sent to both platforms for a parallel run. The export path carries history and ongoing events out of Log Analytics, while the dual-send path keeps new detections and hunts working on the target before Sentinel is switched off. Confirm with your Azure administrators which tables are in scope, whether each table can be exported through a continuous export rule to Event Hubs, and whether any Defender XDR tables are routed differently now that the Sentinel workspace may be managed from the Defender portal. Do not assume every table has an equivalent export path.
Before data lands in OpenSearch, normalize fields to a common schema. Sentinel tables such as the sign-in and security event tables use Azure-specific column names, while Wazuh and other agents emit their own structures. Choose one target schema, map the timestamp, host, user, source address and event identifier fields explicitly, and encode that mapping in your ingest pipeline rather than in dashboards. Create index templates that set the field types, including date and IP fields, and define retention through index state management so that the hot, warm and deletion stages match the retention periods your compliance owners approved. Verify these settings on a test index before the first production load.
The parallel period must duplicate ingestion rather than replace it. Sentinel stays the system of record until the OpenSearch detections, alerting and reports have produced the same results on the same events for a period your security operations team agrees in writing. If you move a source to OpenSearch only, you lose the ability to compare alert volumes and miss events during the gap. Plan for double ingestion costs during this window, confirm the Event Hubs throughput and retention settings with your cloud team, and record each source's cutover date in the change log so that auditors can trace when evidence moved.
The migration sequence from inventory to decommission
This sequence moves Sentinel log storage and hunting to OpenSearch one source group at a time, with each stage producing a written artifact that proves coverage before Sentinel is switched off. It keeps detection parity and rollback options visible until the last source has cut over.
Build the inventory register
List every Sentinel table in use, every connector and data source feeding it, every analytics rule, hunting query, workbook and playbook, and the daily volume and retention for each table. Assign each item an owner and a source group so related feeds move together. The step is done when the inventory register is signed off by the SOC lead and the data owners, and every row has a target OpenSearch index pattern or an explicit decision to retire it.
Pilot one log source end to end
Choose a single, low-risk source such as one firewall or identity feed and route it through Azure Event Hubs to an OpenSearch ingest pipeline, with the same fields normalized. Compare event counts, timestamps and parsed fields against Sentinel for a defined observation window agreed in advance. The step closes with a pilot sign-off record that states what matched, what differed and which field mappings were corrected.
Translate hunting queries and workbooks
Rewrite each KQL hunting query as an OpenSearch query or a PPL query where the syntax fits, and rebuild each workbook as an OpenSearch Dashboards visualization or saved search. Test every translated query against the pilot data and record which ones return equivalent results and which need redesign. The output is a translation log that lists each original KQL item, its OpenSearch equivalent and the reviewer who approved it.
Rebuild alerting and produce the rule parity report
Recreate analytics rules as monitors and detectors using the OpenSearch alerting and security analytics plugins, mapping logic to Sigma-based rules where a community rule already exists. Run the old and new rules against the same replayed events and compare alert counts, severity and routing. The step produces a rule parity report that marks each rule as matched, adjusted with a documented reason, or retired with an approver's name.
Run both platforms in parallel
Keep Sentinel alerting active while OpenSearch alerts go to the same responders in a separate channel, so analysts can compare outcomes during real investigations. Track false positives, missed detections and alert latency on both sides for the agreed window. The step closes when the SOC lead confirms in writing that the parity gaps from the rule report are either closed or formally accepted.
Cut over by source group with a runbook
Move sources in the groups defined in the inventory, one group at a time, following a written cutover runbook. The runbook names the change steps for each connector, the rollback action, the people who approve each move and the check that confirms events are arriving in OpenSearch. Each group is considered complete only when its runbook checklist is signed and its alerts have been observed for the agreed period.
Export retained history and confirm access
Export the Sentinel history that must be kept for legal, audit or investigation needs, using the export method chosen during planning, and load it into OpenSearch with its original timestamps. Confirm that role-based access, field-level security and audit logging in the OpenSearch Security plugin match the access model Sentinel used. The step ends with an export manifest and a access review record.
Decommission Sentinel and record the decision
Once every source group is cut over and the retention obligations are met, decide whether Sentinel is switched off or kept for read-only use. Factor in the Azure portal change: after March 31, 2027, Sentinel is available only in the Microsoft Defender portal, and Microsoft Defender XDR retention and privacy policies apply there. Confirm the Defender portal transition decision with Microsoft documentation and your own contract terms, then issue the decommission record listing removed connectors, deleted workspaces and the date data retention ends.
How the migration differs by starting point
Teams still running Sentinel in the Azure portal face a fixed date. After March 31, 2027, Sentinel is available only in the Microsoft Defender portal, so the migration is driven by a deadline rather than by preference. The first task is to confirm which workspaces, analytics rules and data connectors are in scope and to decide whether the move to OpenSearch happens before or instead of the portal transition, since the portal move itself carries no extra cost according to Microsoft's transition guidance.
- Decide the sequence early: Choose between transitioning to the Defender portal first and migrating later, or moving directly to OpenSearch. Doing both changes creates two rounds of rule testing.
- Inventory before the cutover: List every analytics rule, hunting query, workbook and playbook, then mark which ones depend on Azure-only features.
- Start the history export sooner: Retention exports take time to validate, so begin them before the detection rewrite is finished.
- Run in parallel: Keep Sentinel receiving logs while OpenSearch alerts are tuned, so gaps are visible before the portal is switched off.
- Plan for the date, not the bulk of work: The deadline sets the outer limit; the rule translation is usually the longest task.
Confirm with Microsoft exactly which features your workspaces use that will change in the Defender portal before you fix the schedule.
Teams that have already moved Sentinel into the Microsoft Defender portal have a different starting problem. Retention and privacy now follow Defender XDR policies, and the Fusion analytics rule is replaced by Defender XDR correlation. Some of the detection logic they rely on may therefore already behave differently from what their documentation describes, so the first step is to establish a current baseline rather than assume the old Sentinel behavior.
- Re-baseline the detections: Record what alerts fire today under Defender correlation, since the replaced Fusion logic may have changed what is raised.
- Check retention policy mapping: Confirm how long data is kept under Defender XDR settings and how that compares with the retention your OpenSearch index lifecycle must support.
- Confirm the data path: Identify which sources reach Sentinel through Defender connectors and which need a new collector or pipeline.
- Reconcile privacy settings: Document which data classes and access rules move with the workspace and which must be recreated in OpenSearch Security roles.
- Shorten the parallel run where the baseline is clean: A current, well-documented set of rules usually supports a shorter overlap than a legacy estate.
Verify with the Defender portal documentation for your tenant that the retention and correlation behavior you observe matches what you plan to reproduce.
Organizations that leave Sentinel because of data residency rules, sovereignty requirements or concern about vendor lock-in usually have less flexibility on timing and more on scope. Because Sentinel runs only in Azure, the destination must be infrastructure the organization controls, which moves the work toward hosting design, identity integration and evidence of where data is stored. Here the sequencing is often set by the compliance owner rather than by the portal deadline.
- Define the residency boundary first: Specify which regions, data classes and administrators are in scope before choosing a hosting pattern.
- Design identity and access early: Map OpenSearch Security authentication backends and role-based access to the existing directory, so access is reviewed before data is loaded.
- Plan for exit from the export side: Confirm how Sentinel data and rules can be extracted in usable formats, since that determines how much history can move.
- Keep evidence for assessors: Record configuration, access and change history from the start, so the team can show controls during an assessment.
- Expect the longest timeline: Hosting, hardening and sign-off usually gate the work more than the rule translation.
Ask your compliance lead and the platform team to agree the residency boundary in writing before any scope is fixed, and confirm the scope with a written proposal.
What drives the cost and duration of the move
This table lists the factors that most change the effort and running cost of moving Sentinel log storage and hunting to OpenSearch. Read each row as a driver, why it moves the budget or timeline, how to keep it down, and what to request in a written quote. No Sentinel or DeployOpen prices appear here, so ask for figures in your own scope and environment.
| Driver | Why it changes cost or effort | How to keep it down | What to request in the quote |
|---|---|---|---|
| Number of tables and data sources | Each Sentinel table maps to an index pattern, ingest path, field mapping and retention rule, so more tables means more pipeline and validation work. | Export only the tables that hunting and compliance need, and retire low-value sources before the move. | A table-by-table inventory with the target index design, mapping approach and per-source test plan. |
| KQL analytics rules and workbooks | Each KQL rule must be translated, tested against OpenSearch data and rebuilt as alerting or Security Analytics detectors, and each workbook becomes dashboards. | Rationalize rules to those still in use and group similar workbooks before translation. | Count of rules and workbooks in scope, the translation method and the testing and sign-off steps for each. |
| Identity integrations | Sign-in through SAML, OpenID Connect, Active Directory or LDAP, plus role mapping for analysts, affects configuration and access testing. | Reuse the existing identity provider and map Entra ID groups to a small set of OpenSearch roles. | Which identity sources are in scope, the authentication backends configured and the access review evidence delivered. |
| Required retention | Longer hot and archive retention increases storage, snapshot and index management work, and sizing of the cluster. | Set retention by data class and use snapshots for older data rather than keeping everything hot. | Retention periods per table, storage tiers planned and the sizing assumptions behind the node count. |
| Parallel-run length | Running Sentinel and OpenSearch side by side doubles ingestion and staff attention until detections are proven equal. | Define exit criteria for detections and dual-run only the sources that carry detection risk. | The parallel-run window, the comparison method for alerts and the cutover and rollback steps. |
| Event Hubs export and cutover | Streaming tables out through Event Hubs needs throughput planning, consumer code and reconciliation of event counts during cutover. | Confirm volumes per table before sizing the export path and rehearse cutover on one source first. | Event Hubs throughput assumptions, reconciliation method and the owner of each cutover step. |
| Sizing and staff time to run OpenSearch | Cluster sizing, patching, upgrades within the maintenance window and backup testing are recurring work your team or a retainer must cover. | Plan on a supported version line, automate deployment and keep upgrade testing in a repeatable runbook. | Node and storage sizing, the operating model (in-house or retainer), upgrade and backup responsibilities. |
| Compliance evidence | Assessors expect the logging, access and retention controls to be documented and shown working after the move, which adds evidence collection work. | Map existing evidence sources early and reuse the same log fields where possible. | The evidence list per control, who prepares it and the format delivered to your assessor. |
What usually goes wrong and how to prevent it
Sentinel to OpenSearch migrations tend to fail in predictable places: the detection logic, the data path, the history, the alert stream and the access model. Each card below names one failure and a check to run before cutover, so the team can test the new stack against the old one instead of discovering gaps after Sentinel is switched off.
Detection parity gaps after KQL translation
KQL functions, joins, summarize logic and entity mappings do not translate one to one into OpenSearch queries, Sigma rules or the Security Analytics plugin's detector formats. A rule can convert cleanly and still return different results because a time window, a null handling rule or a field type changed. Run each translated rule against the same historical sample in both platforms and record which alerts match, which differ and why before any rule is retired in Sentinel.
Silent ingestion loss during cutover
When log sources are redirected from Event Hubs or Log Analytics export to OpenSearch ingest pipelines, a misnamed index, a rejected mapping or a broken certificate can drop events without raising an error in either system. Sources that were onboarded through Sentinel's built-in connectors may also have no equivalent collector yet. Count events per source per hour in both platforms during the overlap and treat any unexplained gap as a blocker for that source.
Retention gaps when history is not exported
Sentinel retention settings, archive tiers and data lake storage hold history that does not move on its own, so a team that cuts over without an export leaves investigators without the prior year of evidence. Exporting raw events is only part of the task, since analytics rules, watchlists and saved hunting queries also need to be kept. Agree the required look-back period with legal and compliance first, then confirm the export covers every table that period depends on.
Alert fatigue during the parallel run
Running Sentinel and OpenSearch side by side means the same event can generate an incident in each platform, and analysts end up triaging duplicates or, worse, learn to ignore a queue they assume is redundant. Duplicates also make it hard to measure whether the new rules fire at the expected rate. Route parallel-run alerts to a separate channel or tag them with their source platform, and set an end date for the overlap in the cutover plan.
Access model drift from Entra ID roles
Sentinel access follows Azure RBAC and Entra ID group membership, while OpenSearch controls access through its Security plugin with roles, role mappings and document-level and field-level rules. Groups that were scoped to a workspace in Azure can end up with broader or narrower index access than intended after the move. Map each Entra ID group to an OpenSearch role on paper, then test sign-in through SAML or OpenID Connect with a sample account from each group before analysts are migrated.
Questions buyers ask before moving from Sentinel to OpenSearch
How much effort and time does a move from Sentinel to OpenSearch take?
The effort depends mostly on how many analytics rules, workbooks and hunting queries you run, how many log sources feed Sentinel, and how much history you must keep searchable. No duration in this answer is supported by a researched figure, so ask for one only after a written inventory. Start by counting tables, data connectors, analytics rules, saved queries and workbooks, then group them by owner and business use. Ask any provider to tie its estimate to that inventory and to a named cutover approach. A parallel run, where Sentinel and OpenSearch receive the same data for a period, usually adds time but lowers cutover risk.
Can our own team migrate from Sentinel without outside help?
A team with strong OpenSearch, Linux and log pipeline skills can run the migration itself, but the work spans more disciplines than most SIEM teams hold in-house. Engineers need to rebuild ingestion, index mappings, access control and alerting, and they need to validate detections against known events. OpenSearch is licensed under Apache 2.0 and its FAQ does not describe a paid edition, so software licensing is not the barrier. The main cost is people time, plus the operating effort after go-live. Check whether your staff have run OpenSearch clusters in production and who will own patching and on-call support.
What does the migration need from our security and platform teams?
The migration needs decisions and access from security operations, platform engineering, identity and compliance teams. Security operations must confirm which detections matter and which can be retired. Platform teams must provide hosts or cloud accounts, storage, network paths and certificates. Identity teams must connect sign-in, since OpenSearch Security supports SAML, OpenID Connect, Active Directory and LDAP. Compliance teams should list the retention periods and audit evidence they must keep. Ask your implementation partner to name the owner for each of these inputs in the written scope before work starts.
Can KQL hunting queries be translated to OpenSearch automatically?
Simple KQL filters and aggregations can often be rewritten by hand or with help from conversion tooling, but no tool should be trusted to translate every query correctly. KQL and OpenSearch query DSL differ in field handling, time functions, joins and aggregation behavior, so each converted query needs a test against known events. Plan to review each query, document its intent, and retire queries that no longer match a live investigation. Ask any provider to show how it validates translated queries and which KQL operators fall outside its scope.
What happens to Sentinel history and workbooks during the move?
Historical data does not move automatically, so you must decide what to export, how long to keep it and where it will be searched. Sentinel data can be streamed out during cutover, but you need to confirm the export formats, volumes and any export charges with Microsoft and your own environment before committing. Workbooks do not translate directly, so rebuild the important ones as OpenSearch Dashboards views and retire the rest. Keep a record of the exported archives, their checksums and where each one lives, since auditors and incident responders may need that history later.
How do we rebuild Sentinel alerting on OpenSearch?
Alerting must be rebuilt on the OpenSearch alerting and security analytics plugins rather than copied from Sentinel. Each analytics rule needs a documented purpose, a data source, a severity, an owner and a test case before it goes live. Confirm the plugin versions in your chosen OpenSearch release, since maintenance and feature support differ by version. Run new and old alerts side by side for a period so you can compare volume and catch gaps. Retire rules that duplicate others or fire without action.
Which OpenSearch version should we plan to run?
Choose a version that is still under maintenance on the day you go live, and plan for upgrades throughout the life of the cluster. OpenSearch releases a new minor version about every eight weeks, and each version stays under maintenance until the next major version enters maintenance or one year passes, whichever is longer. During maintenance, versions receive bug fixes and security patches but no new features. Check the current release list before you pick a version, and confirm the upgrade path with your implementation partner. The FAQ states wire compatibility with Elasticsearch 7.10 REST APIs, which matters if you bring tools built for that API.
How DeployOpen scopes, runs and supports the migration
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Microsoft Sentinel to OpenSearch, that work starts with a written scope covering log flows, hunting content and alerting before any cluster is built.
How we scope
- Inventory the Sentinel workspaces, tables, data connectors and retention settings that feed the migration
- Map each KQL hunting query, workbook and analytics rule to an OpenSearch query, dashboard or alerting monitor
- Agree cutover sequencing, parallel run length and the Event Hubs export path in writing before work starts
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing before work begins
How we build
- Size and deploy the OpenSearch cluster in your environment using the installation method your teams prefer
- Configure the Security plugin for SAML, OpenID Connect or LDAP sign-in, role-based access and audit logging
- Rebuild alerting on the alerting and security analytics plugins, then test detections against replayed log samples
- Run security testing on the new ingestion path and dashboards before cutover is approved
How we hand over
- Document the ingestion pipelines, index layout, retention policies and access roles in a handover pack
- Deliver a translated query library with notes on every KQL construct that did not map directly
- Provide a record of the controls and evidence prepared for your compliance assessor, which auditors then review independently
- Walk your analysts and operators through hunting, alert triage and day-to-day cluster operations
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Plan minor version upgrades against the OpenSearch release schedule and maintenance window for your version
- Keep backups, snapshot restores and cluster health checks under documented runbooks
- Confirm support terms, response expectations and retainer scope with your team in the written agreement
