Graylog migration from Splunk or ELK

What a Graylog migration involves

A Graylog migration is not a data copy. Moving from Splunk, an ELK stack or an older Graylog release means moving log sources, parsing logic, searches, dashboards, alerts and access into Graylog, and each of those has to be inventoried, rebuilt in Graylog terms and checked against the original. Historical data is usually the smallest part of the work. Most teams move for one of a few reasons: a licensing change, the cost of daily volume, consolidation of several log platforms, leaving an unsupported version, or moving from self-managed OpenSearch to Data Node.

Teams with Graylog experience and a small estate often do this in-house. Teams with many sources, regulated retention rules or a hard cutover date usually bring in a partner for the inventory, the parsing rebuild and parallel running. The inventory is the step most often underestimated. Confirm every shipper, forwarder and alert consumer, including ones nobody on the current team set up. Then decide, per source, whether the old parsing is rebuilt as processing pipeline rules or simplified.

The target edition only changes the migration scope where a feature is needed. Graylog Open is licensed under SSPL-1.0 and is free with no volume limits. Graylog Enterprise and Graylog Security are subscriptions priced on processed data. If you depend on archive restore or single sign-on through Okta, OpenID Connect or SAML, plan those as explicit work items and confirm the edition that includes them on the current Graylog pricing page before scoping.

What the work includes

Each work package ends in a deliverable you keep. Parsing and alerts are checked against live sources before the old platform is switched off.

Source inventory and field mapping

List every log source, forwarder, index or sourcetype, saved search, dashboard and alert in the current platform, with its daily volume and owner. The field and parsing map records how each source field lands in Graylog, which fields are dropped and which are renamed. Include retired sources too, since they often hold the history you still need to keep.

Target Graylog and Data Node build

Build the Graylog server nodes, MongoDB and a Data Node cluster in your infrastructure, sized from daily ingest and retention using Graylog's planning guidance. Define index sets per log type before traffic moves. If the current platform runs self-managed OpenSearch, moving that storage to Data Node is a separate work package with its own validation. Deliverable: build record and sizing worksheet.

Re-pointing shippers to Graylog inputs

Move each forwarder to a Graylog input that matches its protocol: syslog, GELF or Beats. Confirm message format, timestamps, time zone handling and TLS settings on each input before switching a source over. Keep the old destination configured for a rollback window so a forwarder can return without a redeploy. Deliverable: shipper change log and exported input configuration.

Parsing rebuilt as pipeline rules and extractors

Each parser from the old platform is rebuilt as a Graylog extractor or processing pipeline rule and tested against sample messages from the source. Plan on manual rebuilding, since no automated conversion of parsers is assumed here. Lookup tables replace enrichment that previously ran in the old platform. Deliverable: parsing test set with expected field output for each source.

Searches, dashboards and event definitions

Saved searches and dashboards are translated into Graylog queries and widgets, and alerts are recreated as event definitions with the same thresholds, lookback windows and owners. Notifications to PagerDuty, Slack and email are configured and each event definition is fired with a test event. Deliverables: rebuilt dashboard set and alert test log showing each notification delivered.

Parallel running, cutover and decommissioning

Both platforms receive the same sources for an agreed period, and the team compares event counts, field values and alert behavior between them. Cutover follows a runbook with defined go and rollback criteria. After cutover, the old platform's retained data is exported under your retention policy and its agents and licenses are removed. Deliverables: validation report, cutover runbook and decommissioning record.

What drives migration cost and duration

This table lists the migration drivers that change effort, cost and schedule, with how each one affects the work and how to keep it under control.

Driver	Why it matters	How to keep it down
Log sources and shipper types	Each source type needs an input or parser, and every forwarder must be re-pointed to Graylog inputs.	Group sources by shipper type and move one group at a time. Retire duplicate or unused forwarders during the inventory.
Daily volume and retention	Daily ingest drives storage and edition. Enterprise and Security have a 10 GB per day or 100 Graylog Compute Unit minimum, per Graylog's pricing page.	Measure processed volume per source over a representative period. Drop debug noise and agree retention per index set before sizing.
Searches, reports, dashboards and alerts	Each Splunk search, saved report, Kibana dashboard, ELK visualization and alert needs a Graylog equivalent, such as an event definition.	Rebuild items used recently, consolidate similar dashboards into templates and retire the rest.
Parsing and enrichment complexity	Custom field extraction, Logstash filters and enrichment lookups must be rebuilt as extractors, pipeline rules and lookup tables.	Inventory parsers by log type and reuse grok patterns. Test rules on sample messages before production traffic.
Downstream alert consumers	Ticketing, SOAR and SIEM integrations depend on alert payloads and delivery paths that must be confirmed after the move.	List every consumer and its expected format. Send a test event to each one before retiring the old path.
Data Node or self-managed OpenSearch	OpenSearch 1.x has been deprecated since Graylog 7.0 and will be removed in Graylog 8.0, so an older cluster forces a storage change.	Graylog recommends Data Node. Plan the storage change in the same project and check the compatibility matrix for your target version.
Searchable history or archive only	Searchable history needs index capacity on the new cluster. Archiving reduces that need but adds restore steps, and archive restore is an Enterprise feature.	Decide per index set which data must be searchable. Move only what active investigations or audits need.
Environments and compliance evidence	Each environment repeats the build, and assessors may ask for configuration history and retention settings.	Build once from content packs or scripted configuration. Confirm evidence requirements with your assessor before the build starts.
Edition choice	Graylog Open has no volume limit but community support. Enterprise and Security add 24/7 support and features your rules may need.	Choose the edition from measured volume and the features your rules require. Ask for a quote based on the written scope.

Migration phases and outputs

The sequence moves log collection, parsing, searches and alerts to Graylog in controlled stages, with a written output and sign-off at each one.

Inventory sources, searches and alerts
Your team and ours list every log source, its daily volume, the searches, dashboards and alerts that depend on it, and the owner of each. Output: a source inventory signed off by log owners. The schedule depends on this inventory, so confirm its scope in writing before the build starts.
Design the target environment
We document the target design: the Graylog version, the MongoDB and Data Node topology, index sets and retention per data type, and the input layout. We recommend the current 7.x line, since OpenSearch 1.x use is deprecated from Graylog 7.0 and will be removed in Graylog 8.0. Output: an approved design document.
Build the target environment
We install Graylog server nodes, MongoDB and Data Node in infrastructure you control, configure inputs, index sets, streams and access roles, and apply the agreed TLS and access settings. Output: a working target cluster with a build record that lists versions, configuration and open items.
Rebuild parsing and searches with test messages
Each parser is rewritten as pipeline rules, then tested against sample messages exported from the source platform. Searches, dashboards and event definitions are recreated and compared with the originals. Output: a test report per source showing matched fields, with log owners confirming that the extracted values are correct.
Run both platforms in parallel
Shippers send the same logs to the old platform and to Graylog for an agreed period. We compare event counts, field values, alert behavior and search results between the two. Output: a parallel-run report listing gaps, their causes and fixes, and the date each gap was closed.
Validate and cut over with a rollback plan
Log owners and security sign off on validation results. Shipper configurations are then changed to send only to Graylog, with a written rollback procedure for each source. Output: signed validation records, updated shipper configurations and a cutover log showing each source's switch time and check results.
Decommission the old platform and keep evidence
After the agreed retention window for the old platform closes, we shut down its ingestion and remove access, then archive exported configurations, validation records and cutover logs. Output: a decommissioning record and an evidence package that your auditors can review. Confirm retention requirements with your compliance team before this step.

What teams keep in-house and what they outsource

This table shows which migration tasks usually stay with the internal team and which a partner typically carries, with the skills each side needs. The exact split is agreed in writing before work starts.

Work part	Usually kept in-house or outsourced	Skills needed
Owning the log sources and their meaning	In-house. The internal team confirms what each source emits and what each field means.	Knowledge of the current platform's field semantics, application owners and log formats
Approving field mapping and retention	In-house decision, with the partner drafting the proposal	Data governance, compliance and records retention requirements
Shipper configuration on servers and devices	Shared. The internal team usually controls change windows and access; the partner can prepare configuration.	Syslog, Beats and agent administration across the estate
Building the Graylog target and Data Node cluster	Typically outsourced, with internal review of the infrastructure design	Linux administration, MongoDB, Graylog and Data Node deployment and clustering
Rebuilding parsing as pipeline rules and extractors	Typically outsourced, with internal sign-off on parsed output	Graylog pipeline rules, grok, JSON parsing and regular expressions
Translating dashboards and alerts	Shared. The partner rebuilds them; owners decide which ones still matter.	Graylog dashboards, event definitions and notification setup
Validating alert behavior with on-call teams	In-house. On-call teams confirm thresholds, routing and noise levels.	Operational knowledge of incidents and escalation paths
Load and sizing checks	Typically outsourced, with internal input on peak volumes	Ingest rate analysis, index sizing and cluster capacity planning
Cutover coordination and retained-evidence handover	Shared. The internal team owns business approval and the partner prepares runbooks and evidence.	Change management, rollback planning and evidence retention practices

What usually goes wrong and how to prevent it

Most migration failures are quiet. Logs keep arriving and searches keep running, and nothing looks broken until a dashboard, alert or audit request depends on what was lost or changed. The checks below catch these problems before the old platform is switched off.

Field names change silently

Source systems and Graylog extractors often name the same value differently, so a dashboard or alert keyed on an old field name can stop matching without raising an error. Before cutover, build a field map from each source to its Graylog name and have the owners of each dashboard and alert sign it off. Then check that every saved search and event definition references only mapped fields.

Parsing rules miss edge-case formats

Pipeline rules and extractors are usually tested against the common message shape, while rare variants such as multiline stack traces, legacy device output or truncated lines pass through unparsed. Export a representative sample from each source, including known edge cases, and replay those test messages through the pipeline before live traffic moves. Track unparsed messages per stream and treat any new unparsed variant as a failed check.

Search syntax changes results

Splunk SPL, Kibana Query Language and Lucene queries have different syntax and defaults from Graylog search, so a translated search can return different counts without warning. Common traps include wildcard behavior on fields, default time ranges and how values are tokenized. Run each migrated search over the same time window in both platforms and compare counts before retiring the original.

Alerts recreated without thresholds or history

Event definitions are often rebuilt from memory, which drops thresholds, grouping keys, notification targets and the context that made the old alert useful. The result is alerts that fire on every match or never fire at all. Export the old rules, record their thresholds and recipients, then run an alert test log that replays known incidents and confirms each event definition triggers or stays quiet as expected.

Retention shorter than policy

Retention is set per index set, and Graylog Open deletes the oldest indices once the limit is reached. If retention is shorter than the written policy, or old logs were never exported, that history is gone once the old platform is retired. Agree the archive or export path before decommissioning, and if you move from self-managed OpenSearch to Data Node, rebuild retention on the new cluster.

Cutover without rollback or parallel run

Repointing forwarders to new Graylog inputs in one step leaves no way back if messages stop arriving. Keep the old forwarder configuration ready, cut over one source group at a time, and run both platforms side by side for an agreed window. Confirm message counts match per source before the old destination is removed. Skipping the parallel run removes the main evidence that nothing was lost in transit.

How the migration changes by starting point

Splunk migrations change most at the search layer. Saved searches, macros, lookups and field aliases are rebuilt by hand in Graylog's query language and pipeline rules. Collection is simpler to re-point than search.

Forwarders: Universal and heavy forwarders are re-pointed at Graylog inputs such as syslog or GELF, and sourcetype-based parsing is rebuilt as pipeline rules.
Search and knowledge objects: Each search, macro and tag is rewritten and tested against the same sample events before it is trusted.
Retention: Splunk index settings do not carry over automatically. Confirm how long each data type must be searchable in Graylog and whether older data stays in Splunk during overlap.
Confirm with the environment owner: which sources and sourcetypes are in scope and who owns each saved search and alert.

What you need to provide

Before design starts, give the migration team read-only access to the source platform, whether Splunk, an ELK stack or an older Graylog. That access is used to inventory and export saved searches, dashboards and alert definitions, which become the baseline for what must be rebuilt. Export formats differ by source, so ask the team to confirm which objects can be exported in bulk and which must be recreated by hand. Keep a written list of everything exported and everything excluded.

Next, provide an inventory of log sources with a named owner for each source and an approximate daily volume. Sample messages for every source type should include the edge cases your teams already know about, such as multi-line stack traces, malformed records and sources whose format changed after an upgrade. These samples drive the grok, JSON and extractor work in pipeline rules, so vague samples lead to rework. Also state retention periods and any legal hold requirements, because they determine index sets and whether historical data moves at all.

Confirm target hosting, network paths and certificate decisions, including which TLS certificates the inputs and web interface will present. Name an owner for each log source who can approve field mapping, and secure a change window with rollback approval from your change board. Give the migration team access to the shipper estate, including forwarders, agents and syslog senders, so each one can be re-pointed to a Graylog input. Agree in advance who signs off the cutover and who can authorize a reversion.

Three decisions should be made before design begins because they change the architecture. The first is the edition: Graylog Open or a paid tier, since Enterprise and Security add features that some pipelines may depend on. The second is the search backend. Graylog recommends Data Node, and OpenSearch 1.x has been deprecated since Graylog 7.0 and will be removed in Graylog 8.0, so an existing OpenSearch 1.x cluster needs a plan. The third is history handling: whether old data is migrated, kept in the source platform for reference, or allowed to expire. Record these choices with the owners so design starts from a fixed baseline.

Frequently asked questions

How long does a Graylog migration from Splunk or ELK take?

The duration depends on your inventory, and the written scope fixes the timeline before work starts. The main drivers are the number of log sources and shippers to re-point, the daily volume and retention you carry over, and how many parsers, dashboards and alerts must be rebuilt as pipeline rules, lookup tables and event definitions. Validation requirements from your security or compliance team also add time. Teams often run old and new platforms in parallel for a defined period, so the dual-run length, cutover criteria and rollback steps belong in the scope too. We confirm the inventory first, then agree the timeline in writing.

How much does a Graylog migration cost and what does the quote include?

The quote follows from the written scope, and DeployOpen does not publish a price list. Two cost lines matter. The first is the services to inventory, rebuild, test, cut over and hand over the migration. The second is the Graylog licence and infrastructure. Graylog Open is free with no volume limits and community support. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, according to Graylog's pricing page. Ask for a quote that lists sources, pipelines, dashboards, alerts, data transfer, testing and the handover package, and separates one-time work from recurring support.

Can our own team migrate to Graylog without an implementation partner?

Yes, for a small estate where your team already runs Graylog well. A migration with a few sources, a limited set of dashboards and no audit evidence requirement can usually be done in-house if the team covers these skills: Graylog server and MongoDB administration, Data Node or OpenSearch operations, grok and JSON parsing, processing pipeline rules and testing, shipper configuration for syslog, GELF or Beats, event definitions with notification routing, and role-based access to streams. Larger estates, several log types or formal evidence needs often benefit from a partner who works alongside your operations team.

Can historical logs move from Splunk or ELK into Graylog?

Bulk transfer of history depends on the export formats your source platform produces, so confirm this with the vendor before the scope is written. Graylog stores data in index sets with rotation and retention, so migrated history needs its own index set and a defined retention period. Many teams keep older data in the source platform or in archive storage for the retention window and move only the events needed for active investigations. Graylog Enterprise adds a data lake with archive restore and data tiering, which is worth evaluating if restore is required. Confirm export format, volume, timestamp accuracy and field mapping with your compliance owners.

Do Splunk searches and dashboards convert to Graylog automatically?

No. Searches, dashboards and alerts are rebuilt in Graylog and validated against sample logs and expected results. Query languages, field names and parsing differ between platforms, so saved objects cannot be carried over as they are. Start by inventorying every saved search, dashboard panel, scheduled alert and report, then decide with each owner which ones still matter. Each retained item is recreated as a Graylog search, dashboard widget or event definition, tested against historical events and signed off by its owner. Keep the original queries in the inventory so reviewers can compare results.

What happens to our OpenSearch 1.x deployment during a Graylog migration?

OpenSearch 1.x use with Graylog has been deprecated since Graylog 7.0 and is scheduled for removal in Graylog 8.0, so plan to move off it as part of this migration. Graylog recommends Data Node as the search backend. The plan should cover a new Data Node cluster, recreated index sets, transfer of any history you keep and a check of MongoDB and Graylog versions against the compatibility matrix for your target release. Confirm your current Graylog and OpenSearch versions first, since they set the upgrade path and the order of steps.

How DeployOpen runs Graylog migrations

DeployOpen plans and carries out Graylog migrations inside your own infrastructure, moving log collection and searches from Splunk, an ELK stack or an older Graylog release onto a Graylog version you choose. The work follows a written scope, a staged build and a handover your team can run without us.

How we scope

The written scope lists each source moving to Graylog, its current shipper and the Graylog input that will receive it.
We inventory existing Splunk searches, ELK parsing, dashboards and alerts, and mark which ones are rebuilt, retired or left in place.
We confirm the target Graylog version, MongoDB version and search backend, Data Node or self-managed OpenSearch, against the Graylog compatibility matrix before work starts.

How we build

Shippers are re-pointed to Graylog inputs such as syslog, GELF or Beats in a staging environment before any production traffic moves.
Parsing from Splunk props or ELK pipelines is rebuilt as Graylog processing pipeline rules, tested against sample messages from each source.
Dashboards and alerts are recreated as Graylog dashboards and event definitions, with notification targets confirmed and test events run end to end.

How we hand over

Deliverables include a source-to-input map, pipeline rule documentation, index set and retention settings, and a record of each rebuilt alert.
Runbooks cover adding a log source, rotating indices, checking the message journal and restoring Graylog configuration from MongoDB backups.
We walk your operations and security staff through the environment and agree the written acceptance criteria before the engagement closes.

How we support

Engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before the migration begins.
Ongoing support, Graylog upgrades and continuous testing are available as a retainer after handover.
Ask any quote to state which items are one-time migration work and which recur, such as upgrades and support.

Graylog migration from Splunk, ELK or an older Graylog