Migrate from Microsoft Sentinel to Wazuh: what the move involves
The move from Microsoft Sentinel to Wazuh is a rebuild of collection, detection and response on Wazuh's four components: the Wazuh indexer, the Wazuh server, the Wazuh dashboard and the Wazuh agents on endpoints. Sentinel's data connectors, KQL analytics rules and Logic Apps playbooks do not carry over as they are. Teams usually arrive here because of a renewal, Azure billing that is hard to forecast, a data residency requirement, or the change that moves Sentinel into the Microsoft Defender portal after March 31, 2027. Whatever the trigger, the work is a platform project with a cutover, not a configuration change inside an existing tool.
Security engineering usually owns the detection content, meaning the rewrite of analytics rules as Wazuh decoders and rules and the mapping of alerts to the SOC's runbooks. Platform engineering owns the server sizing, the indexer cluster, the agent rollout through configuration management, backups and upgrades. The SOC owns acceptance testing, because analysts must confirm that alert volume and fidelity are acceptable before Sentinel is switched off. Procurement and compliance should be involved early, since the Sentinel retention and export obligations must be settled before any data is deleted. Effort and risk are driven by how many data connectors, custom rules and playbooks you run, how many endpoints need an agent and how much history must be kept. Ask any implementation partner for a written scope that lists each of these, and confirm the Wazuh release line and offline needs with the Wazuh documentation for your environment before you commit to a timeline.
Which Sentinel capabilities map cleanly to Wazuh and which need rework
This table maps the main Sentinel capabilities to their Wazuh equivalents and labels each as clean, needs rework or gap. Read the status column first, then the Wazuh column to see what your team must build. Connector coverage for Microsoft cloud sources must be confirmed against the connectors you actually use before you plan cutover.
| Sentinel capability | Wazuh equivalent | Status |
|---|---|---|
| Log collection from Windows and Linux hosts | Wazuh agents on endpoints, forwarding events to the Wazuh server for decoding and rule analysis | Clean |
| Syslog and appliance logs (firewalls, network devices) | Syslog collection on the Wazuh server, plus agentless monitoring with periodic API probing where a device supports it | Clean |
| Microsoft cloud data connectors (Entra ID, Microsoft 365, Azure activity, Defender sources) | No direct equivalent assumed. Wazuh pulls some cloud sources through integration modules, so confirm each connector against current Wazuh documentation or ingest through a forwarder you build | Needs rework |
| KQL scheduled analytics rules | Wazuh rules in XML with decoders that parse fields, and correlation through frequency and timeframe settings. Each KQL query is rewritten by hand | Needs rework |
| Analytics alerts and incidents | Alerts stored in the Wazuh indexer and shown in the dashboard. Incident grouping, ownership and status must be rebuilt in your case tool or ticketing system | Needs rework |
| Workbooks and dashboards | Wazuh dashboard views and OpenSearch Dashboards visualizations, rebuilt from the saved queries you export | Needs rework |
| Logic Apps playbooks | Shuffle workflows triggered by Wazuh alerts, or custom scripts calling the same ticketing, chat and enrichment APIs | Needs rework |
| Defender XDR correlation and Fusion detections | No direct equivalent. Wazuh rules and event correlation cover part of the logic, and cross-product incident correlation must be designed and tested | Gap |
| Regulatory compliance views (PCI DSS, GDPR, HIPAA, NIST 800-53) | Prebuilt compliance views in the Wazuh dashboard, mapped to framework requirements in your own control evidence | Clean |
| Vulnerability and endpoint inventory findings | Wazuh vulnerability detection correlates agent software inventory with CTI or an offline vulnerability repository | Clean |
Which history, sources and integrations to move
Moving off Sentinel is four separate jobs: keeping historical data, carrying detection logic, replacing data sources and rebuilding downstream integrations. Each one has a different owner, a different format and a different point where work can stall, so inventory them separately before choosing a cutover date.
Export historical data first
Sentinel's continuous export rules can send Log Analytics tables to Azure Storage, and that is the documented path to take history out of the workspace. Confirm the export format, the folder layout and the per-GB export charges in Microsoft's current documentation before scheduling it. Exported files are not indexed for search in Wazuh by default, so plan a conversion and indexing step, and test a sample time range end to end before you rely on it for investigations or retention.
Inventory analytics rules for rewriting
Export the analytics rules as ARM templates so the detection logic is captured in a reviewable form, then list each KQL query, its schedule, its entity mappings and its severity. Most rules will not translate line for line into Wazuh decoders and rules, so classify them as rewrite, replace with a file integrity or vulnerability check, or retire. Fusion-based detections in the Defender portal are replaced by Defender XDR correlation, so record which rules depended on it.
Map every data connector
Build a table of each active data connector, the tables it writes to and the event sources behind it. Each row then maps to one of three Wazuh paths: a Wazuh agent on the endpoint, syslog collection from network devices, or agentless API probing for devices that expose an API. Several Microsoft connectors pull from cloud APIs with no local host, so confirm whether a Wazuh integration exists or whether you need a custom collector before the source is considered covered.
Deploy agents and syslog listeners
Windows and Linux servers and workstations usually move to Wazuh agents, which also cover file integrity monitoring and inventory collection. Firewalls, switches and appliances that send syslog to Sentinel can be pointed at the Wazuh server, and devices with an API can be probed on a schedule. Agent versions, the server cluster sizing and the remote configuration plan should be documented before you change any log forwarding on production systems.
Rebuild notifications and ticket sync
Logic Apps playbooks often send alerts to chat, open tickets, enrich incidents or call response actions, and none of those flows move automatically. List each playbook trigger, each external system it calls and each credential it uses. Wazuh alerts can feed an external orchestration tool, and the rebuilt flows need their own testing, error handling and secret storage, with the old playbooks kept disabled until the new ones are verified.
Confirm the evidence trail
Some controls depend on retained logs, not just on active alerting, so record which exported tables satisfy each retention or audit requirement. Confirm with your assessor or compliance team whether an exported archive, a Wazuh index or both will be accepted as evidence. Keep Sentinel's retention and export settings unchanged until that decision is documented.
How KQL analytics rules become Wazuh rules
KQL analytics rules cannot be translated line by line into Wazuh. Each rule has to be read for what it actually detects: which event fields it depends on, which log sources produce those fields, what time window it correlates over, and what count or threshold turns a pattern into an alert. Start by listing the fields each rule references, then check whether a Wazuh decoder already extracts them from the same source. Where it does not, write a decoder in the local_decoder.xml file so the value is parsed into a named field. Next, express the logic as a rule in local_rules.xml using the frequency, timeframe and if_matched_sid settings where the detection depends on repetition or sequence. Only then consider whether a stateless rule covers the same intent.
Testing is where most migrations succeed or fail. Use wazuh-logtest to run sample events from the exported history through the decoders and rules, and confirm that each alert fires on the events the Sentinel rule fired on, and stays silent on the benign events it was tuned to ignore. Keep a table that maps each Sentinel rule to its Wazuh rule ID, its data source and its test events. Note that the Fusion analytics rule in Sentinel is replaced by Defender XDR correlation when Sentinel runs in the Defender portal. Decide rule by rule whether the detection stays in Defender, because Defender holds the endpoint and identity signals, or moves to Wazuh, where the log source and rule logic are under your control. Confirm with your security team which detections must remain in Defender for their incident process.
Migration sequence from inventory to decommission
This sequence moves Sentinel detections, sources and response workflows to Wazuh in controlled stages, so each source group is proven on the new platform before Sentinel stops receiving it. Each step closes with a named record that the next step depends on.
Inventory sources, rules and playbooks
Start by listing every data connector, custom table, scheduled analytics rule, Fusion or Defender-side correlation that your team relies on, and every Logic Apps playbook attached to an alert. Record the owner, the log volume, the retention requirement and the compliance framework each item supports. Export the analytics rules as ARM templates so the logic is preserved in a readable form. The output is an inventory register with one row per source, rule and playbook, signed off by the security operations lead and the compliance owner. Confirm the current Sentinel retention settings and any Defender portal policies before you record retention needs, because they differ from Sentinel's own settings once the workspace moves.
Run a pilot Wazuh deployment
Install a pilot Wazuh environment in a non-production network segment. Wazuh documents an all-in-one installation, a prebuilt OVA virtual machine, Docker, Kubernetes and an offline guide, so choose the method that matches your hosting and connectivity rules. If the pilot sits in a disconnected network, follow the offline installation guide and plan an offline vulnerability repository in place of the online threat intelligence feed. Enroll a small set of agents from representative Windows and Linux hosts, add one syslog-fed firewall, and confirm alerts reach the dashboard. The output is a pilot report that records the install method, agent count, decoder and rule gaps against the inventory register, and any hardware or network constraints found.
Rebuild detections as Wazuh rules
Translate the highest-priority KQL analytics rules into Wazuh decoders and rules, starting with the detections that the compliance owner marked as required. Test each rebuilt rule against replayed or recreated events from the pilot, and document which Sentinel detections have no direct equivalent so they can be redesigned or accepted as a gap. Map the Wazuh dashboard compliance views for frameworks such as PCI DSS, GDPR, HIPAA and NIST 800-53 to the controls in your register. The output is a rule mapping table with one row per Sentinel rule, its Wazuh equivalent, the test evidence and the accepted gaps.
Run both platforms in parallel
Point each in-scope source at Wazuh while it still feeds Sentinel, so both platforms receive identical events for an agreed observation period. Compare alert volumes, false positive rates and the time to detect the same test activity on each platform, and log every difference. Keep Sentinel as the system of record until the parity log shows that the agreed detections fire on Wazuh with acceptable noise. The output is a parity log that lists each source, each detection, the matched and missed alerts, and the decision taken on each gap. Ask your DeployOpen or internal team to define the pass criteria in writing before the parallel run starts.
Cut over by source group
Move sources in groups, such as identity, endpoints, network devices and cloud audit logs, instead of switching everything at once. For each group, replace the Sentinel data connector with a Wazuh agent or syslog collection, rebind the matching rules and playbooks, and confirm that the response workflows still trigger. Replace each Logic Apps playbook with a Shuffle workflow triggered by Wazuh alerts, and retire the Sentinel route for that group only after its parity checks pass. The output is a cutover runbook per group, listing the change window, rollback steps, the named approver and the post-cutover checks.
Decommission Sentinel with retained exports
After all groups are cut over and the retention period set by your compliance owner has been covered, stop data ingestion into Sentinel and disable the export rules. Keep archived exports in a location you control, with checksums and an index that maps each file to its source and time range, so investigations and audits can still reach historical data. Confirm the export format and folder layout you received from Sentinel before you delete anything, and check the Defender portal retention policies that still apply to any data kept in the workspace. Remove connectors, rules and workspace resources only after the archive is verified. The output is a decommission record that lists the archive location, verification results, deleted resources, the retention schedule and the sign-off from the data owner.
Running Sentinel and Wazuh in parallel and cutting over
During the parallel run, the same events reach both platforms. The simplest pattern is to keep existing Sentinel data connectors and Azure Monitor Agent collection in place while adding a second destination for each source, such as a Wazuh agent on endpoints or a syslog forwarder for network devices. Dual forwarding doubles the collection work on the source and the transport, so confirm that the source's CPU, network and local buffer can carry both paths before you turn the second one on.
- Duplicate at the source, not in the cloud: Adding a Wazuh agent or syslog target beside the Sentinel path avoids depending on Sentinel exports, which keeps the Wazuh copy independent of Azure outages.
- Tag the origin: Set a source tag or field in each path so that events and alerts can be grouped by platform when you compare them.
- Watch time sync: Confirm that both platforms agree on timestamps and time zones, because mismatched clocks make alert comparisons look like detection gaps.
- Limit scope early: Start with a small set of hosts per source class so that problems surface before the whole estate is duplicated.
- Document each path: Record which connector, agent or forwarder feeds each platform so the cutover plan has a clear inventory.
Before you call the parallel run stable, check that events from each source arrive in both platforms at the expected rate and that no source silently drops out of either path.
Cut over by source class rather than all at once. Endpoints usually come first because the Wazuh agent provides the richest coverage there: log analysis, file integrity monitoring, the software inventory used for vulnerability detection, and remote agent configuration. Network devices and cloud sources come later, since they depend on syslog collection, API probing or cloud log pulls that need more design work. Identity and high-value sources should move only after the endpoint path has shown stable results.
- Endpoints first: Move Windows, Linux and macOS hosts once the agent deployment and policy baseline are proven.
- Network sources second: Firewalls and other devices move through syslog collection, with the parser and rule mapping tested against recent logs.
- Cloud and SaaS sources last: These often need custom integrations or API probing, so plan them with the owners of each tenant.
- Retire Sentinel connectors per class: Disable a Sentinel connector only after its Wazuh path has run through a full review cycle.
- Keep a hold list: Mark sources that depend on Microsoft-specific tables or Defender features so they move only after a replacement is verified.
At each step, confirm that the detections, dashboards and compliance views the teams use are available in Wazuh before the Sentinel source is switched off.
Compare the two platforms on what they detect and how they behave, not just on how many alerts they produce. Volume differences are expected because the rule sets, decoders and correlation logic differ. The useful question is whether the same incidents, test events and attack simulations produce an actionable alert in both places, and whether the analyst workload is acceptable. Use a fixed set of test cases that the security team agrees on before the parallel run starts.
- Build a test case set: Include known benign activity, simulated attacks from your red team or testing partner, and recent confirmed incidents.
- Map alerts to outcomes: For each test, record whether Sentinel alerted, whether Wazuh alerted, the time to alert and the severity.
- Review false positives separately: Track noisy rules on each side and tune them before comparing totals.
- Measure volume by source class: Break daily alert counts down by source so that a jump in one class is easy to explain.
- Record gaps: Note each Sentinel analytics rule with no Wazuh equivalent so that the gap is either accepted or closed.
Ask your security team to sign off on the comparison method and the acceptance thresholds before the results come in, so the decision rests on agreed criteria.
Define rollback criteria in writing before cutover. A rollback might mean re-enabling a Sentinel connector, restoring a forwarder or pausing a Wazuh rule set. Triggers typically include a source that stops reporting in Wazuh, missed test detections that Sentinel caught, or analyst workload that the team cannot sustain. Keep Sentinel retention running until the evidence needs for the period you must cover are met, because historical data is what auditors and incident responders will ask for after the switch.
- Set explicit triggers: Write down the conditions that force a rollback, such as a missed test detection or a silent source, and who can invoke it.
- Keep the Sentinel path warm: Leave connectors disabled rather than deleted for a defined period so they can be restored quickly.
- Confirm retention needs with compliance: Ask your compliance lead which log periods must remain available and in what form, and keep Sentinel data until that obligation is covered.
- Plan the export: Use Sentinel export rules or other supported methods to preserve history that Wazuh will not hold, and check what Azure charges for it.
- Record decisions: Keep a dated log of each cutover and rollback so that the evidence trail survives the migration.
Before you decommission Sentinel, confirm with your auditors and legal team which records they still require and where those records will be stored.
What drives the cost and duration of the move
This table lists the factors that change the size of a Sentinel to Wazuh migration, why each one matters, and how to keep it manageable. Read it as a checklist for scoping and for comparing quotes, since most of the effort sits in inventory, rule rewrites and history handling rather than in the software itself. No Sentinel or Wazuh prices are given here, so confirm them with Microsoft and in your own environment.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Data connectors and log sources | Each Sentinel data connector maps to a Wazuh agent, syslog feed or API pull that must be configured, parsed and tested. Connectors for cloud services often have no direct Wazuh equivalent and need custom collection. | Inventory every connector and table, group sources by collection method, and retire sources that no analytics rule or workbook uses. |
| KQL analytics rules | Each KQL rule must be read, translated into Wazuh decoders and rules, tuned against real events and re-tested. Rules with joins, lookups or time windows take the most work. | Export rules as ARM templates, score them by use and complexity, and migrate the high-value detections first. |
| Playbooks (Logic Apps) | Each playbook is a separate workflow with its own connectors, credentials and approval steps. Rebuilding them in Shuffle or another SOAR tool is a design task, not a copy. | Count playbooks by trigger and action, drop unused ones, and map the remaining ones to Wazuh alert triggers. |
| History volume to export | Large retained history takes longer to export and index, and export charges and storage transfer time grow with volume. Wazuh history is usually loaded in batches, not replayed in full. | Agree in writing how much history is needed for hunting and audit, and export only that window in formats the new indexer can ingest. |
| Wazuh indexer and server sizing | Indexer storage, search load and server analysis capacity depend on event rate, retention and alert volume. Undersizing causes dropped or delayed alerts. | Measure current daily volume and peak rate from Sentinel, then size a test cluster and load it with representative data before production. |
| Clustering and high availability | A clustered Wazuh server and indexer adds nodes, load balancers and replication settings. Each node carries its own operating and patching work. | Decide early whether a single node meets your availability target, and document the scale-out path. |
| Agent rollout across endpoints | Each endpoint needs an agent, enrollment, group policy and version control. Rollout effort grows with fleet size, mixed operating systems and offline segments. | Pilot in one group, use configuration groups and automated deployment tools, and track enrollment coverage against the asset inventory. |
| Compliance mapping | Your auditors may expect Sentinel's compliance content to be mapped to Wazuh's PCI DSS, GDPR, HIPAA or NIST 800-53 views, with evidence for each control. Gaps must be documented. | Agree the framework and control list before build, and reuse the existing control matrix as the mapping baseline. |
| Staff time and skills | Engineers must learn Wazuh rule syntax, indexer operations and upgrades, and analysts must learn new hunting and dashboard workflows. Parallel running adds effort. | Name owners for each stream, plan a parallel run period, and ask the partner to include knowledge transfer in the written scope. |
| Support and upgrades | Self-hosted Wazuh has no vendor-run service unless you buy one. Patch cadence matters: the 4.14 line has shipped several patch releases in 2026, so upgrades recur. | Ask whether the quote includes upgrade windows, patch testing and a support retainer, and who handles security advisories. |
What usually goes wrong when moving off Sentinel
Most failed Sentinel exits do not fail loudly. Sources stop sending, rules stop matching, history becomes unreadable and response steps quietly disappear. The cards below name the failure points that recur in Wazuh migrations and the check that catches each one before cutover.
Silent loss of a log source
A Sentinel data connector that was never listed in the inventory keeps working until the tenant is switched off, and a Wazuh replacement that is not configured simply shows no events. Build a source inventory from Sentinel's connected data sources and map each one to a Wazuh agent, a syslog listener or an API pull. Confirm that every source produces events in Wazuh for at least one full business cycle before decommissioning the Sentinel connector.
Detection gaps from unrewritten rules
KQL analytics rules do not translate line for line into Wazuh decoders and rules, so a rule that was never rewritten produces no alert and no error. Export the rule set, classify each rule by data source and intent, and write Wazuh rules with test events. Run the old and new detections in parallel and record which Sentinel alerts have no Wazuh counterpart.
Unqueryable historical data
Exported Sentinel history arrives as files, and files are not searchable until someone loads them into a store. Decide which history must stay queryable in the Wazuh indexer and which can stay as archived files. Test a sample export end to end by loading it, running the queries an investigation would need, and confirming that timestamps and fields still match.
Undersized indexer storage
The Wazuh indexer stores every alert and archived event on the disks you provision, and retention is whatever you configure rather than a default Microsoft applies. Size storage from measured daily volume, the retention period you actually need and index overhead, then confirm disk growth in a pilot. Set retention and disk alerts before go-live so the cluster does not fill during an incident.
Missed Logic Apps response actions
Sentinel playbooks often run quietly on incidents, for example to disable an account, tag a host or open a ticket, and nobody lists them as detections. Inventory every Logic Apps workflow attached to an automation rule and assign each one a Shuffle workflow or a manual procedure. Test each response action against a non-production asset before the playbook is turned off.
Agent version drift
Wazuh agents on endpoints run their own version, and a server upgrade can leave older agents unable to report or receive new rules. Record the agent version on every host, use the server's remote management for agent configuration and upgrades, and review the release notes for each patch release before upgrading. Patch releases in the 4.14 line have arrived roughly every one to two months, so schedule a recurring agent review.
Unmanaged licensing and retention assumptions
Wazuh is licensed under GPLv2, but the cost of running it sits in servers, storage, staff time and any support contract you buy. Teams often assume Sentinel's retention and billing rules carry over, and they do not. List the retention periods, compliance obligations and support terms in writing and ask any implementation partner to price them as separate line items in the quote.
How the move differs by starting point
A small security operations team that uses Sentinel mainly for Azure activity logs, Microsoft Entra ID sign-ins and a handful of built-in analytics rules usually has the smallest migration. The main job is to replace a short list of connectors with Wazuh agents and syslog collection, then recreate the rules that matter. Because the estate is narrow, parallel running for a few weeks is often practical, and the team can cut over once alert volumes look comparable.
- Connector inventory: List every enabled data connector and map each one to an agent, a syslog feed or an API probe.
- Rule triage: Most built-in analytics rules are tied to Microsoft products, so decide which ones still apply on the new platform before rewriting anything.
- Log history: Confirm how much history the auditors or incident responders need, since a short retention window keeps the export small.
- Playbooks: Count the Logic Apps playbooks in use, because a few notification flows are often the only automation to rebuild.
Before starting, confirm with your own SOC which connectors and rules are actually used, since unused ones can be retired rather than migrated.
An organization with many Azure subscriptions, several Log Analytics workspaces and a large body of custom KQL analytics rules faces a migration measured in rule counts and ownership, not just log flows. Each workspace may have different collection rules, and each custom rule may depend on a table or field that Wazuh does not expose in the same way. Sequencing by business unit or by workspace keeps the work manageable and gives each rule owner a clear test window.
- Workspace map: Document every workspace, its subscriptions, its sources and the teams that own its rules.
- Rule rewrite backlog: Export analytics rules and sort them by behavior, since many KQL queries translate to Wazuh decoders and rules only partially.
- Phased cutover: Move one workspace or one business unit at a time so that detection gaps are visible and limited.
- Dependency checks: Find workbooks, watchlists and automation that read from these rules before retiring them.
Ask your team to count custom rules per workspace and to flag any rule that depends on a Microsoft-only table, because those rules set the effort more than the log volume does.
A team that has already moved Sentinel into the Microsoft Defender portal has a different starting point. Retention and privacy settings are now governed by Defender XDR policies, and the Fusion analytics rule has been replaced by Defender XDR correlation. The migration therefore needs a clear record of which detections came from Sentinel and which now come from Defender XDR, because each set needs its own replacement plan.
- Policy baseline: Record the Defender XDR retention and privacy settings that apply to your data before exporting anything.
- Correlation split: Separate detections that Sentinel generated from those produced by Defender XDR correlation, since they will not map one to one onto Wazuh rules.
- Defender data sources: Decide which Defender telemetry Wazuh will need through agents or supported integrations and which will stay in Microsoft.
- Deadline awareness: Microsoft's published date for Azure portal support is March 31, 2027, so plan the migration against it.
Confirm with Microsoft's current documentation which Defender XDR data remains accessible for export, because access paths can differ from the Log Analytics tables you know.
Sites that cannot reach the internet, such as classified, operational technology or isolated research networks, cannot keep Sentinel at all because it runs only in Azure. For these sites the migration is a build project as much as a rule rewrite. Installation, software updates and vulnerability data must all come through an approved transfer path, and the team must plan this before deciding which sources to onboard.
- Offline installation: Follow the Wazuh offline installation guide and stage every package and dependency before the cutover window.
- Vulnerability data: Use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform, and set a process to refresh it.
- Agent coverage: Confirm which endpoints and devices can run agents and which need syslog or agentless monitoring.
- Export path: Plan how historical data moves across the boundary, since Sentinel exports go to Azure storage and must be carried over by an approved method.
Ask your security authority how media transfers and update approvals are handled, because those rules will set the sequencing more than any technical setting.
Questions buyers ask before moving off Sentinel
How much does it cost to move from Sentinel to Wazuh?
The move has one-time costs and recurring costs, and the recurring side usually decides the long-term picture. One-time costs cover planning, rewriting analytics rules, rebuilding playbooks, connector replacement and the parallel run. Recurring costs cover the servers or cloud instances that host the Wazuh indexer, server and dashboard, storage sized for your retention period, backups, patching, and the staff time to operate the platform. Wazuh itself is free under GPLv2, so no per-GB license fee replaces Sentinel's ingestion charges. Your Sentinel bill also has components to model: analytics ingestion, commitment tiers, retention beyond the included period and any data lake charges. Ask for a fixed-scope quote that lists each component, the daily ingestion volume it assumes and the number of rules and playbooks in scope. A separate page compares these costs component by component.
How long does a Sentinel to Wazuh migration take?
The pace is set by the size of your detection library, the number of data sources you must rebuild, the volume of history you need to carry over and how many playbooks depend on Logic Apps. Teams with a small set of analytics rules and a few connectors move faster than teams with hundreds of custom KQL rules and many cross-system workflows. Agent rollout across endpoints is often the slowest step because it depends on change windows and asset ownership. Retention requirements also matter, since they determine how much history must be exported and verified. DeployOpen agrees a timeline in the written scope before work starts, so ask for a phased plan with exit criteria for each phase, including the point where the parallel run ends.
What does the internal team need to contribute to a Wazuh migration?
Your team needs to supply decisions and access, not all of the build effort. Security engineering owns the detection content: they decide which KQL analytics rules still matter and validate the rewritten Wazuh rules against known events. Infrastructure or platform staff provide the hosting, network paths for agent and syslog traffic, certificates and identity integration. Asset owners approve agent deployment on endpoints and firewalls. Compliance leads confirm which evidence must be retained and for how long. Someone accountable for daily operations, such as alert triage and rule tuning, must be named before cutover, because Wazuh will not tune itself. Confirm these responsibilities in the scope so no one assumes another team owns them.
Can we run the Sentinel to Wazuh migration in-house?
Yes, many teams with strong Linux, detection engineering and infrastructure skills run the migration themselves. Wazuh publishes an all-in-one installation path, a prebuilt OVA, Docker, Kubernetes, Ansible and Puppet options, and an offline installation guide. The harder parts are usually rewriting detections, sizing the indexer and cluster correctly, designing retention and hardening the deployment. Consider an outside team if your staff are already committed to incident response, if you lack KQL to Wazuh rule translation experience or if an audit deadline is fixed. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and runs fixed-scope engagements with written deliverables. Ongoing support and upgrades are available as retainers.
How do we keep Sentinel history for audits after leaving?
Keep the original Sentinel data in a retained, read-only store that you control, and make sure the exported copy can be queried and verified. Use Sentinel's export options, such as data export rules to storage, to move logs out while the workspace is still active, and check that the exported files are complete for every table you must retain. Export your analytics rules as definitions as well, so you can show which detection logic was active on which dates. Record the mapping between old and new rules, and keep alert and case records alongside the logs. Wazuh stores its own alerts in the indexer, but it does not replace an export of Sentinel history. Confirm retention periods with your compliance lead and with the auditor who will review the evidence, because DeployOpen prepares controls and evidence but does not issue audit reports or certifications.
Can we turn off Sentinel during the parallel run?
You can usually stop active ingestion to Sentinel once every required source sends logs to Wazuh and the rewritten rules match the outcomes you expect, but you should not delete the workspace until the retention and audit checks pass. A parallel run lets both platforms receive the same events so you can compare alerts, catch missing sources and confirm that Wazuh decoders parse fields correctly. Before switching off ingestion, confirm that every data connector has a replacement, that syslog and API-based sources are verified, and that the export of history has finished. Keep read access to the old workspace for the agreed period so investigators can check past events. Ask for the exit criteria and the cutover date in writing before the parallel run starts.
How does Wazuh handle the Microsoft Defender portal change?
Wazuh is not affected by the Defender portal change, because it does not depend on Microsoft's portal. Microsoft says Sentinel will no longer be supported in the Azure portal after March 31, 2027, and will be available only in the Microsoft Defender portal. In the Defender portal, Defender XDR data privacy and retention policies apply instead of Sentinel's, and the Fusion analytics rule is replaced by Defender XDR correlation. If you are staying on Sentinel for now, these changes affect your retention and detection logic, so review them with Microsoft's transition guidance. If you move to Wazuh, the practical task is to rebuild the detections that relied on Fusion or Defender correlation as Wazuh rules and correlation logic, and to set your own retention in your own environment.
Which parts of the Sentinel setup need to be checked before we start?
Start with an inventory of what Sentinel does today, so the scope matches reality. List every data connector, every custom and scheduled analytics rule, every workbook and every Logic Apps playbook, along with its owner and the systems it touches. Note which sources send data through agents, syslog or APIs, because each needs a different Wazuh path. Confirm the daily ingestion volume and retention needs, and identify any Microsoft-only sources that have no Wazuh equivalent. Confirm Wazuh's compliance dashboards, such as PCI DSS, GDPR, HIPAA and NIST 800-53 views, cover the frameworks you report against. Use this inventory to request a quote with a clear scope.
How DeployOpen scopes and runs the Wazuh migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the Wazuh indexer, server, dashboard and agents. For a move off Microsoft Sentinel, the work is agreed in writing first, then built, tested and handed over in stages so detections and evidence carry across without a gap.
How we scope
- Inventory every Sentinel data connector, analytics rule, workbook and Logic Apps playbook in the current workspace.
- Agree which log sources move to Wazuh agents, syslog collection or agentless API probing, and which stay in Microsoft.
- Confirm the export path for history, including export jobs or data export rules, and who owns the exported data.
- Write deliverables, timelines and acceptance criteria into a fixed-scope agreement before any work starts.
How we build
- Deploy the Wazuh components in your cloud accounts, data centers or air-gapped network using the method your environment requires.
- Rewrite KQL analytics rules as Wazuh decoders and rules, then test each one against replayed or sample events.
- Replace Logic Apps playbooks with Shuffle workflows triggered by Wazuh alerts, with connectors you have approved.
- Harden the deployment, configure access controls and single sign-on, and test detections before cutover.
How we hand over
- Document the architecture, data flows, rule catalog, mapping from each Sentinel rule to its Wazuh equivalent, and known gaps.
- Provide runbooks for agent enrollment, rule changes, upgrades and backup and restore of the Wazuh indexer.
- Record which Sentinel detections were retired, replaced or left open, so your team can decide on the remaining items.
- Prepare compliance evidence for the controls you need to show, while noting that independent auditors and certification bodies issue any attestation.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Plan Wazuh patch upgrades from the release notes so your team can schedule maintenance windows in advance.
- Re-test detections after upgrades or new log sources, and update documentation to match the running system.
- Scope additional work, such as new integrations or rule sets, as a separate written agreement.
