Kibana and Elasticsearch upgrade order: which component to upgrade first on a production cluster

Direct answer

Upgrade Elasticsearch first, then Kibana, to the same minor version. This is the documented and safer order for a minor upgrade within the same major release. Kibana is designed to work with a range of Elasticsearch versions, but Elasticsearch does not guarantee backward compatibility with an older Kibana. Running a newer Kibana against an older Elasticsearch is unsupported and will cause startup failures or saved-object migration errors.

Why Elasticsearch-first works

During a rolling Elasticsearch upgrade, your cluster temporarily runs a mix of old and new nodes. Kibana, still on the old version, can continue to serve dashboards because it tolerates a newer Elasticsearch within the supported version range. Once all Elasticsearch nodes are upgraded, you upgrade Kibana. The reverse order—Kibana first—risks Kibana refusing to connect to the older cluster or attempting saved-object migrations against incompatible system indices.

Minimal production steps

1. Disable shard allocation to prevent rebalancing during node restarts:

   curl -X PUT 'localhost:9200/_cluster/settings' -H 'Content-Type: application/json' -d '{"persistent":{"cluster.routing.allocation.enable":"none"}}'

2. Stop one Elasticsearch node, upgrade its package, and start it.
3. Re-enable shard allocation and wait for cluster health to return to green:

   curl -X PUT 'localhost:9200/_cluster/settings' -H 'Content-Type: application/json' -d '{"persistent":{"cluster.routing.allocation.enable":null}}'
   curl 'localhost:9200/_cluster/health?wait_for_status=green'

4. Repeat for each remaining node.
5. After all nodes are upgraded, stop Kibana, upgrade it to the same version, and start it.
6. Verify both report the expected versions:

   curl 'localhost:9200'
   curl 'localhost:5601/api/status'

Observable signals

Hard stops—treat these as blocking errors, not warnings:

• Kibana logs a version mismatch error such as This version of Kibana is incompatible with Elasticsearch.
• Saved-object migration failures that halt Kibana startup, often with Unable to complete saved object migrations.
• Elasticsearch rejecting Kibana's requests with incompatible version errors.

Tolerable transitional warnings during the Elasticsearch-first window:

• Kibana may log deprecation warnings about APIs that changed in the new Elasticsearch version.
• Cluster health may briefly show yellow while shards relocate after each node restart—this is expected and resolves once allocation completes.

Rollback considerations

If Kibana migrates its saved objects during startup, there is no supported path back to the older Kibana version. Snapshot and restore of the system indices (e.g., .kibana*) across versions is not reliable because the saved-object metadata format changes. Plan your upgrade window accordingly: once Kibana starts and completes migration, rolling back requires restoring the entire cluster from a pre-upgrade snapshot taken before any component was upgraded, and even then, only if you also downgrade Elasticsearch. In practice, treat the upgrade as one-way after Kibana begins its migration.

For exact version compatibility, consult the official Elastic Stack compatibility matrix for your source and target versions, and read the upgrade guide for your specific version jump—especially if you are crossing a major version, which may require additional steps like reindexing.