Microsoft Sentinel is unusual among SIEMs in that most people leaving it are not unhappy with the product. They are unhappy with a bill that grows every time a network team turns on verbose logging. Pay-per-gigabyte ingest means cost tracks log volume rather than estate size or team size, and the sources that generate the most volume, firewall traffic, proxy, DNS, verbose application logs, are usually the ones with the lowest alerts-per-gigabyte ratio in the entire platform. Graylog is the standard destination for exactly that traffic: a mature, self-hosted log-management platform that is very good at ingesting enormous volumes cheaply.
The most important thing in this guide is therefore a warning: for most organisations, the right migration is partial.
Do the value-per-gigabyte analysis first
Before any architecture, produce one table. For each connector and log source in your workspace, put the monthly ingested gigabytes next to the number of analytics-rule detections that source has contributed to in the last year.
The distribution is almost always extreme. A handful of sources, Entra ID sign-in logs, Defender alerts, audit logs, produce very little volume and almost all detections. A handful of others produce most of the volume and have never appeared in a rule that fired. That table is your migration plan: the bottom of it moves to Graylog, the top of it stays in Sentinel, and the middle gets argued about with the detection engineers who own those rules.
This is also the analysis that tells you whether to migrate at all. If your bill is dominated by Microsoft-native telemetry, Graylog will not help, because reproducing those connectors is work you do not want and the volumes are small anyway. If your bill is dominated by network and application logs shipped in via syslog or the Logs Ingestion API, the saving is substantial and the engineering is straightforward.
Evaluate the cheap tiers before you build anything
Microsoft has introduced lower-cost ingestion tiers aimed precisely at high-volume, low-signal data, with reduced query capability and different retention semantics in exchange. Price your specific source mix against them honestly.
If moving your top three volume sources to a cheap tier gets the bill to something acceptable, that is a better outcome than standing up and operating a Graylog cluster, and you should take it without ego. Migrate when the tiering does not get you there, when the query restrictions break how you actually use that data, or when you want the data somewhere Microsoft does not meter it at all. Confirm current tier behaviour with Microsoft rather than any secondary source, including this page, because these tiers have changed more than once.
The mapping
- Azure Monitor Agent / AMA data collection rules → Graylog inputs (Syslog, Beats, GELF, or the HTTP API).
- Log Analytics workspace tables → Graylog streams, one per logical source, with routing rules.
- KQL parsing and ASIM normalization → Graylog extractors and pipeline rules, applied at ingest.
- Analytics rules → Graylog event definitions (search condition, aggregation, threshold).
- Watchlists → Graylog lookup tables.
- Workbooks → Graylog dashboards.
- Logic App playbooks → external automation (Shuffle, StackStorm, or your existing orchestration), triggered by Graylog notifications.
- Archive and long-term retention → Graylog archiving to object storage.
Where the engineering effort actually goes
Not into detections. Into parsing.
Sentinel connectors arrive with normalization done: the ASIM schema and the built-in parsers mean a firewall log from one vendor looks structurally like a firewall log from another, and analytics rules are written against that consistency. Graylog gives you extractors and pipeline rules, and you write them. For a handful of well-behaved syslog sources this is an afternoon. For an estate with a dozen appliance vendors each emitting its own dialect, it is the bulk of the project.
Two things make it manageable. First, do parsing in pipeline rules rather than extractors wherever the logic is non-trivial, because pipeline rules are testable, version-controllable, and composable in a way extractors are not. Second, only parse fields you will actually search or alert on; the temptation to reproduce full ASIM normalization for a source that nobody queries is how a two-week task becomes a two-month one.
Sizing and the storage reality
Graylog runs on OpenSearch or Elasticsearch, so the cost you removed from an ingest meter reappears as disks, nodes, and someone to look after them. That trade is still strongly favourable at high volume, which is exactly why you moved the high-volume sources, but it is a trade and not a free lunch.
Size on daily indexed gigabytes and required hot retention. Put hot indices on fast storage. Configure index rotation and retention on day one, and use Graylog’s archiving to push aged data to object storage rather than keeping everything hot because nobody set a policy. And be realistic that a multi-terabyte-per-day Graylog deployment is a platform with an on-call rotation, not an appliance.
Order of operations
- Build the value-per-gigabyte table and evaluate Sentinel’s cheap tiers against it.
- Draw the boundary: which sources stay in Sentinel, which move, and which get summarised into Sentinel from Graylog.
- Stand up Graylog, sized for the moving sources, with retention and archiving policies configured before the first log arrives.
- Re-point one source, write and test its pipeline rules, and confirm searches return what analysts expect.
- Dual-ship that source to both platforms for a billing cycle, so you can prove the Graylog copy is complete before you stop paying for the Sentinel copy.
- Rebuild only the detections that used the moved sources, as Graylog event definitions, and wire notifications into your existing response path.
- Repeat per source, stopping Sentinel ingestion for each one only after its Graylog copy is validated.
- Recheck the bill after each source, because the whole justification is a number you can watch move.
Clearing the bar before you cut over
Per source: the Graylog copy contains every event the Sentinel copy did over an overlapping window, parsed fields match what analysts search on, detections that used that source fire correctly in their new home, retention meets the documented obligation, and the ingest reduction shows up on the Azure bill. Only then stop the Sentinel data collection rule for that source.
The short version
Sentinel to Graylog is best understood as ingest triage rather than a platform migration. Move the volume, keep the signal, and be genuinely open to the possibility that Sentinel’s own cheaper tiers solve your problem with less work. Where Graylog wins is on high-volume, low-signal data at scale, where per-gigabyte pricing is simply the wrong shape for the workload. Model the illustrative economics in the calculator above, count the OpenSearch cluster and its operator as real costs, and validate every source with a dual-ship overlap before you turn the meter off.