What moving Graylog from OpenSearch to Data Node involves
Moving an existing Graylog off self-managed OpenSearch onto Graylog Data Node is an in-place migration, and the effort depends mostly on how many OpenSearch hosts you run, how much data sits on them, and whether your cluster already uses TLS. Confirm those three facts first, because they decide how long the cutover window needs to be and how much of the work your own team can absorb. Graylog documents the migration as a change to a live system, so plan it as a maintenance activity rather than a configuration tweak. The Graylog docs carry a warning that any Data Node migration risks data loss on live data, and they require appropriate backups before you start. Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved open source license, so your legal and procurement teams should review that license before committing to the platform. The migration itself does not change the license terms of Graylog Open, but it does change the search backend your organization operates.
The migration wizard is reached from System > Cluster Configuration in the Graylog web interface. It asks you to create or upload a certificate authority in PEM or PKCS #12 format, sets a certificate renewal policy (automatic by default, with a 30-day certificate lifetime by default), and requires Data Node to be installed on every existing OpenSearch instance. Before opening the wizard, decide who owns the certificate authority and how renewals will be monitored, because an expired certificate will affect every node. The Graylog Data Node migration guide lists the steps in order, and the separate TLS-secured guide applies if your OpenSearch cluster already encrypts node and client traffic.
What carries over from OpenSearch and what the migration changes
This table compares each part of a running Graylog search backend with what it becomes after the in-place migration to Data Node. Read each row as a checklist item: confirm the carry-over behavior against the Graylog docs for your exact Graylog and OpenSearch versions before you schedule cutover, because several answers depend on version and edition.
| Capability | Self-managed OpenSearch today | Data Node after migration | Migration note to confirm |
|---|---|---|---|
| Index sets | Index sets point to indices on the OpenSearch cluster | Index sets continue to define storage, but the indices live on Data Node nodes | Confirm in the migration guide that existing index sets and their rotation settings are preserved before cutover |
| Indices and stored messages | Message data sits in OpenSearch indices | Data is moved onto the Data Node cluster as part of the in-place process | The Graylog docs warn of data loss risk on live data, so take backups first and verify restore |
| Streams and pipelines | Stored in Graylog's MongoDB metadata, not in OpenSearch | Unchanged, since they are Graylog configuration rather than search data | Confirm no stream or pipeline rule references an OpenSearch-only setting |
| Users and roles | Graylog users and roles live in Graylog and MongoDB | Unchanged at the Graylog level | Confirm any direct OpenSearch Security users or roles you created outside Graylog, which Graylog does not manage |
| TLS for node and client traffic | Depends on how your OpenSearch cluster was secured | Certificate authority and renewal policy are set in the wizard, with automatic renewal and a 30-day default lifetime | Confirm your CA type (PEM or PKCS #12), renewal policy and whether your cluster was already TLS-secured, which needs the separate guide |
| Retention | Index rotation and retention delete the oldest indices per index set | Retention remains an index set setting, applied to Data Node indices | Confirm rotation thresholds and retention behavior on Data Node in the Graylog docs for your version |
| Host installation | OpenSearch runs on each existing host | Data Node must be installed on every existing OpenSearch instance | Plan one host at a time, and check each host meets the Data Node install requirements in the docs |
| Edition and version features | Some capabilities depend on OpenSearch version (Graylog Security needs 2.0 or later) | Data Node support follows the Graylog compatibility matrix for your release | Confirm feature availability for your edition and Graylog release before cutover, since some features need Enterprise or Security |
Which version and TLS path applies to your cluster
If your OpenSearch nodes accept Graylog traffic without TLS on either the node-to-node transport layer or the HTTP client layer, the in-place wizard path in this guide applies. The wizard asks for Data Node on every existing OpenSearch instance, so the first task is to confirm exactly what is running today.
- Node inventory: list every OpenSearch instance that Graylog writes to, including nodes in warm or cold roles, because the wizard expects Data Node on each one.
- TLS settings: read the
opensearch.ymlfile on each node and confirm that transport and HTTP encryption are both disabled. - Cluster health: start from a green cluster with no unassigned shards, since migrating a degraded cluster raises the data loss risk the Graylog docs warn about.
- Host access: confirm that you can install packages on each host with the privileges your team uses for OpenSearch today.
- Configuration drift: note any node whose settings differ from the rest, because those nodes need a separate review before the change window.
Check the node list and TLS settings against your change record before you schedule the wizard run.
If transport or HTTP TLS is enabled on your OpenSearch cluster, do not treat the standard wizard steps as the whole job. Graylog documents a separate guide for TLS-secured OpenSearch clusters, and the Data Node migration guide points to it. Work from that guide for the certificate handling on your cluster.
- Encrypted paths: separate transport TLS, which covers traffic between OpenSearch nodes, from HTTP TLS, which covers clients such as Graylog, because each affects how Data Node joins the cluster and how Graylog reconnects.
- Existing certificate chain: collect the CA and node certificates you run today, and record whether each is self-signed or issued by an internal CA.
- Expiry dates: note the expiry date of every certificate in the chain, since the wizard's default certificate lifetime is 30 days and renewal policy needs to match your operations.
- Certificate material: the wizard can create a certificate authority or accept one in PEM or PKCS #12 form, so decide in advance which format you will supply.
- Service accounts: list the OpenSearch users and roles that Graylog uses today, because those credentials must still work after the move.
Confirm the separate TLS guide's prerequisites and certificate plan with your security team before scheduling the change window.
The compatibility matrix is the gate for this migration. For Graylog 7.0 through 7.2, it lists OpenSearch from 1.1.x up to 3.7.x. OpenSearch 1.x has been deprecated since Graylog 7.0 and is scheduled for removal in Graylog 8.0, so a 1.x cluster can run today but must be planned for change.
- Graylog line: record the exact Graylog version now running and the target version, since the matrix is read per release.
- OpenSearch range: a cluster on a version from 1.1.x through 3.7.x sits inside the documented range for Graylog 7.0 to 7.2. Anything outside that range needs a check with Graylog before you proceed.
- 1.x deadline: Graylog 8.0 removes support for OpenSearch 1.x, so the Data Node move is a practical point to settle that dependency.
- MongoDB pairing: the matrix pairs Graylog 7.0 to 7.2 with MongoDB 7.x up to 8.2.x, and a mismatch there can block the same change window.
- Newer releases: OpenSearch versions above 3.7.x are not in the supplied matrix range, so confirm support with Graylog before using one.
Save the matrix row for your exact Graylog release in the change record so the version decision is documented.
Graylog Security needs OpenSearch 2.0 or later. If your organization licenses Graylog Security, a cluster still on OpenSearch 1.x fails this requirement even though Graylog Open can run on it. The edition you hold therefore sets the version floor, and that choice should be made before the migration sequence is fixed.
- Edition check: confirm with Graylog which features your license includes, such as investigations and compliance packs, before you choose a target version.
- Version floor: OpenSearch 2.0 or later is the minimum for Graylog Security, so a 1.x cluster needs an upgrade step before or alongside the Data Node move.
- Sequence: decide whether the OpenSearch upgrade happens first or whether the target becomes Data Node on a supported engine. The sibling topic on moving off OpenSearch 1.x covers that decision in detail.
- Upper bound: the supplied matrix range still applies to Graylog Security, so a version floor does not remove the 3.7.x ceiling for the 7.0 to 7.2 line.
- License terms: ask Graylog to confirm the license tier for your environment, because published pricing gives starting points and not a quote for your deployment.
Record the edition and the OpenSearch version floor together so security and procurement review the same decision.
How the migration runs from inventory to decommission
The sequence moves the search backend from self-managed OpenSearch to Data Node in an order that keeps log data recoverable at every stage and ends with the old nodes retired only after searches and ingest are confirmed on the new backend.
Inventory OpenSearch hosts and indices
List every OpenSearch node, its version, its role in the cluster, the index sets Graylog writes to, and the retention and rotation settings on each. Record which hosts run Graylog-related services and where the data paths and heap settings live. Confirm the exact Graylog and OpenSearch versions against the compatibility matrix before anything else, because the wizard depends on them. The output is a written inventory that the migration team signs off, and it becomes the checklist for installing Data Node on each host later. Ask your Graylog administrator to confirm which index sets are active and which are only kept for retention.
Verify backups before any change
The Graylog documentation warns that any Data Node migration carries a risk of data loss on live data, so take backups first and test that they restore. Confirm snapshot repository configuration, the storage location, the access rights of the backup account, and a recent successful snapshot covering every index in the inventory. Also back up the MongoDB configuration database and Graylog server configuration files. The step is done when a restore of a sample index has been tested in a separate environment and the team has written down who can start a restore. Do not proceed on an untested backup.
Pilot the migration on a non-production Graylog
Run the full sequence on a copy of the environment with representative indices and the same Graylog and OpenSearch versions. The pilot exercises the certificate step, the wizard, the Data Node installation on each host and the validation checks in the same order production will use. Record every deviation, including timing, errors, permission problems and anything the wizard asks that the runbook did not anticipate. The step is complete when the pilot finishes and the team has a corrected runbook. Ask your vendor or internal platform owner to confirm which parts of the pilot cannot match production, such as data volume or network paths.
Create or upload the certificate authority
In the wizard, the certificate authority is either created by Graylog or uploaded in PEM or PKCS #12 format. Decide which option your security policy allows, and confirm who holds the private key and where it is stored. Choose the certificate renewal policy: automatic renewal is the default, and the default certificate lifetime is 30 days. If you choose manual renewal, confirm who receives renewal reminders and how the renewal will be performed on each node. The step is done when the authority is in place, the renewal policy is recorded in the change record, and the security owner has approved both.
Run the migration wizard in System Cluster Configuration
Open System, then Cluster Configuration, and start the Data Node migration wizard. Provide the certificate authority from the previous step and the renewal policy, then follow the prompts that ask for Data Node to be installed on every existing OpenSearch instance. Do not treat the wizard as a one-click operation: keep the change window open, watch the cluster health and Graylog journal, and stop if any node reports errors. The step is complete when the wizard reports that the migration has moved to the installation phase and every node is listed as pending or ready. Ask the vendor to confirm the current wizard behavior for your exact Graylog version.
Install Data Node on each OpenSearch host
On each host from the inventory, install Data Node as the wizard directs, one node at a time so the cluster keeps quorum and index availability throughout. Confirm that each node joins the cluster, that shard allocation returns to a healthy state, and that the data paths match the inventory. Check that the node certificates are issued from the authority and that renewal is configured. The step is done when every host runs Data Node, the cluster reports healthy, and the wizard marks the installation complete. Keep the OpenSearch nodes you have not yet replaced available until validation passes.
Validate searches, ingest and alerts
Confirm that Graylog can write new messages to the expected index sets, that searches return results across old and new indices, and that dashboards and event definitions still evaluate. Check the message journal for growth, compare message counts for a sample window before and after the change, and confirm that inputs such as syslog, GELF or Beats still accept traffic. Validate that retention and index rotation still delete the oldest indices as configured. Record each check in a signed validation record. The step is complete when every check passes and the record is filed with the change ticket.
Run in parallel, cut over and decommission
Keep the old OpenSearch nodes available in read or standby mode for a parallel run long enough to compare results with your own log review requirements, then cut over by confirming that all Graylog traffic goes to Data Node. Only after the parallel run and the rollback plan have been accepted should old OpenSearch nodes be stopped, removed from load balancing and retired. Retain the final snapshots as your archive of the pre-migration state. The step is done when the old nodes are removed, the inventory is updated to show Data Node, and the change owner closes the record. Ask your security or compliance lead how long the parallel run and retained snapshots must last under your policies.
Choosing the certificate authority and renewal policy
Before the migration wizard runs, the team has to decide where the certificate authority for Data Node comes from. The wizard in System > Cluster Configuration either creates a new certificate authority or accepts one you upload, in PEM or PKCS #12 format. Creating one inside the wizard is the simpler path for a lab or a first production cluster. Uploading an existing CA makes sense when your security team already issues certificates for internal services and wants Data Node to trust the same root. Whichever route you choose, confirm the format your CA export uses before the wizard starts, because a mismatched file is an avoidable stop in the middle of a change window.
The renewal policy is the setting that most often causes trouble later. Automatic renewal is the default, and the default certificate lifetime is 30 days. A 30-day lifetime means certificates are rotated frequently, so an automatic process that fails silently will eventually break cluster communication. Decide who owns the CA private key, where it is stored (an HSM, a vault or a restricted file store on the Graylog host), and who can export or replace it. Confirm with your security team whether a 30-day lifetime fits your internal certificate standards, and whether the renewal policy should be automatic or manual for your environment.
Monitoring renewal failures is the decision teams most often skip. Assign an owner for alerts on certificate expiry and renewal errors, and route them to a channel someone reads outside business hours. Check the Graylog Data Node migration guide for the current renewal behavior and any manual steps required, since the wizard's behavior is documented there and may change between releases. Record the CA location, key custodian, renewal policy and alert destination in your runbook before cutover, so the person on call during a renewal failure does not have to reconstruct the design.
Documented tools and paths for this migration
Graylog documents one in-place route for moving an existing OpenSearch backend onto Data Node, with a separate guide for TLS-secured clusters. The cards below cover the wizard, the certificate decisions it forces, the Data Node install on each host, and the backup and rollback work that sits outside Graylog's own tooling.
In-place migration wizard
The wizard in System > Cluster Configuration is the documented entry point. It asks you to create or upload a certificate authority, set a certificate renewal policy, and install Data Node on every existing OpenSearch instance. Read the full wizard flow before scheduling work, because each step changes the cluster you are migrating. Confirm the Graylog version in your environment matches the guide you are following.
Certificate authority and renewal policy
The wizard accepts a CA in PEM or PKCS #12 form, or creates one for you. Decide whether your organization will issue the CA or let Graylog manage it, and who owns the private key. The renewal policy defaults to automatic with a 30-day certificate lifetime, so confirm that your monitoring and change process can handle renewals that happen without a ticket.
TLS-secured cluster variant
Graylog provides a separate guide for OpenSearch clusters that already use TLS. If your nodes enforce TLS for transport or HTTP traffic, follow that path rather than the standard wizard steps. Check which certificates the existing cluster presents, which CA signed them, and whether your team can reissue them without downtime.
Data Node install on each host
The wizard asks for Data Node on every existing OpenSearch instance, so each host needs a planned install window. Inventory the hosts, their OS packages, disk layout and JVM settings before starting. Graylog's installation docs list the supported package methods, and you should confirm the exact package and version for your platform there.
Backups and snapshots
Graylog warns that any Data Node migration carries a risk of data loss on live data and requires appropriate backups first. Graylog's guide does not name a snapshot tool for you. Use the OpenSearch snapshot documentation as the reference, and confirm with your storage and platform team which repository type, retention and restore test your environment supports before the migration starts.
Rollback planning
Rollback depends on what you captured before the wizard ran. Write down the steps to restore the previous search backend, the snapshot you would restore from, and the point at which you stop and roll back. Test the restore in a non-production copy where possible, and confirm who has authority to make the call during the change window.
Planning rollback before the wizard runs
Rollback has to be designed before the migration wizard runs, because the Graylog docs warn that any Data Node migration carries a risk of data loss on live data. Once the wizard has started installing Data Node on each OpenSearch host, you are no longer reverting one setting. You are reversing a sequence of changes across the Graylog server nodes, the cluster configuration and every search host, and that is much harder to do under pressure. Write the rollback plan as a document with named owners, and agree it with the people who will approve a revert at the time.
Before you start, retain three things. First, a verified backup of the indices and of the MongoDB database that holds Graylog configuration, with a test restore on a separate cluster. A backup that has never been restored is an assumption, not a recovery option. Second, the original OpenSearch configuration, including opensearch.yml, JVM options, security settings and the certificates currently in use, so the old cluster can be brought back exactly as it was. Third, the certificate material created or uploaded in the wizard, the certificate authority with its private key, and the renewal policy you chose, stored where the recovery team can reach it without the failed cluster being up.
Document the revert steps in writing and confirm each one with Graylog for your version, since the wizard flow and cluster configuration screens change between releases. The decision point to plan around is the moment Data Node takes over indexing and new log data is written only to the new backend. After that point, returning to OpenSearch means moving or replaying data that arrived during the migration, and your journal capacity will determine how much can be held in the meantime. Set that cut-off explicitly, record who can call it, and ask Graylog support to confirm what a revert looks like once it has passed.
What drives the effort and cost of this migration
This table lists the factors that change how much work the move from self-managed OpenSearch to Data Node involves, whether each cost is one-time or recurring, and what to request in a written quote. Use it to see which factors apply to your environment before comparing proposals. The main takeaway is that host count, data volume, TLS posture and version gaps usually matter more than the wizard itself.
| Driver | Why it changes effort or cost | One-time or recurring, and what to ask for |
|---|---|---|
| Number of OpenSearch hosts | The wizard asks for Data Node to be installed on every existing OpenSearch instance, so each host adds installation, configuration and verification work. | One-time. Ask the partner to list each host, its role and the install steps they will perform on it. |
| Index volume and retention | Larger indices and longer retention lengthen the pre-migration backup and the post-migration verification, and raise the data-loss stakes if something goes wrong. | One-time for the migration, with backup storage that recurs. Ask how backup size was estimated and where copies will be held. |
| TLS posture of the existing cluster | A TLS-secured OpenSearch cluster follows the separate TLS guide, which adds certificate authority setup, renewal policy decisions and additional testing. | One-time build work, then recurring certificate renewal. Ask whether the quote covers the TLS-secured variant and who owns renewal after handover. |
| Graylog and OpenSearch version gaps | Graylog 7.0 to 7.2 support OpenSearch from 1.1.x up to 3.7.x, and Graylog Security needs OpenSearch 2.0 or later. Older versions may require an upgrade before the migration can start. | One-time, and it can add a separate upgrade project. Confirm current versions against the compatibility matrix and ask whether an upgrade is in or out of scope. |
| Number of inputs and sources to re-verify | Each input, stream, pipeline and dashboard that reads from the search backend needs checking after cutover to confirm logs still arrive and search results match. | One-time. Ask for a written list of inputs and sources in scope and the test method for each. |
| Change windows and maintenance periods | Limited windows force planning around the wizard run, host installs and rollback steps, and may require staged work across several sessions. | One-time, sometimes with after-hours labor. Ask how many windows the plan assumes and what happens if a window is missed. |
| Parallel run or staged cutover | Running old and new backends side by side protects log continuity but doubles some storage and monitoring work for the period it runs. | Temporary infrastructure cost that recurs until decommissioning. Ask who pays for the extra capacity and when the old backend is retired. |
| Rollback plan and tested restore | A rollback path that has been rehearsed takes more preparation than one that exists only on paper, but it limits the impact of a failed cutover. | One-time preparation. Ask whether the partner will rehearse rollback and document the restore steps used. |
Questions buyers ask before moving Graylog to Data Node
How much does a Graylog Data Node migration cost?
No public price applies to this work, and DeployOpen does not publish a price list. The cost follows from a written scope that covers the number of OpenSearch hosts, the cluster size and data volume, whether TLS is already in place, the certificate authority approach, and how much backup and rollback work is required. Ask for each component to be priced separately: planning, backups, certificate setup, Data Node installs on each host, validation, and handover. Clarify which parts are one-time project work and which recur, such as a support retainer. Graylog's own licensing is separate: Graylog Open is free with no volume limits and community support, while Enterprise starts at 15,000 US dollars per year according to the Graylog pricing page, licensed on processed data.
How long does the migration take?
Duration depends on the cluster and the environment, and no fixed timeline applies to every deployment. The main drivers are the number of OpenSearch instances that need Data Node installed, the amount of live data that must be backed up and verified, the state of existing certificates, change windows, and how many log sources must keep flowing during the work. Ask for a schedule that lists the backup and verification gates before the wizard runs, and a separate window for each host. Confirm the expected duration with the scope in writing before work starts, since the scope sets the timeline.
What does our team need to provide for the migration?
The team needs to supply access and decisions that only the owner can make. Typically that includes administrative access to Graylog and each OpenSearch host, a maintenance window agreement, current backup storage with enough space for a full copy, the certificate authority material or a decision on creating one, and the certificate renewal policy. Confirm the Graylog and OpenSearch versions in use against the compatibility matrix before scoping, because Graylog 7.0 to 7.2 support OpenSearch only up to 3.7.x. Name a point of contact for approvals, and make sure someone can review monitoring output during and after the cutover.
Can our internal team run this migration without a partner?
Yes, an internal team can run the migration if it has the skills and time for it, and the Graylog docs describe the in-place wizard in System > Cluster Configuration. The Graylog docs warn that any Data Node migration carries a risk of data loss on live data and require appropriate backups first, so the team should be confident in backup restore testing before starting. Teams without recent OpenSearch and TLS experience often choose a partner for planning and validation. DeployOpen plans, implements, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, typically under a fixed-scope written agreement.
Does the migration affect Graylog Open users?
The migration itself does not change the Graylog Open license, but the edition you run determines which features you can use afterward. Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license, and it is free with no volume limits and community support. Features such as Okta, OpenID Connect and SAML single sign-on, data lake archive restore, and SIEM features depend on Enterprise or Security licenses. Confirm with Graylog which features your edition includes before planning, and review the license terms in the LICENSE file of the Graylog repository.
What happens if the migration fails partway through?
A failed migration should be handled through rollback planning that is agreed before the work begins. Because the Graylog docs warn of data loss risk on live data, the first safeguard is a verified backup taken before the wizard runs. The rollback plan should state how to stop the wizard, which hosts were changed, how to restore from backup, and how to resume log ingestion, including whether the Graylog message journal can hold data during the outage. Ask for the rollback steps to be tested in a non-production copy where possible. Any recovery work after a failure is scoped as separate work in writing.
Do we need TLS before migrating to Data Node?
Not always, but the TLS-secured variant needs its own planning. Graylog provides a separate guide for TLS-secured OpenSearch clusters, and the wizard asks you to create or upload a certificate authority in PEM or PKCS #12 format. The default certificate lifetime is 30 days with automatic renewal, so confirm whether that policy fits your security standards before accepting it. Decide early who owns the certificate authority, how renewals are monitored, and how trust is distributed to each host. These decisions affect both the cutover window and later operations.
How DeployOpen scopes and delivers the migration
DeployOpen plans and carries out the move of a running Graylog search backend from self-managed OpenSearch to Data Node inside your own infrastructure. Each engagement starts with a written scope that covers version prerequisites, backups, the certificate authority, Data Node installation on every OpenSearch host and a rollback plan before any live data is touched.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timeline agreed in writing before work starts.
- The written scope confirms your current Graylog and OpenSearch versions against the Graylog compatibility matrix.
- We record which OpenSearch hosts, clusters and index sets the Data Node migration will touch and which are out of scope.
How we build
- We verify backup and restore of Graylog configuration and OpenSearch indices in a non-production copy first.
- We agree the certificate authority type, renewal policy and certificate lifetime with your security team before the wizard runs.
- We install Data Node on each existing OpenSearch host and test the TLS-secured variant where your cluster requires it.
How we hand over
- You receive documentation of the migration steps, the certificate renewal settings and the verification checks that were run.
- The deliverables include a tested rollback plan with the conditions under which it would be executed.
- We walk your platform and security teams through the Data Node configuration so they can operate it after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the migration is complete.
- Post-migration checks cover ingest, search and retention on the new backend before the old OpenSearch hosts are retired.
- Ask for a quote built from the written scope, which sets out the one-time migration work separately from any recurring support.
