Why a Graylog backend move from Elasticsearch to OpenSearch is time-bound
If your Graylog still stores logs in Elasticsearch, the search backend must move before Graylog 8.0 removes support. Graylog 7.0 deprecates Elasticsearch and names Data Node and self-managed OpenSearch as the preferred search backends, so the window for a planned move is the 7.x line. The move is a change to the search backend only. The Graylog server nodes and MongoDB, which hold configuration and metadata, are separate concerns that you can keep running, upgrade or redesign on their own timeline.
Effort depends on three things: how much data sits in your indices, how much disk the Graylog nodes have for the message journal while the search backend is down, and how much downtime your log sources and analysts can tolerate. The journal is the buffer that holds incoming messages when Graylog cannot write them to the search backend, so a full-cluster restart needs enough journal space to absorb everything that arrives during the switch. Ask your team to measure current daily ingest, retention in days and free space on each Graylog node before choosing a method. The Graylog OpenSearch upgrade methods documentation describes the options and their journal requirements.
Also confirm which Graylog version you run today, because the path differs for 6.x and 7.x installations and the target backend decides how much of the work repeats later. Note that OpenSearch 1.x is deprecated from Graylog 7.0 and will be removed in Graylog 8.0, so an in-place OpenSearch upgrade may be needed as well. Record the answer to the question of whether you are moving to OpenSearch now and to Data Node later, or going to Data Node directly, because that choice sets the order of your change windows.
Which parts of an Elasticsearch-backed Graylog map cleanly to OpenSearch
This table compares the Graylog features your current Elasticsearch-backed deployment relies on with their OpenSearch counterparts and migration notes. Read each row as a checklist: the Graylog-side objects usually carry over, while security configuration, Kibana content and version-specific behavior need to be verified before cutover.
| Capability | Elasticsearch-backed Graylog today | OpenSearch equivalent and migration note |
|---|---|---|
| Index sets and rotation | Index sets, rotation by message count, size or time, and retention that deletes the oldest indices | Index sets are Graylog objects, so they carry over with the backend. Confirm rotation and retention settings after cutover and check index data is readable from the new cluster. |
| Streams and pipelines | Streams route messages and processing pipelines transform them inside Graylog | Stored in Graylog and MongoDB rather than the search backend, so they do not change with the backend swap. Export and review them before the switch anyway. |
| Dashboards and saved searches | Dashboards and searches are defined in Graylog, rendered by Graylog's own interface | Graylog content is not Kibana content. Kibana objects do not carry over, so any dashboards built in Kibana must be rebuilt or rechecked. |
| Users, roles and authentication | Graylog roles, plus any Elasticsearch security realms used for the backend | Graylog users and roles stay in Graylog. Elasticsearch security realms, roles and users must be recreated in the OpenSearch Security plugin and verified. |
| TLS for node and client traffic | TLS configured on the Elasticsearch cluster and Graylog connection settings | Configure TLS in the OpenSearch Security plugin and update Graylog connection settings. Certificates are not copied automatically. |
| Snapshots and restore | Snapshot repositories holding Elasticsearch indices | Snapshot restore into OpenSearch depends on the source version. Confirm supported restore paths for your exact Elasticsearch release before relying on them. |
| Compatibility and version | Graylog pinned to Elasticsearch-era dependencies | OpenSearch is a fork of Elasticsearch 7.10 and is wire-compatible with it. Check the Graylog compatibility matrix for your target Graylog and OpenSearch versions, and confirm Graylog Security requires OpenSearch 2.0 or later. |
Full-cluster restart, rolling restart or snapshot restore: choosing a method
Downtime is usually the first constraint to settle. A full-cluster restart stops the search backend for the duration of the switch, so Graylog cannot write to or search its indices while OpenSearch is installed in place of Elasticsearch. A rolling restart keeps the cluster available by replacing nodes one at a time, which trades a longer window of mixed versions for continuous search. A snapshot restore into a new cluster lets the old cluster keep serving until cutover, which moves the downtime to a short switch at the end.
- Full-cluster restart: search and indexing stop for the whole switch, so the journal becomes the only place new messages are held.
- Rolling restart: search stays up, but the cluster runs mixed versions for part of the window.
- Snapshot restore: the old cluster keeps running until the new one is validated and Graylog is pointed at it.
- Log sources: confirm whether inputs can be paused or whether they must keep sending during the window.
Before choosing, confirm with the Graylog 5.2 OpenSearch upgrade methods page how each method behaves for your Graylog version, since the procedure details and supported paths are version-specific.
The message journal on each Graylog node is the buffer that holds incoming messages when the search backend cannot accept them. Graylog's documentation states that a full-cluster restart needs enough disk on Graylog nodes to hold all incoming messages in the journal while OpenSearch is installed. The size of that buffer depends on how long the switch lasts and on your daily ingest rate, so the journal sizing in your own environment is the number to work out before scheduling anything.
- Journal capacity: calculate the expected switch duration multiplied by peak ingest, then add margin, and check it against the journal limit configured on each node.
- Rolling and snapshot methods: the journal load is lower because the search path stays available, but it is not zero during node replacement or cutover.
- Disk on data nodes: the Elasticsearch data disks also need room for snapshots or temporary copies if you take that route.
- Overflow behavior: confirm what Graylog does when the journal fills, because that decides whether messages are dropped or sources are throttled.
Confirm the journal guidance and disk requirements for your Graylog version on the 5.2 upgrade methods page and in the system architecture guidance before you commit to a window.
Cluster size changes how practical a rolling restart is. A rolling restart works node by node, so the number of data nodes, their shard allocation and replica settings determine how long the cluster runs in mixed state and whether replicas can absorb a node being taken out. Elasticsearch documentation notes that a highly available cluster needs at least three master-eligible nodes, and that role separation affects how safely nodes can be replaced. A small single-node or two-node cluster leaves little room to rotate nodes without losing availability.
- Node count and roles: list master-eligible, data and ingest nodes, since each role changes the rotation order.
- Replica settings: a rolling replacement depends on replicas being healthy before each node leaves.
- Index volume: many large indices lengthen shard relocation and recovery time after each node restarts.
- Single-node clusters: a full-cluster restart is often the simpler path when there is no second node to rotate.
Ask the Graylog and OpenSearch documentation for the rolling procedure that matches your Elasticsearch version, and test your replica and shard layout in a staging copy first.
The snapshot route needs a second cluster that can receive a copy of your indices. It keeps the production cluster untouched until the new OpenSearch cluster has been loaded, checked and connected to Graylog. This suits organizations with spare capacity, a regular snapshot repository already in place, or a need to validate the new backend before any production write moves. The cost is extra infrastructure for the duration of the project and a cutover step that must be rehearsed.
- Spare capacity: the new cluster must hold the restored indices plus room for new writes.
- Snapshot repository: confirm that a shared repository is reachable from both clusters and that its access is controlled.
- Cutover: plan how inputs and Graylog's connection are switched, and how writes received during the copy are reconciled.
- Rollback: keep the original cluster available until the new one has passed checks.
Confirm the snapshot procedure, supported OpenSearch versions and compatibility limits on the 5.2 upgrade methods page before you size the second cluster.
Graylog documents the full-cluster restart as the recommended method for most users, so it is the default to test against your constraints. Choose a rolling restart when search must stay available and your cluster has enough nodes and replicas to rotate safely. Choose a snapshot restore when you can run a second cluster and want the old backend to stay live until validation is complete. Make the decision on written answers to the questions below rather than on preference.
- Downtime window: the longest acceptable interval for searching and for sources that cannot buffer.
- Journal math: expected switch length, peak ingest and configured journal size per node.
- Cluster facts: node count, roles, replica settings and shard counts.
- Infrastructure: whether a second cluster and a shared snapshot repository are available.
- Version path: the Graylog and OpenSearch versions you will run, checked against the 5.2 upgrade methods page and the Graylog 7.0 upgrade notes.
Record the chosen method and its checks in your change plan, and confirm each step with the Graylog documentation for your exact versions before work starts.
How much journal disk the switch needs
A full-cluster restart is the documented method most users take, and it needs enough disk on each Graylog node to hold every incoming message in the message journal for as long as OpenSearch is being installed and the cluster is unavailable for indexing. Graylog buffers messages on disk while the search backend is down, so the journal, not the search cluster, is what determines whether you lose logs during the window. Size the journal before you schedule the switch, not after the first node goes offline.
To estimate the window, multiply your daily ingest rate by the number of days you expect the backend to be unavailable, then add headroom for bursts and for the time needed to replay the backlog once indexing resumes. Your expected work duration should cover OpenSearch installation, the Graylog configuration change, a test of search and index rotation, and a rollback allowance. The Graylog system architecture page advises giving the message journal 3 to 5 times daily ingest on SSDs, which is a planning ceiling for storage rather than a measured requirement for your switch. Ask your team to confirm the ingest figures from a recent period that includes peak days, because an average understates the backlog during a busy week.
Check the journal settings on each Graylog node against your own ingest pattern before the cutover, and confirm the disk has room for the backlog on every node, since each node journals its own inputs. Pay particular attention to the maximum journal size and the age and volume limits configured in graylog.conf, and make sure the disk alarms you rely on will fire before the journal fills. If the calculated window does not fit the available disk, shorten the work window, stage the change across a maintenance period with lower ingest, or review the Graylog operations and troubleshooting guidance before committing to a date.
Sequence for moving the backend with a parallel run and cutover
This sequence moves a Graylog search backend from Elasticsearch to OpenSearch in a controlled order, so each stage produces evidence that the next stage depends on. It ends with Elasticsearch decommissioned and a documented rollback path that stayed available until the cutover was confirmed.
Inventory indices, streams and configuration
The Graylog administrator and the platform owner record every index set, its rotation and retention settings, the streams and processing pipelines that route into them, event definitions, users and roles, input configuration, and the TLS certificates used by the Elasticsearch nodes and Graylog. Compare the stored index counts and sizes against the cluster status before anything changes. The step is done when the inventory is signed off and every item has an owner and a documented purpose, so nothing is discovered missing during cutover.
Confirm the cutover method and rollback point
Choose between the full-cluster restart, the rolling restart and the new-cluster-from-snapshot method, using Graylog's documented options as the baseline. Graylog recommends the full-cluster restart for most users, but it needs enough disk on Graylog nodes to hold all incoming messages in the journal while OpenSearch is installed. Write down who can trigger rollback, which snapshot or backup is the restore point, and the conditions that trigger it. The step is done when the decision and rollback criteria are approved in writing before any production change.
Build a pilot on a non-production copy
The platform team restores a recent snapshot of indices and configuration into a non-production Graylog and OpenSearch environment, then runs the full cutover procedure against it. They check that the index sets resolve, pipelines process sample messages as before, dashboards load, and the Graylog server starts cleanly against the new backend. Record every deviation, including version or plugin mismatches. The step is done when the pilot completes without unresolved issues and the runbook has been corrected from what the pilot revealed.
Run the parallel validation window
The length and form of the parallel run depend on the chosen method. With a new cluster restored from a snapshot, the old and new backends can run side by side while the team compares search results, message counts and alert firing for the same sources. With a full-cluster restart, there is no true parallel backend, so validation relies on the pilot results, the snapshot and a closely watched post-restart check. Confirm the window length with your own risk owners. The step is done when comparison results match expectations or each gap is explained and accepted.
Execute the cutover under the agreed method
The operator stops ingest where the method requires it, takes a fresh snapshot, performs the restart or restore steps in the documented order, and reconnects Graylog to OpenSearch. Journal usage is watched throughout, since incoming messages buffer on Graylog nodes while the search backend is unavailable. Logs of each action are kept with timestamps. The step is done when Graylog reports the backend healthy and the first inputs are indexing into OpenSearch, or when the rollback criteria are met and the team has reverted.
Check search, dashboards and alerts after cutover
Once ingest resumes, the team runs saved searches, opens key dashboards, and confirms that event definitions evaluate and notifications reach their channels, such as email, Slack or PagerDuty where configured. They verify that retention still deletes the oldest indices and that users can sign in with their existing roles. Compare a sample of recent messages with the pre-cutover baseline. The step is done when the agreed checklist passes and the owners of searches and alerts confirm the results in writing.
Decommission Elasticsearch after the agreed hold
After the post-cutover checks pass and the rollback window closes, the team takes a final archive of the old Elasticsearch data, removes Graylog's configuration pointing at it, stops the nodes, and retires certificates, firewall rules and monitoring tied to them. Update the asset inventory and runbooks so Elasticsearch no longer appears as a dependency. Note that Elasticsearch is deprecated for Graylog and removed in Graylog 8.0, so this work also removes a future upgrade blocker. The step is done when the cluster is shut down, the archive location is recorded, and the change is closed.
Documented paths for moving index data and configuration
Graylog, OpenSearch and Elastic each document a different way to move index data and configuration. Read them together before choosing a path, because the Graylog method you pick decides how much journal capacity you need and how much downtime the switch costs.
Graylog's OpenSearch upgrade methods
Graylog's 5.2 documentation describes three methods for moving from Elasticsearch to OpenSearch: a full-cluster restart, a rolling restart and a new cluster restored from a snapshot. The full-cluster restart is the method Graylog recommends for most users. Read the method page for the Graylog version you run today, since the guidance was written for 5.2 and your target version may differ. Confirm the method with your Graylog support contact before scheduling the change window.
Full-cluster restart and journal capacity
A full-cluster restart stops indexing while OpenSearch is installed, so Graylog nodes must hold every incoming message in their journal for that window. Size the journal disk against your ingest rate and the expected duration of the switch, not only against normal operation. Confirm the journal settings on each Graylog node before the change starts, and plan how sources will buffer if the journal fills.
OpenSearch migration and the Migration Assistant note
OpenSearch's migration documentation covers moving data between versions and clusters. Its guidance on whether Migration Assistant fits a given move is useful for judging whether a tool-driven migration suits your topology, but Migration Assistant is built around OpenSearch's own cluster-to-cluster workflow. Check whether Graylog's index layout and index set naming survive that path before relying on it for a Graylog cluster.
Snapshot and restore between clusters
A new cluster restored from a snapshot lets you run OpenSearch alongside the old Elasticsearch cluster and cut over once the restored indices check out. This path needs a snapshot repository both clusters can reach and a restore test on representative indices. Confirm which Elasticsearch and OpenSearch versions can exchange snapshots, because compatibility depends on the release line you start from.
Graylog 7.0 upgrade requirements
The Graylog 7.0 upgrade notes state that Elasticsearch is deprecated, will be removed in Graylog 8.0, and that Data Node and self-managed OpenSearch are the preferred search backends. Read this page before your next Graylog upgrade, since it sets the deadline that shapes the rest of the plan. Check the prerequisites listed for the Graylog version you are moving to, not only the search backend.
No Kibana dashboard importer and config export checks
No importer exists that moves Kibana dashboards into Graylog, so saved searches and visualizations must be rebuilt as Graylog searches and dashboards. Export your Graylog configuration, index set settings and pipeline rules before changing the backend, and check that export format against the Graylog version you run. Treat the rebuilt dashboards as a separate work item with its own review.
Moving from OpenSearch to Data Node later
Graylog recommends Data Node as its search backend, and OpenSearch 1.x is deprecated since Graylog 7.0 and removed in Graylog 8.0. The work on this page ends when your Graylog runs on a supported OpenSearch release, so treat the move to Data Node as a separate project with its own change window. Do not fold it into the Elasticsearch to OpenSearch cutover, because each step changes a different part of the search tier and multiplies what can fail at once.
Before you pick the OpenSearch version for this step, check the target combination in the Graylog compatibility matrix. For Graylog 7.0 to 7.2, the documented ceiling is OpenSearch 3.7.x, and Graylog Security needs OpenSearch 2.0 or later. Confirm the exact Graylog and OpenSearch pairing for your release before you install anything, because a version that works for the server may not be the one Graylog documents for your edition. Record the pairing in your change plan so the later Data Node move starts from a known, supported state.
When you plan the later move, the Data Node path is an in-place migration performed with the Graylog migration wizard, so your existing OpenSearch hosts and index data are not rebuilt from scratch. Ask your Graylog contact or check the Graylog documentation for the prerequisites, the certificate authority and renewal policy the wizard expects, and the rollback steps. Schedule that work after the OpenSearch cutover has been stable for long enough to show that searches, retention and alerting behave as expected.
What drives the effort and duration of the move
This table lists the factors that change how much work the move takes and how long the cluster stays in a changed state. Read each row for who carries the work and whether the cost is paid once or recurs. The main takeaway is that journal headroom, the chosen method and the number of log sources usually matter more than the search engine swap itself.
| Driver | Why it changes effort | Who pays and cost type |
|---|---|---|
| Index volume and retention | More indexed data means longer reindexing or snapshot restore and more disk to hold old and new copies during the switch. | Internal staff confirm sizing; partner or internal platform team pays for the work. One-time for the move, with storage cost recurring. |
| Number of index sets and streams | Each index set has its own rotation and retention settings, and each stream routes into them. More of them means more configuration to verify after the switch. | Internal staff review settings; partner effort scales with the count. One-time. |
| Journal disk headroom | A full-cluster restart needs enough disk on Graylog nodes to hold all incoming messages in the journal while OpenSearch is down or being replaced. Less headroom forces a shorter window or a different method. | Infrastructure team pays for any added disk. Hardware cost is one-time, though larger journals raise recurring storage cost. |
| Chosen method | Full-cluster restart, rolling restart and new cluster from snapshot each carry different preparation, testing and cutover steps. Graylog recommends the full-cluster restart for most users. | Internal staff or partner decides with the team. One-time planning and testing cost. |
| Downtime window | A shorter acceptable window narrows the method choice and may require more parallel capacity or more journal disk. | Business owners set the window; the cost of extra capacity is one-time or recurring, depending on whether it is kept. |
| Cluster topology | A single node has no peers to take traffic during a rolling change. A multi-node Graylog and backend setup needs each node changed in turn and checked before the next. | Internal platform team or partner pays for repeated node work. One-time for the move. |
| Security and TLS scope | Enabling TLS, certificates and authentication on the new OpenSearch cluster adds configuration and client updates on every Graylog node. | Internal security team sets policy; partner or internal engineers implement. One-time, with certificate renewal recurring. |
| Custom plugins or Kibana content | OpenSearch Dashboards derives from Kibana 7.10.2, so saved objects, plugins or dashboards built on the older stack need review for compatibility. | Internal analysts check content; partner effort depends on how much needs rework. One-time. |
| Number of log sources affected | Sources that send through the backend indirectly may need no change, but inputs, collectors and alerts tied to specific indices need checking after cutover. | Internal teams owning each source verify delivery. One-time, with ongoing monitoring recurring. |
What usually goes wrong during the backend switch
Most failed backend switches come from a few predictable gaps: the message journal filling during a long outage, search behavior changing after the move, and settings that were never carried over. Each card below names one risk and a check you can run before the cutover window opens.
Journal overflow during a long restart
A full-cluster restart stops search while Graylog keeps accepting messages into its on-disk journal. If the outage runs longer than the journal can hold, incoming messages are lost or inputs stall. Graylog's method guidance says the Graylog nodes need enough disk to hold all incoming messages during the switch. Before the window, measure your daily ingest rate, multiply by the planned outage length, and confirm the journal volume has room for that figure with margin.
Field mapping differences break searches
OpenSearch is a fork of Elasticsearch 7.10, so most queries carry over, but index templates, field types and analyzers may not behave identically on a new cluster. Saved searches, extractors and pipeline rules that depend on specific field types can return fewer results without raising an error. Run a set of known searches on a staging cluster and compare counts and field types against the current system before you cut over.
Dashboards and alerts pointing at the old backend
Event definitions, notifications and dashboards reference index sets and connection settings. If any of them still point at the old Elasticsearch endpoint after the switch, alerts can go silent while the system still looks healthy. Export the list of event definitions and their notification targets, then send a test alert through each channel after cutover and confirm it fires.
Certificates and authentication not carried over
The new search backend needs its own TLS certificates, trust chain and service credentials, and Graylog must trust them. Teams often reuse hostnames without reissuing certificates, or leave the old realm and role mappings in place. Confirm that the Graylog server trusts the new certificate chain, that service accounts exist with the required permissions, and that a test user can sign in and search before the old cluster is switched off.
Unsupported version pairs
Graylog publishes a compatibility matrix that pairs each Graylog release with supported MongoDB and OpenSearch versions. Moving to a newer Graylog and a newer OpenSearch in the same window doubles the number of variables to test. Check the matrix for both your current Graylog version and your target version, and confirm that the chosen OpenSearch line is supported before you install anything.
Backups skipped before the switch
Without a verified backup of the MongoDB configuration and the existing indices, a failed switch can force a rebuild of streams, pipelines and inputs from memory. Take a MongoDB backup and a snapshot of the old cluster, then restore a copy into a test environment to confirm both are usable. Record the restore time so the rollback plan has a realistic estimate behind it.
Questions buyers ask before moving Graylog off Elasticsearch
How much effort and cost does moving Graylog off Elasticsearch involve?
The effort depends on the cluster size, the Graylog version in use and how much disk the message journal can absorb during the switch. Most of the cost is labor: planning the method, testing the new search backend, cutting over Graylog nodes and verifying searches, dashboards and event definitions afterward. Software costs are typically zero for the OpenSearch backend itself, because OpenSearch is released under the Apache License, Version 2.0. Ask any partner for a fixed-scope quote built from your node count, index volume, retention period, number of inputs and pipelines, and whether you need a snapshot repository for rollback. Work that recurs includes patching and capacity checks on the new backend, which should be priced separately from the one-time migration.
Can our own team move Graylog off Elasticsearch without outside help?
A team that already runs Graylog and OpenSearch can usually do the work internally, provided it has a tested backup, a rollback plan and enough spare disk on the Graylog nodes. The skills needed are Linux administration, OpenSearch cluster operations, TLS and certificate handling, and a working knowledge of Graylog's index sets and journal settings. Teams that have not operated a search cluster before often find the verification stage, comparing search results and alerts before and after the cutover, takes the most time. If your team lacks one of these skills or has no staff free during a change window, a fixed-scope engagement can cover planning, execution and documentation while your staff keep ownership of the running system.
How long will log search and ingestion be down during the switch?
Downtime depends on the method you choose. Graylog's documentation describes a full-cluster restart, a rolling restart and a new cluster restored from a snapshot, and it recommends the full-cluster restart for most users. A full-cluster restart stops search for the duration of the change, so inputs must buffer incoming messages in the journal until the new backend is ready. A rolling restart keeps the cluster available but takes longer to plan and needs compatible versions at each step. A snapshot-based move limits risk to the old cluster but requires a period of catch-up for data written after the snapshot. The duration itself depends on your data volume and hardware, so measure it in a test environment that matches production before you commit to a window.
What does the journal need to hold during the Elasticsearch to OpenSearch move?
The journal must hold every incoming message while the search backend is unavailable, so its capacity is the main technical limit on a full-cluster restart. Graylog's documentation says the nodes need enough disk to hold all incoming messages in the journal during that window. The system architecture guidance advises giving the message journal 3 to 5 times daily ingest on SSDs, and sizing log storage as daily ingest times retention days times 120 percent. Before the change, confirm the current journal size, the maximum ingest rate during peaks, and how long the window will last. If the window is longer than the journal can cover, a rolling method or a snapshot-based move is the safer choice.
Is OpenSearch free to use after leaving Elasticsearch?
Yes, the OpenSearch software is released under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe any paid edition. That license is an OSI-approved open source license. Graylog Open is a different case: since Graylog 4.0 it is licensed under the Server Side Public License version 1 (SSPL-1.0), which is not OSI-approved, even though it is free of charge with no volume limits. So the backend you move to is licensed differently from the Graylog server that uses it. Check your own policy on license types before you decide, and read the Graylog LICENSE file for the terms that apply to your version.
Do we need Graylog Enterprise or Graylog Security for this move?
The move itself does not require a paid Graylog edition. Graylog Open can run on self-managed OpenSearch, and the migration uses Graylog's documented methods. You do need a paid edition for specific features. Graylog Enterprise is priced from 15,000 US dollars per year and adds a data lake with archive restore, data tiering, a correlation engine and 24/7 support, according to Graylog's pricing page. Graylog Security is priced from 18,000 US dollars per year and needs OpenSearch 2.0 or later. Both minimums apply at 10 GB per day or 100 Graylog Compute Units. If you rely on those features or on single sign-on with Okta, OpenID Connect or SAML, confirm the license terms in writing before you plan the backend change.
What changes when Graylog 8.0 removes Elasticsearch support?
Graylog 7.0 deprecates Elasticsearch, and Graylog 8.0 removes it, so an Elasticsearch backend must be moved before you upgrade to 8.0. Graylog names Data Node and self-managed OpenSearch as the preferred search backends. The OpenSearch move is the natural first step, and a later move to Graylog Data Node is a separate project with its own certificate and rollout planning. Plan the order of work with your upgrade calendar in mind, since an upgrade to 8.0 on Elasticsearch is not a supported path. Confirm the exact compatibility rules for your target versions in Graylog's upgrade notes before you schedule the change.
What DeployOpen needs from your team to scope the move
A fixed-scope quote for this move depends on a short list of facts about your current Graylog, and the written scope comes first: DeployOpen agrees the scope, deliverables and timeline in writing before any work starts, so the more precise your inputs, the fewer assumptions the scope has to carry. Start with versions. Confirm the exact Graylog server release, the Elasticsearch version behind it, and the MongoDB version used for configuration, because the compatibility matrix in the Graylog docs ties supported combinations together and the path differs depending on whether you are moving to OpenSearch or straight to Data Node. Also confirm whether Graylog Security is licensed, since it needs OpenSearch 2.0 or later.
Next, provide an inventory of index sets and streams. List each index set with its rotation rule (message count, size or time), its retention setting and its approximate size on disk, along with the streams that route into them and any processing pipelines that depend on specific field names. Add your daily ingest and retention period, since sizing for the journal and the new cluster both come from those figures. Ask for the journal configuration and the free disk on each Graylog node, because a full-cluster restart requires enough disk to hold incoming messages in the journal while OpenSearch is replaced. Describe your network topology too: which hosts run Graylog, Elasticsearch and MongoDB, where the load balancer sits, and which firewall rules separate them.
Finally, describe authentication and the downtime window. Name the authentication backends in use (LDAP or Active Directory, trusted header, or single sign-on) and any certificates or TLS settings on the search cluster, since those must be carried across. State how long log ingestion can pause, who approves the window, and whether a rollback point is acceptable if the cutover fails. These answers determine whether the full-cluster restart or a snapshot-based method fits, and they feed directly into the timeline and deliverables that follow the scope.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this move, we scope the Elasticsearch to OpenSearch change against your Graylog version, cluster layout and journal capacity, then build, test and document it in your environment.
How we scope
- Inventory the current Graylog version, Elasticsearch version, node roles and index sets before choosing a restart method
- Confirm journal disk capacity on each Graylog node for the chosen full-cluster or rolling path
- Agree the target OpenSearch version and the planned Data Node follow-on in a written, fixed-scope agreement
How we build
- Take and verify snapshots of existing indices and Graylog configuration before any node is changed
- Install and configure OpenSearch on the agreed hosts, with Security plugin and TLS settings planned up front
- Run a rehearsal on a non-production copy and record the restart sequence, timings and any parsing or index differences
How we hand over
- Deliver a runbook with the cutover order, rollback steps and the checks that confirm search and indexing work
- Document journal thresholds, monitoring points and the decisions made about OpenSearch and Data Node
- Walk your operations team through the procedure and the open items you must confirm with your vendors or environment
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing
- Plan follow-up work for the OpenSearch 3.x upgrade path and the later move to Data Node before Graylog 8.0
- Keep scope changes, new versions and added nodes under written change requests agreed before work starts
