|
1 | 1 | [[upgrading-elastic-stack]]
|
2 | 2 | == Upgrading the Elastic Stack
|
3 | 3 |
|
| 4 | +Every major and minor release of the Elastic Stack introduces new and powerful |
| 5 | +features, as well as important bug fixes and enhancements to existing features. |
| 6 | +At the same time, the Elastic team is constantly striving to improve performance, |
| 7 | +stability, and security. |
| 8 | + |
| 9 | +While upgrading requires an investment of your time and resources, it enables |
| 10 | +you to benefit from these improvements and opens the door to using the stack |
| 11 | +in new and better ways. You can minimize the impacts of upgrading by scheduling |
| 12 | +regular upgrades to ensure that you are running actively supported versions of |
| 13 | +Elasticsearch, Kibana, Logstash, and Beats. |
| 14 | + |
| 15 | +The longer you wait between upgrades, the more difficult the upgrade process |
| 16 | +becomes. If you lag behind more than one major release, when you do upgrade |
| 17 | +you’ll face full cluster restarts or reindexing, as well as a more significant |
| 18 | +development effort to migrate your applications. |
| 19 | + |
| 20 | +[discrete] |
| 21 | +=== Stack version compatibility |
| 22 | + |
4 | 23 | When upgrading to a new version of {es}, you need to upgrade
|
5 | 24 | each of the products in your Elastic Stack. Beats and Logstash 6.7 are
|
6 | 25 | compatible with {es} {version} to give you flexibility in scheduling
|
|
0 commit comments