Elasticsearch vs OpenSearch: the migration decision.

The Elasticsearch to OpenSearch migration decision became live for many enterprises after the Elastic license change of 2021 moved Elasticsearch and Kibana to source available terms. OpenSearch is the AWS led fork that continues the function under the Apache 2.0 open source license. On the surface the choice looks binary: stay on source available terms or move to an open source fork. In practice it is a weighing exercise across license posture, compatibility, engineering cost, and the maturity of each project, and the right answer differs by deployment. This article frames that decision the way a buyer side advisor would.

It sits within the wider cluster on Redis, Elastic and database relicensing, and assumes you have already read what the change did, covered in the Elastic license change explained.

Start with whether you have a problem at all

Before weighing the migration, confirm that the Elastic license change actually reaches your use. The central restrictions of the Server Side Public License and the Elastic License are aimed at offering the software to third parties as a service. A company that runs Elasticsearch internally to power its own search and analytics usually sits comfortably inside the Elastic License and faces no forced choice. The exposure concentrates in companies that host or resell the function. If your use is purely internal, the migration decision may be one of preference and future proofing rather than necessity, and that changes how much engineering cost is worth spending. The first step is the question posed in is your Elasticsearch use affected.

The license posture each path gives you

OpenSearch is licensed under Apache 2.0, a permissive open source license approved by the Open Source Initiative. Moving to it restores the open source footing that Elasticsearch had before 2021 and removes the managed service and feature gating restrictions that the source available terms introduced. Staying on Elasticsearch leaves you on the Elastic License or the Server Side Public License, unless you adopt the GNU AGPL option that Elastic added as of 2024. The AGPL is genuine open source, but it is strong copyleft with a network clause, so it is not a clean equivalent to Apache 2.0. The cleanest license posture is OpenSearch, the most familiar one is the Elastic License, and the AGPL sits between them with obligations of its own.

Compatibility and the cost of moving

OpenSearch began as a fork of Elasticsearch 7.10, the last Apache 2.0 release, so older deployments often migrate with limited friction. The two projects have diverged since, which means newer Elasticsearch features, client libraries, and APIs may have no exact OpenSearch equivalent. The migration cost is driven by how far your deployment has moved past the fork point and how deeply your applications are coupled to Elasticsearch specific behavior. Index mappings, query syntax, ingest pipelines, and client versions all need checking. A migration that looks trivial at the cluster level can carry real work at the application layer, which is why a compatibility assessment precedes any commitment. The mechanics are set out in migrating from Elasticsearch to OpenSearch.

When staying on Elasticsearch is the right call

Migration is not always the answer. If your use is internal and sits inside the Elastic License, if you depend on Elasticsearch features that OpenSearch does not match, or if the AGPL option gives you an acceptable open source path, staying can be the lower risk choice. A forced migration that breaks search relevance or ingestion can cost more than the license concern it was meant to solve. The discipline is to let actual use and real migration cost drive the decision rather than a reflex against source available terms. This is the same calculus that applies across the relicensing wave, framed in forking versus paying, the database decision.

How to make the decision defensible

A defensible Elasticsearch to OpenSearch migration decision rests on three inputs: a clear read of how each instance is used, a compatibility assessment against the specific version and features you run, and an honest estimate of migration cost and elapsed time. Set those against the value of a cleaner license posture, and the right path usually becomes obvious. Document the reasoning, because the same record answers a board question, a procurement review, or a future audit. The decision is not permanent either, since OpenSearch and Elasticsearch continue to evolve, so revisit it when your version or your use materially changes.

This article is commercial and licensing risk advisory, not legal advice. For interpretation of the Elastic License, the Server Side Public License, the AGPL, or the OpenSearch license against your specific deployment, your own counsel is the right place to turn.