// service / migration
Graylog migrations with a plan for every message
New provider, new hardware, new major version or a new search backend. Migrations fail in the details: index compatibility, collector cut-over and what happens to the logs in between.
- phase.1:
- inventory & dependency map
- phase.2:
- target build (parallel)
- phase.3:
- config migration & validation
- phase.4:
- dual-shipping where possible
- phase.5:
- collector cut-over
- rollback:
- defined before phase.5 starts
Graylog 7.0 deprecated Elasticsearch and OpenSearch 1.x as search backends, with removal planned for Graylog 8.0, and it requires MongoDB 7.0 or later and Java 21. Many long-running environments are several steps behind that. A migration is often the moment to fix years of accumulated drift at the same time.
We inventory the existing environment first — inputs, streams, pipelines, index sets, dashboards, alerts, users and collectors — then decide what moves as-is, what gets rebuilt, and how historical data is handled: migrated, kept read-only for its remaining retention, or deliberately aged out.
// scope
Migration types we handle
Server & provider moves
On-premises to cloud, cloud to cloud, or VPS to dedicated hardware — for example to Hetzner for cost or to AWS to sit next to workloads.
Version upgrades
Stepwise upgrades through supported versions, following the vendor's documented upgrade paths and compatibility requirements.
Elasticsearch → OpenSearch / Data Node
Moving off deprecated search backends to Graylog Data Node or self-managed OpenSearch.
MongoDB upgrades
Stepping MongoDB through required versions with backups and validation at each stage.
Single node → cluster
Re-platforming a single server into a clustered architecture without losing configuration.
Other stacks → Graylog
Moving collection from ELK, rsyslog files or ad-hoc tooling into a structured Graylog setup.
// deliverables
What you receive
- Inventory of the current environment and its dependencies
- Migration plan with cut-over and rollback steps
- Target environment built and validated in parallel
- Post-migration verification: inputs, streams, alerts, searches
- Decommissioning checklist for the old environment
// faq
Common questions
Can historical logs be migrated?
Often, but not always worth it. Depending on source and target backends, data can be reindexed, snapshot-restored where compatible, or left on the old cluster in read-only mode until it ages out. We compare cost and risk per option.
Will we lose logs during cut-over?
The goal is no. Where collectors support it we dual-ship to old and new environments, then cut over. For protocols without retries, such as UDP syslog, we minimise the window and document it.
Do dashboards, streams and alerts move?
Configuration lives in MongoDB and moves with it on same-version or supported upgrade paths. Content packs and the API help when rebuilding selectively. We verify each item after migration.
// related services
Independent service provider — not affiliated with Graylog, Inc. Software licensing is subject to the applicable vendor license. Licensing notes.
You have logs. We build and operate the infrastructure that makes them useful.
Tell us about your environment. An engineer will reply with a first architecture outline.