Migrating from Elasticsearch to OpenSearch.

Migrating from Elasticsearch to OpenSearch is rarely a purely technical decision. It begins with a license change and ends with a search cluster, and the work in between is mostly about scoping the move precisely so it does not become an open ended project. This guide walks the decision and the migration from the buyer side, with the license facts stated plainly and the engineering choices framed by what they cost.

Why the Elasticsearch license changed

In 2021, Elastic moved Elasticsearch and Kibana from the Apache 2.0 license to a dual model under the Server Side Public License and the Elastic License. The stated aim was to limit cloud providers from offering the software as a managed service without contributing back. Whatever the merits of that goal, the effect for buyers was a shift in terms on software many had adopted years earlier under a permissive open source license. Source available is not open source, and the Server Side Public License is not approved by the Open Source Initiative. As of 2026, Elastic has also added an open license option for newer versions, which complicates the picture rather than simplifying it, because the version you run determines the terms that govern it.

In response, Amazon Web Services led a fork of the last Apache 2.0 code, and OpenSearch was the result. OpenSearch is maintained under the Apache 2.0 license, which is what makes it the destination for buyers who want to return to an open license footing. The fork story is worth reading on its own, and we cover it in our piece on the OpenSearch fork story.

Should you migrate from Elasticsearch to OpenSearch?

The move is not automatic. For an internal search index that never leaves your own walls, the competitive use language in the Server Side Public License may not reach you at all, and the cost of migrating could outweigh a risk that does not apply. For a vendor that embeds search in a product sold to customers, or a platform that offers search as a service, the calculus changes. The honest first step is to map where Elasticsearch sits in your estate and how each instance is used, then decide. Migration is one of several valid answers, alongside staying on an Apache 2.0 version, adopting the newer open license option, or negotiating commercial terms with the vendor.

We weigh these paths in detail in our guide to the compliance obligations a database relicense creates. The point here is that you should reach the migration decision through a scoped review, not a reflex.

Step one: inventory every Elasticsearch instance

Start by finding every cluster, every index, and every application that talks to them. Software composition analysis will surface the libraries and clients, but Elasticsearch often hides in places a dependency scan misses, such as logging pipelines, observability stacks, and embedded search in third party tools. Record the version of each instance, because the version sets the license that governs it. A complete inventory turns the migration from a guess into a bounded list of named systems, ranked by how exposed each one is.

Step two: test OpenSearch compatibility against real workloads

OpenSearch began from the Apache 2.0 Elasticsearch and Kibana code, so early versions were close to a drop in replacement. The two projects have diverged since, in client libraries, in some query behaviors, and in the names of the dashboard tools. Do not assume parity. Stand up an OpenSearch cluster, point a copy of your real queries and mappings at it, and confirm that your client libraries connect and behave. The gaps you find here are the true scope of the migration, and they are far cheaper to find in a test than in production. Pay particular attention to client version pinning, because an application that hard codes an Elasticsearch client version is the most common source of breakage.

Step three: plan the data move and the cutover

Index data can move by reindexing from a snapshot or by replaying from the source of truth. Large indices take time to rebuild, so the data move is usually the long pole. Sequence the cutover by application rather than all at once. Move the lowest risk index first, validate it behind a test suite, then promote it. Run OpenSearch and Elasticsearch side by side during the transition so any regression can be reverted in minutes rather than rolled back across the estate. The side by side window costs some infrastructure for a period, and it buys you a safe path that does not bet the product on a single switch.

Step four: update clients and decommission cleanly

With data flowing to OpenSearch, update each application to the OpenSearch client and retire the Elasticsearch one. This is the step where the inventory pays off, because you already hold the list of every application to touch. Once traffic has fully moved and a rollback window has passed, decommission the Elasticsearch clusters and the versions that carried the source available terms. Update your software bill of materials to reflect the new state, so the next person to ask what governs your search has a current answer rather than a stale manifest.

What the migration does and does not solve

A clean migration to OpenSearch returns your search layer to an open license and removes the competitive use question that the Server Side Public License raised. It does not, by itself, fix the broader discipline gap that let the license change go unnoticed. The estate that ran Elasticsearch on terms no one had revisited probably runs other components the same way. The lasting value of the migration is the inventory it forces you to build, which becomes the asset that catches the next relicense at intake. The mechanics of the source available license itself are covered in our explainer on the Server Side Public License explained.

Migration work like this is the focus of our open source remediation advisory service. For the wider frame, read our pillar on Redis, Elastic, and database relicensing, and to understand how a relicense interacts with your hosting, see database relicensing and your cloud provider. Interpretation of whether your use is restricted is a question for your own counsel.