Why OpenSearch 1.x has to move before Graylog 8.0
If your Graylog 7 deployment still stores logs on OpenSearch 1.x, that backend has to change before you move to Graylog 8.0. Graylog deprecated OpenSearch 1.x support in Graylog 7.0 and documents its removal in Graylog 8.0, so the upgrade is a prerequisite for the next major release rather than an optional clean-up. The Graylog 7.0 upgrade notes also state that OpenSearch 1.x reached end of maintenance in May 2025, which means the search backend is no longer receiving upstream bug fixes or security patches. For a log platform that often holds security-relevant data, that gap matters on its own, even before the version ceiling is considered.
The compatibility matrix for Graylog 7.0 through 7.2 lists OpenSearch from 1.1.x up to 3.7.x, so 3.7.x is the highest OpenSearch line Graylog documents as supported today. Within that range, Graylog Security requires OpenSearch 2.0 or later, so a team on Graylog Security cannot stay on a 1.x backend even while still running Graylog 7. Confirm your current Graylog edition and the exact OpenSearch build in your cluster before you choose a target, because the matrix sets the boundaries and the version you pick must fall inside them. Also confirm the upgrade path with the current Graylog documentation for your target release, since the matrix and upgrade notes are the authority for what is supported.
On effort, the short answer is that the work is driven by the size of your cluster, the number of indices and the depth of your data retention, not by the version numbers alone. Whichever path you take, you will need a verified backup, a rollback plan and a test run on a copy of the data before production. You can either upgrade the OpenSearch cluster in place to a supported line or move the search backend to Graylog Data Node, which Graylog recommends. Ask any partner or internal team to scope both options against your environment in writing, and ask them to name which steps are one-time migration work and which costs recur, such as operating the new backend.
Upgrade OpenSearch in place or switch to Data Node?
Upgrading in place keeps the search backend you already operate. The cluster, its hosts, its operating procedures and its existing indices stay where they are, and the change is limited to moving OpenSearch from 1.x to a version that Graylog 7.0 to 7.2 supports. The Graylog compatibility matrix lists OpenSearch from 1.1.x up to 3.7.x for those releases, so the target is a 2.x or 3.x line within that range. OpenSearch is released under the Apache License, Version 2.0, and its FAQ does not describe a paid edition, so the upgrade does not add a license cost to the software itself.
- What stays: your cluster topology, host inventory, existing index data and the team's familiarity with OpenSearch operations.
- What changes: the OpenSearch major version, plugin compatibility, TLS and security configuration, and the rolling upgrade sequence you run on each node.
- Graylog Security: if you plan to use Graylog Security, the backend must be OpenSearch 2.0 or later, so a move to 2.x is the minimum for that edition.
- Ongoing ownership: you continue to run, patch and capacity-plan the OpenSearch cluster yourselves.
- Upgrade planning: confirm the exact target version with the compatibility matrix on the day you plan the change, because the supported range is set by Graylog.
Before committing, check the target version against the Graylog compatibility matrix and confirm your team's support arrangements for the new OpenSearch line.
Switching moves log storage from OpenSearch to Graylog Data Node, which Graylog recommends as the search backend. The change replaces the OpenSearch cluster with a Data Node cluster that Graylog manages as its own component, and it includes an in-place migration path documented separately. The existing Graylog server nodes and their configuration remain in use, while the storage layer and its installation are different. Data Node is part of the Graylog platform, so its support and version alignment follow Graylog releases rather than a separate OpenSearch release train.
- What stays: Graylog server nodes, MongoDB for configuration and metadata, inputs, streams and pipelines.
- What changes: the search backend, the Data Node installation on each host, the certificate authority and renewal policy, and the migration runbook.
- Licensing: Data Node is the backend Graylog recommends, and its terms should be checked against your Graylog license and the Graylog product pages before purchase decisions.
- Graylog Security: Data Node is a supported path for Graylog Security deployments, so this route also satisfies the OpenSearch 2.0 or later requirement without tying you to OpenSearch version numbers.
- Effort: the migration needs planned backups, a rollback plan and a cutover window, so it is a project in its own right.
Confirm with Graylog which Data Node version matches your Graylog 7.x target and whether your license covers Data Node in your environment.
The two paths differ in what you license and who you rely on for support. OpenSearch software is available under the Apache License, Version 2.0, and the OpenSearch Software Foundation is a Linux Foundation project that does not oversee the technical direction of OpenSearch. If you choose the in-place path, your support relationship for the search layer is with the OpenSearch community and with whichever vendor or partner you engage for operations. If you choose Data Node, the backend is part of the Graylog platform and support follows the Graylog relationship.
- Graylog Open: the Graylog server is licensed under SSPL-1.0, which is not an OSI-approved license, and that applies to both paths.
- Graylog Enterprise and Security: the Graylog pricing page lists starting prices per year, with a minimum data volume, licensed on processed data. Ask whether the quote includes Data Node support.
- One-time costs: planning, testing, migration work and any hardware changes.
- Recurring costs: Graylog license fees if you use Enterprise or Security, and the operations effort for the chosen backend.
- What to ask for in a quote: the exact versions in scope, what support covers after cutover, and how license volume is measured.
Review the licensing text and the pricing page with your procurement and legal teams before you choose a path.
The decision usually depends on whether you want to keep operating OpenSearch as your own platform or to standardize on the backend Graylog recommends. An in-place upgrade is the smaller change when your OpenSearch cluster is healthy, your team already runs it well, and you accept that the Graylog compatibility range governs which versions you can run. A switch to Data Node is the better fit when you want the storage layer aligned with the Graylog release cycle and are willing to plan a larger migration. Neither path removes the 8.0 deadline, because OpenSearch 1.x support is deprecated in Graylog 7.0 and will be removed in Graylog 8.0.
- Choose in-place upgrade if: the cluster is stable, the target version is inside the compatibility range, and your team owns OpenSearch operations.
- Choose Data Node if: you want Graylog to recommend and align the backend version for you, and you can schedule a migration window.
- Consider Graylog Security needs: both paths can meet the OpenSearch 2.0 or later requirement, so the decision should rest on operations and support.
- Timing: start the decision early, because each path has prerequisites that take time to test.
- Hybrid approach: some teams upgrade OpenSearch first to reach Graylog 7.x and then plan a later move to Data Node.
Agree the path, the target versions and the test plan in writing before any production change begins.
Which OpenSearch 1.x features and settings carry over
This table compares each part of an existing OpenSearch 1.x deployment that Graylog depends on against a supported OpenSearch 2.x or 3.x target and against Graylog Data Node. Read each row as a question to answer in your own environment before choosing the target, since several items map only partly. The main takeaway is that index data usually moves with a supported upgrade path, while security plugin configuration, Dashboards objects and version-specific index behavior need separate checks with each vendor.
| Component | OpenSearch 2.x or 3.x target | Graylog Data Node target |
|---|---|---|
| Graylog index sets and index names | Index sets point to the same index patterns after the upgrade, provided the cluster keeps its index naming. Confirm that Graylog 7.x accepts the target version before cutover. | Index sets are re-created under Data Node. Existing indices are not automatically reused, so plan how historical data is carried over or searched. |
| Indices and data format | Indices created on OpenSearch 1.x are expected to be readable after a supported upgrade path. Confirm version-specific index compatibility with the OpenSearch migration guide before moving data. | Data is not moved in place by default. Confirm with Graylog how the in-place wizard handles existing indices on your version. |
| Security plugin configuration | Roles, users, role mappings and TLS settings may need manual review because security plugin behavior changes across major versions. Export and diff the configuration before the upgrade. | Graylog manages its own authentication and TLS to Data Node. Existing OpenSearch security plugin roles do not transfer, so rebuild access controls for Data Node. |
| TLS certificates and node transport | Certificates and trust chains usually carry over, but check certificate validity, hostname settings and cipher or protocol defaults in the target release. | Certificates are issued for Data Node. Confirm the certificate authority and renewal policy with Graylog before installing Data Node on each host. |
| Snapshots and repositories | Snapshot repositories registered on OpenSearch 1.x should be readable by the target only within the version range the vendor documents. Take a fresh snapshot before any change. | Snapshots taken from OpenSearch are not a documented restore path into Data Node. Confirm the restore procedure with Graylog before relying on old snapshots. |
| Dashboards objects and saved searches | OpenSearch Dashboards objects derived from Kibana 7.10.2 may need import or migration steps. Test saved objects and visualizations after upgrade, since they are not Graylog objects. | Graylog searches and dashboards are stored in Graylog's MongoDB metadata, so they remain in Graylog. Confirm that no OpenSearch Dashboards objects are used as a reporting dependency. |
| Index lifecycle and retention behavior | Index rotation and retention created by Graylog should be checked after upgrade, because behavior tied to older index settings can differ. Confirm with Graylog's supported version list. | Retention and rotation are configured in Graylog index sets. Verify that retention deletes the expected oldest indices after cutover. |
| Rollback path | Rolling upgrades are documented for supported source versions, but rollback after a major upgrade is often limited. Confirm the rollback steps with the OpenSearch documentation before starting. | Keep the OpenSearch 1.x cluster available until Data Node is verified. Confirm rollback steps with Graylog for your exact versions. |
Documented upgrade and migration paths
Graylog and OpenSearch document several routes off OpenSearch 1.x, and each asks something different of your team. Read the version rules first, then compare the OpenSearch upgrade guidance with Graylog's own Data Node migration before you commit to a sequence.
Graylog 7.0 upgrade notes
These notes state that OpenSearch 1.x support is deprecated in Graylog 7.0 and removed in Graylog 8.0, and that OpenSearch 1.x reached end of maintenance in May 2025. Your team needs to read the breaking changes for every Graylog version between your current release and the target, then list which ones touch your inputs, pipelines, API clients and MongoDB prerequisites. Confirm the target Graylog version with your own change calendar before you schedule anything.
Graylog compatibility matrix
The matrix defines which OpenSearch versions Graylog 7.0 to 7.2 accept, from 1.1.x up to 3.7.x, and it requires OpenSearch 2.0 or later for Graylog Security. Check the matrix against the MongoDB version and the Graylog server version you plan to run, not only the search backend. A cluster that is supported today may still need a second step if you also want Security features, so record that requirement before you pick a target.
OpenSearch migrate or upgrade guide
OpenSearch documents its own in-place and migration routes for moving between its versions, including rolling upgrades from supported Elasticsearch-era indices. This path keeps you on OpenSearch, so your team owns the cluster upgrade, plugin compatibility and the Security plugin configuration. Plan a snapshot, a rehearsal on a copy of the cluster and a rollback point for each hop. Confirm which hops are supported from your current version before you sequence them.
Migration Assistant fit check
OpenSearch's Migration Assistant guidance explains when a migration tool fits and when a simpler upgrade or fresh cluster is the better choice. Use it to decide whether your cluster is large or old enough to justify a dedicated migration project, or whether an in-place upgrade is enough. Document the answer with index counts, data volume and downtime tolerance so the decision can be reviewed later. Ask your team to confirm these inputs before the plan is approved.
In-place Data Node migration
Graylog's in-place wizard moves the search backend from self-managed OpenSearch to Graylog Data Node, which Graylog recommends as the search backend. The team must install Data Node on each OpenSearch host, prepare certificates and a renewal policy, and take backups before the switch. This path removes OpenSearch from your stack, so plan how you will operate Data Node, test rollback and confirm that the wizard covers your version and layout.
Sequence for moving the search backend before 8.0
This sequence moves Graylog's log storage off OpenSearch 1.x in an order that protects existing data and keeps log intake running. Each step closes with a check you can confirm before the next one starts.
Inventory versions, plugins and index sets
Record the Graylog server version, the MongoDB version, every OpenSearch 1.x node version, and any OpenSearch plugins or security settings in use. Confirm the target Graylog release and the search backend version it supports in the compatibility matrix, including whether Graylog Security is licensed, since it needs OpenSearch 2.0 or later. List every index set, its rotation and retention settings, and every input, stream and pipeline that writes to it. The output is a written inventory that the platform owner signs off on before any change is made.
Back up configuration and index data
Take a snapshot of the existing OpenSearch 1.x indices into a registered snapshot repository that the cluster can reach and that is stored separately from the cluster itself. Back up the MongoDB database that holds Graylog configuration and metadata, and export Graylog content packs or configuration you need to recreate. Restore one test index from the snapshot to a scratch location to confirm the backup is readable. Done means you have a restore test that succeeded and a documented location for each backup.
Pilot on a non-production cluster
Build a non-production copy of the Graylog server, MongoDB and the target search backend, then restore a representative sample of indices and replay a copy of real input traffic or a sanitized equivalent. Confirm that searches, dashboards, event definitions and notifications return the same results as production. Note every parsing, pipeline or plugin difference, and resolve each one. Done means the pilot matches production behavior for the workflows your teams rely on.
Run the target backend in parallel
Stand up the target search backend beside the existing cluster and point a subset of inputs or a new index set at it, while the OpenSearch 1.x cluster keeps receiving the main traffic. Watch the message journal on each Graylog node, the indexer throughput, disk use and error logs through the period you set in advance. Compare search results between the two backends for the same queries. Done means the parallel run stayed within the journal and storage limits you defined and the results agree.
Cut over inputs and index sets
Move inputs, streams and index sets to the new backend in a planned change window, one group at a time, and confirm each group is writing before the next group moves. Keep the old cluster read-only for searches over historical data until the cutover is verified. Record the time and the operator for each switch. Done means all log sources write to the new backend and no input shows a growing backlog in the journal.
Define rollback criteria before cutover
Agree in writing the conditions that trigger a rollback, such as sustained journal growth, lost or delayed messages, failed searches or broken alerting, and name the person who decides. Keep the old inputs configuration and the OpenSearch 1.x cluster available until those conditions have been checked for the period you agreed. Test the rollback steps in the pilot so the team knows the exact actions. Done means the rollback runbook was rehearsed and the decision owner is named.
Decommission the OpenSearch 1.x nodes
After the agreed verification period passes with no rollback trigger, take a final snapshot of the old cluster, remove its nodes from Graylog's configuration, and shut them down in order. Revoke any service accounts and firewall rules that only the old cluster needed, and update monitoring and runbooks. Keep the final snapshot for the retention period your policy requires. Done means no Graylog component references the OpenSearch 1.x cluster and the final snapshot is verified.
What drives the effort and cost of this move
This table lists the factors that change the effort and cost of moving Graylog off OpenSearch 1.x, and what each one means for the plan. Read each row as a question to answer in your own environment before asking for a quote. The main takeaway is that node count, data volume and the security configuration of the existing cluster usually matter more than the upgrade steps themselves.
| Driver | Why it changes effort or cost | What to confirm or ask for |
|---|---|---|
| Node and index count | Each OpenSearch node and Graylog index set adds reindexing, validation and rollback steps, and the number of hosts sets how many change windows the work needs. | Node list, index set count, shard counts and whether the target is an upgrade in place or a move to Data Node. |
| Retention and data volume | Larger stored volumes lengthen snapshots, backups and any reindex or restore test, and retention rules decide what must survive the move. | Daily ingest, retention period per index set and current disk use, with backup size estimates from your own storage. |
| Security plugin and TLS configuration | OpenSearch Security settings, certificates, roles and authentication backends must be carried over or rebuilt, and each TLS change affects every connected Graylog node. | Whether the Security plugin is enabled, which authentication backends are in use, certificate authority and renewal policy. |
| Custom content and Dashboards objects | Saved searches, dashboards, streams, pipelines and index templates need an export and import check, and custom content takes longer to verify than defaults. | Inventory of streams, pipelines, dashboards and content packs, and who owns each object. |
| Graylog Security needs | Graylog Security requires OpenSearch 2.0 or later, so a target version or license choice may change which components are in scope. | Current and planned license edition, and the OpenSearch version the vendor will certify for your Graylog release. |
| Journal capacity during the switch | Inputs buffer messages in the journal while search nodes are stopped or restarting, so the journal must hold the outage window without losing logs. | Journal size settings and disk headroom on each Graylog node, measured against your daily ingest rate. |
| Change windows and team skills | Each stage needs an approved window and someone who can run cluster operations, certificate work and rollback, which limits how many steps run in parallel. | Approved maintenance windows, named operators for OpenSearch and Graylog, and who signs off each stage. |
| One-time versus recurring costs | One-time work covers assessment, migration, testing and cutover. Recurring costs cover support, backups, license fees and ongoing patching of the new backend. | A quote split into one-time and recurring items, with license terms for any Graylog Enterprise or Security features. |
What usually goes wrong and how to prevent it
Most failed OpenSearch moves under Graylog are not caused by hard technical limits. They come from skipped checks: a version outside the supported range, a backup nobody restored, or a TLS setting that drifted during the change. Each card below names one failure mode, why it hurts this migration, and the check that prevents it.
Upgrading to an unsupported OpenSearch version
Graylog 7.0 to 7.2 support OpenSearch from 1.1.x up to 3.7.x, and Graylog Security needs 2.0 or later. Teams sometimes jump to a release they found in a package repository, such as a newer minor outside that range, and discover the gap only when Graylog refuses to connect. Before any change, confirm the exact target version against the compatibility matrix and write it into the change record.
Missing or untested snapshots
A snapshot that exists but has never been restored is not a backup. Confirm that a snapshot repository is registered, that the snapshot covers the indices Graylog depends on, and that a test restore into a separate cluster completes. Also back up MongoDB, since Graylog configuration and metadata live there, and the OpenSearch data alone will not rebuild the Graylog setup.
Certificate and TLS mismatches
Moving to a new search backend often changes the certificate chain, hostnames or trust store that Graylog server nodes use. A node that trusts the old certificate authority will fail quietly on some hosts and loudly on others. Inventory every connection from Graylog to the backend, confirm the CA and hostname checks for each node, and test renewal before the change window so an expiring certificate does not stop indexing.
Journal overflow during the switch
While the search backend is unavailable or slow, Graylog keeps accepting messages into its on-disk journal. If the journal fills before indexing resumes, messages are lost or inputs back up. Size the journal against the expected duration of the switch and your daily ingest, sizing it on SSDs as the system architecture guidance advises, and check journal utilization during the change rather than after it.
Security plugin role drift
After a backend change, roles, role mappings and users created in the OpenSearch Security plugin can differ from what Graylog expects, so some searches or index operations fail for specific users only. This usually shows up after go-live, when a service account or an analyst's saved view breaks. Export the role and mapping configuration before the change, compare it after, and test with each Graylog service account and a representative analyst login.
Skipped rollback planning
Teams that plan only the forward path have no defined way back when a check fails at 2 a.m. Write the rollback steps before starting: which snapshot restores the indices, which configuration files revert, who decides to roll back, and the time limit for that decision. Rehearse the rollback on a staging copy so the steps are known to work, and record who on your side and on the partner side owns each step.
Questions buyers ask before moving OpenSearch under Graylog
What does it cost to move OpenSearch 1.x under Graylog?
The cost depends on how many nodes, indices and log sources sit behind your current cluster, how much of the work your own team can absorb, and whether the target is an OpenSearch upgrade or a move to Graylog Data Node. Costs fall into three groups: the engagement itself (planning, the upgrade or migration runbook, cutover support and documentation), infrastructure for the new or upgraded nodes and a temporary parallel environment, and internal staff time for change windows and testing. Engagement fees are one-time. Licenses for Graylog Open are free, while Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year according to Graylog's pricing page, with a minimum of 10 GB per day or 100 Graylog Compute Units. Ask any partner for a fixed-scope quote listing node counts, backup steps and rollback tests.
How long does an OpenSearch 1.x upgrade take before Graylog 8.0?
Duration depends on cluster size, data volume, the number of Graylog nodes that must reconnect, and how many maintenance windows your change process allows. Larger clusters with many indices need longer for snapshots, rolling restarts and index verification. Teams that run a parallel test cluster finish faster because the production cutover becomes a short, rehearsed step. Graylog's compatibility matrix says Graylog 7.0 to 7.2 support OpenSearch from 1.1.x up to 3.7.x, so the target version you choose sets the path. Ask for a schedule that separates the staging rehearsal from the production window and that names the rollback point for each step.
What must our team provide before the work starts?
You need to provide access and decisions, not only servers. The usual inputs are:
- Inventory of OpenSearch nodes, versions, plugins, index sets and retention settings
- Current Graylog server and MongoDB versions, plus the Graylog configuration files
- Backup storage with a tested snapshot repository and enough free capacity
- Named owners for change approval, DNS, certificates and the load balancer
- Agreed maintenance windows and a rollback decision owner
Graylog's installation docs recommend Data Node as the search backend, so decide early whether you are upgrading OpenSearch or switching to Data Node. Confirm the choice with Graylog's upgrade notes before you buy hardware.
Can our own engineers do the OpenSearch to Graylog move themselves?
Yes, if your team has operated Linux hosts, Graylog and a search cluster and can run controlled rolling restarts. OpenSearch documents installation through Docker, Helm, tarball, RPM and Debian packages, so the tooling is open. The risk sits in the details: snapshot restores that were never rehearsed, mismatched Graylog and OpenSearch versions, and TLS or certificate changes that break node joins. An internal team can do the work in-house, or bring in DeployOpen for planning, a rehearsed runbook and hands-on cutover support. DeployOpen implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure.
Does moving to Graylog Enterprise or Security change the licensing?
Yes, the license terms change with the edition you run, but the search backend move does not require a paid license by itself. Graylog Open is licensed under SSPL-1.0, which the LICENSE file describes as not an OSI-approved open source license, and it is free with community support. Graylog Enterprise adds a data lake, data tiering, a correlation engine and 24/7 support. Graylog Security adds SIEM features and needs OpenSearch 2.0 or later for its backend, according to the compatibility matrix. If you plan to use those features after the move, confirm the edition and backend version together before the upgrade.
What happens if we miss the Graylog 8.0 deadline?
Graylog's upgrade notes say OpenSearch 1.x support is deprecated in Graylog 7.0 and will be removed in Graylog 8.0, and that OpenSearch 1.x reached end of maintenance in May 2025. Staying on 1.x means running a backend that receives no further maintenance from OpenSearch, and the Graylog version that drops it would need a different backend before you can move forward. Teams that delay usually face a rushed upgrade in a single window, which raises the risk of data loss or failed node joins. Plan the move on your own schedule, and confirm the exact 8.0 release date with Graylog before you commit to a date.
Should we upgrade OpenSearch or switch to Graylog Data Node?
Choose based on the Graylog version you are targeting and the operating model you want to keep. Upgrading OpenSearch keeps your current cluster design and suits teams that already run it well, but you must match the OpenSearch version to the Graylog compatibility matrix. Switching to Data Node aligns with Graylog's recommended search backend and is the path its multi-node guide uses for medium to large deployments, with three Data Nodes on their own cluster. Either way, you will need snapshots, a rehearsal and a rollback plan. Ask for both options costed against your current node count, so the decision rests on your data volume and staffing.
What checks confirm the migration worked?
Confirm the cluster health, the Graylog node connection status, index counts and document counts for each index set, and a sample of searches that match results from before the cutover. Also check that retention still deletes the oldest indices as configured, that inputs still receive messages and that the message journal drains without backlog. Record the results in a runbook that names who signed off each step. These checks produce evidence for your own change records, and an independent auditor decides whether that evidence meets any framework requirement.
What the work needs from your team
Start by confirming what DeployOpen needs before any work begins, because the written scope depends on it. The team must supply administrative access to the Graylog server nodes, the MongoDB deployment that holds Graylog configuration, and every OpenSearch 1.x node that stores log indices. Access should be scoped to the hosts and cluster APIs named in the scope, with credentials handled under your own secrets process. Confirm also which network paths exist between the Graylog nodes, the OpenSearch cluster and any Data Node hosts, since the upgrade path you choose changes which of those paths must be open.
Name one owner for each area before the work is scheduled: a Graylog administrator who approves configuration changes, an OpenSearch or platform owner who controls the cluster and its certificates, and a business owner who can accept or reject the log retention and search behavior after cutover. Ask for change windows in writing, including who can halt a step if search or ingest degrades. Because OpenSearch 1.x support is removed in Graylog 8.0, agree on the target Graylog 7.x version and the backend version before choosing dates, and confirm the upgrade rehearsal window your environment allows.
Backups are a precondition, not a deliverable you can skip. Confirm that you can take a verified snapshot of the OpenSearch indices and a MongoDB backup that restores into a non-production environment, and that someone on your team can run the restore. Provide a test copy of representative log data or an approved sample, along with the index sets, streams and processing pipelines that route it, so the team can check that searches, dashboards and event definitions return the same results after the move. DeployOpen delivers the written plan, the upgrade and rollback steps for the environment you name, the verification checklist, and documentation of what changed. It does not issue compliance attestations on the result.
How DeployOpen scopes and delivers this migration
DeployOpen treats the move off OpenSearch 1.x as a planned change to a running log platform, not a version bump. We scope the target backend, build and test it in your infrastructure, and hand over documentation your team can operate.
How we scope
- Inventory the current Graylog, MongoDB and OpenSearch versions, index sets and retention before choosing a target backend
- Confirm the Graylog 7.x release you will run against the compatibility matrix and the OpenSearch or Data Node version it supports
- Record which features need OpenSearch 2.0 or later, including Graylog Security, so the target is set early
- Agree the written scope, deliverables and timeline in writing before any work starts, as engagements are fixed-scope
How we build
- Build the target search backend in a staging copy of your environment using the install path your standards allow
- Rehearse the cutover with a verified backup and a documented rollback path for each backend change
- Check that inputs, streams, pipelines, event definitions and dashboards still behave as before after the move
- Test certificates, authentication and access controls on the new backend before production traffic is switched
How we hand over
- Provide a runbook covering versions, the backend change, validation steps, rollback and post-migration checks
- Document the configuration, index rotation and retention settings your team needs to keep running the platform
- Walk your operations and security staff through the new backend, monitoring and backup routines
- Deliver evidence of what was tested and what was changed, so your team and auditors can review it later
How we support
- Offer ongoing support, upgrades and continuous testing through a retainer after the migration closes
- Plan the next Graylog 7.x upgrade and backend patching as recurring work agreed in writing
- Confirm with your team which support scope, response expectations and reviews you need before the retainer starts
- Keep the platform inside your own cloud accounts, data centers or air-gapped network throughout
