Best reasons to motivate company to update from ElasticSearch 2.1.1 to ElasticSearch 6.3.2?

[ujjain]

I'm looking to convince management of updating from ElasticSearch 2.1.1 to 6.3.2.

What would be primary reasons? I already have these:

• Not EOL
• Faster
• Less buggy
• Alerting for Monitoring & Security purposes
• Upgrading will only get harder

[shanec (Shane Connelly)]

A while ago I posted about going from 1.6 to 5.0. There are a number of the items I wrote about then that are also applicable to you at v2.1.

In addition, I'll link the release blog posts for the versions since then. We try to provide some short blurbs on bigger features that you may be interested in:

• 5.1
• 5.2
• 5.3
• 5.4
• 5.5
• 5.6
• 6.0
• 6.1
• 6.2
• 6.3

A few big things:

• In 6.0, we added a new feature that makes node restarts (and other types of "recovery") much faster.
• In 6.0, we changed the way the columnar store (doc_values) works to handle sparse values (common in many use cases) much better. It uses a lot less disk in those situations and can result in a lot faster queries as well.
• We added something called "Adaptive Replica Selection" which allows Elasticsearch to become aware of the load on nodes and reroute queries to the nodes that are less loaded. This tends to cut the latency of queries where you're in a noisy neighbor situation, like can be the case in some cloud/virtual environments.
• We added a task manager, which allows an administrator to inspect (and potentially kill off) tasks that are runaway.
• We added an SQL interface (and a way to translate SQL queries to Elasticsearch DSL for learning) and rollups for aggregating time-series data to our free x-pack features and a variety of other features including SAML, machine learning, and a variety of security features and others to our paid x-pack features.
• We didn't just fix bugs, but we added new safety measures and debugging tools. For example, if you've ever had a "red" index, we've fixed a number of the resiliency bugs and we've also added a "cluster allocation explain" API which can tell you why Elasticsearch may be unable to allocate a shard to give you hints on how to resolve.
• We added a lot of text search features. A new highlighter which combined the benefits of the "old" highlighters, so if you're using highlighting, this is generally a better way forward, field collapsing which lets you do something like "only return 3 of each model of car in my search result," better multi-word synonym support, indices that can be pre-sorted for much faster querying, a new "significant_text" aggregation which works like the "significant terms" aggregation but for text fields, a collation keyword field for sorting in language-specific orders, and others
• We added a sort of cluster-federation component called cross-cluster search. As the name implies, it allows you to stand up a node that can query multiple downstream clusters. It's loosely akin to Tribe node, but addresses a huge number of architectural and deployment problems with Tribe
• We added a few entirely new field types in a group we call "range fields." These can represent entire ranges in a single field value. For example a range of dates/times, a numeric range, an IP range. There are new use cases that some users have built on top of these, but it will depend on your use case.