Graylog major and minor upgrades whose documented breaking changes need planning: runtime and database prerequisites, API changes and parsing changes.
Upgrading Graylog 6.x to 7.0: Java 21, MongoDB 7.0 minimum and stepwise MongoDB upgrades, Kafka broker 2.1 minimum, the Data Warehouse to Data Lake rename, new API token defaults, entity creation API changes that break automation, and OpenSearch 1.x deprecation.
What changes for a running Graylog when moving to 7.2: plain-text entity suggestion queries, case-insensitive matching on paginated APIs, Okta and CEF field changes that affect parsing rules and dashboards, and new health checks to watch afterward.
Upgrading from Graylog 5.2 to 6.0: the required data_dir setting, plugins rebuilt for the jakarta namespace, renamed JVM metrics, stricter template comparisons and CPU-based processor defaults.
Stepping through the Graylog 6.x minor releases one at a time: API error type changes in 6.1, the removed GreyNoise Community adapter, the report creator role in 6.3 and new input type permissions.
Bringing MongoDB up to the version Graylog 7 requires: the 7.0 minimum, the supported range up to 8.2, replica set upgrade order, backups and why skipping preflight checks is a bad idea.
Upgrading Graylog across several nodes: backup first, MongoDB and OpenSearch before Graylog, all nodes on the same version before the next step, Data Node after Graylog, and keeping inputs flowing through the journal.
Upgrading a Docker Compose Graylog stack: image tags for Graylog, Data Node and MongoDB, upgrade order between containers, volumes to back up and checking the journal drains after restart.
Fixing in-house plugins and scripts that break on upgrade: jakarta and MessageFactory changes in 6.0, the MongoCollection wrapper in 6.3, and the CreateEntityRequest structure and strict JSON validation in the 7.0 API.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.