Overview of an Elasticsearch to OpenSearch migration
Moving from Elasticsearch or a managed search service to self-hosted OpenSearch changes the engine, the data path and the operating model at the same time. The source version decides the method. OpenSearch is a fork of open source Elasticsearch 7.10 and is wire-compatible with it. It can use indices from Elasticsearch 6.0 through 7.10 and supports rolling upgrades from those versions, so a source in that range may move in place, one node at a time. Older clusters and sources outside that range usually need snapshot and restore, remote reindexing or Migration Assistant. Confirm the exact path in the migration documentation before you choose.
Most teams start this work for one of three reasons. The first is a license and cost review. OpenSearch is released under the Apache License, Version 2.0, and its FAQ does not describe a paid edition, so the comparison shifts to hardware, storage, retention and the people who run the cluster. The second is exiting a managed search service, which means rebuilding snapshot policy, security settings and client endpoints in-house. The third is control over hosting, data residency and network placement. Each trigger sets different requirements for the cutover window and the rollback plan.
Choosing between an internal team and a partner depends mainly on three factors: the version gap between source and target, the data volume that must be moved and verified, and the number of clients, applications or teams that send indexing or query traffic. A small gap, modest volume and a single client often suit an internal team with a tested runbook. Large gaps, very large indices or many dependent applications increase the testing and cutover work. Before you compare quotes, ask for a written scope that names the source version, the method, the cutover approach and the rollback steps.
What the migration work includes
Each work package ends with a named deliverable that your team keeps after the migration. Sequence and scope are agreed in writing before work starts.
Source inventory and compatibility review
The partner catalogs the source cluster versions, node roles, indices, index templates, mappings, snapshot repositories, plugins, ingest pipelines, client libraries and Dashboards saved objects. OpenSearch is wire-compatible with Elasticsearch 7.10 and can use indices from 6.0 through 7.10, so the source version determines which migration methods apply. Deliverable: a signed inventory and compatibility report.
Migration method selection
OpenSearch documents four methods: rolling upgrades, snapshot and restore, remote reindexing and Migration Assistant. Each depends on the source version, the downtime your services can accept and the data volume to move. Migration Assistant can move workloads across several major versions in one step and supports live traffic capture. Deliverable: a method decision record with the reasons for the chosen approach.
Target cluster build and sizing
The partner installs the target OpenSearch version with the deployment method your platform team runs, such as Docker, Helm, the Kubernetes Operator, tarball or Linux packages. Node roles, dedicated cluster manager nodes, replicas on separate nodes and shard allocation awareness are configured before any data moves. Deliverable: a validated target cluster with a build record.
Security and access setup
Authentication backends, TLS for node and client traffic, role mappings and index permissions are rebuilt on the OpenSearch Security plugin and reviewed against the source access model. Confirm which backend your identity provider supports, such as SAML, OpenID Connect, LDAP or Active Directory. Deliverable: an access matrix and tested role mappings.
Client and Dashboards migration
Application clients, ingest agents, Logstash outputs and Dashboards saved objects are repointed and tested against the target cluster. OpenSearch Dashboards derives from Kibana 7.10.2, so saved objects created in later Kibana releases need a compatibility review. Confirm each client library's supported OpenSearch version with its maintainer. Deliverable: a client inventory with test results and updated connection settings.
Cutover, rollback and handover
The partner runs the agreed cutover window, keeps the source cluster available for rollback, and records each step in a runbook. Monitoring, snapshot schedules and on-call procedures transfer to your team in a handover session. Confirm how long the source cluster must stay available with your data owners. Deliverable: a cutover runbook, a rollback plan and a handover pack.
What drives migration cost and duration
This table lists the factors that most change the effort of moving from Elasticsearch to OpenSearch, why each one matters, and what to do to keep it under control.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Source version distance | OpenSearch is wire-compatible with Elasticsearch 7.10 and can use indices from Elasticsearch 6.0 through 7.10 with rolling upgrades. Older or newer sources fall outside that path and need snapshot and restore, remote reindex or Migration Assistant. | Confirm your exact source version first. Where you are inside the 6.0 to 7.10 range, a rolling upgrade is usually the simplest route. Outside it, plan a method that does not depend on that path. |
| Data volume and index count | Snapshot transfer, reindexing time and validation scale with stored data and the number of indices. Many small indices add more work per index than a few large ones. | Measure primary store size and index count before scoping. Remove stale indices and expired data before the move, and confirm whether retention rules should change at the same time. |
| Client applications and language libraries | Each application that talks to the cluster must be checked against OpenSearch client libraries and any Elasticsearch-specific calls. Libraries that assume the Elastic product name or licensed features need testing and sometimes replacement. | Build an inventory of applications, clients and versions. Test the highest-traffic and most custom integrations first in a non-production cluster. |
| Kibana or Dashboards objects | Saved searches, visualizations, dashboards and index patterns from Kibana 7.x must be exported, imported and reviewed. Objects that use unsupported visualization types or plugins need rework. | Export saved objects, list the visualization and plugin types in use, and decide which dashboards to rebuild rather than port. Confirm compatibility for each type against the Dashboards version you choose. |
| Security and SSO configuration | Roles, users, tenants, TLS settings and SSO mappings in the Elastic security layer must be recreated in the OpenSearch Security plugin. Mapping backend roles to security roles often takes the longest decisions. | Export current role and user definitions, document which identity provider protocol you will use, and agree the role model with the data owners before the cutover window. |
| Number of environments | Development, test, staging and production each repeat the migration steps, and differences between them create rework and surprises at cutover. | Keep environment configuration in version-controlled code and run the same runbook in every environment. Limit the number of environments that need separate validation. |
| Downtime tolerance | A rolling upgrade keeps the cluster available but needs careful sequencing. Snapshot and restore usually means a write freeze or a catch-up step. Migration Assistant with live traffic capture is designed for low or zero downtime but adds components to build and run. | Ask the business owners for the acceptable write pause and read impact. Choose the method against that limit, and test the cutover and rollback steps with timed rehearsals. |
| Compliance evidence needs | Assessors may expect records of the migration plan, approvals, access changes, audit log settings, data integrity checks and retention controls. Producing this evidence takes time that is separate from the technical work. | Agree the evidence list at scoping. Capture configuration exports, test results and change approvals as the work happens. DeployOpen prepares evidence for assessments, but independent auditors issue the findings. |
Migration phases and outputs
Each phase produces a named output and closes on a decision, so the move from Elasticsearch to OpenSearch stays controlled from inventory through handover.
Discover and inventory the source estate
The platform team maps every Elasticsearch cluster, index, alias, index template, ingest pipeline, snapshot repository, plugin, client application and Kibana object, and records each version. They confirm which indices were created on versions 6.0 through 7.10, since OpenSearch can use those indices. The phase closes with a signed inventory and a list of open decisions.
Design the target OpenSearch cluster
The architecture owner sets the OpenSearch version, deployment method, node roles, dedicated cluster manager layout, replica placement, identity integration and security model. Dashboards and the snapshot repository are designed in the same pass. The phase closes with an approved target architecture record and sign-off from the platform and security owners.
Select method and run a pilot
The team chooses rolling upgrade, snapshot and restore, remote reindex or Migration Assistant for each workload, based on source version, downtime tolerance and whether data must be copied. They run the chosen method on one non-critical index set. The phase closes with an agreed method, a tested runbook, documented rollback steps and recorded pilot results.
Test migration and validate results
The team runs a full test migration into a non-production cluster built to the target design. They compare document counts, mappings, settings, aliases and sample query results between source and target, and check index health and client requests. The phase closes when every difference is explained or fixed and the cutover runbook is approved.
Cut over production traffic
The operations team freezes or captures writes as the chosen method requires, moves the final data, and switches application endpoints to OpenSearch. Where Migration Assistant is used, they confirm capture and replay status before switching. They verify index health, document counts and key search results afterward. The phase closes when the business owner accepts production on OpenSearch.
Switch Dashboards and client connections
The team moves Kibana saved objects into OpenSearch Dashboards, which derives from Kibana 7.10.2, and confirms the import path for the version in use. They check visualizations, index patterns and alerting that depend on them, update client libraries and configuration, and map user roles in the Security plugin. The phase closes when dashboard owners and client teams confirm their workflows.
Decommission Elasticsearch and hand over
The team keeps the source cluster read-only for an agreed period, takes a final snapshot, then shuts it down and removes its access paths. They hand runbooks, architecture records, backup and restore procedures and monitoring to the operations team. The phase closes with a decommissioning record, a signed handover and a plan for ongoing OpenSearch maintenance releases.
How the migration differs by starting point
Clusters on Elasticsearch 7.10 or earlier usually have the most in-place path. OpenSearch is wire-compatible with 7.10, can use indices from versions 6.0 through 7.10, and supports rolling upgrades from those versions.
- Method: rolling upgrade, one node at a time, so the cluster stays available while each node is replaced.
- Tooling: OpenSearch tarball, RPM, Debian packages or Docker images, managed through your existing configuration tooling.
- Cutover: usually minimal client change because the wire protocol matches, but confirm client library versions with the vendor.
- Checks: confirm plugin compatibility and index versions before the first node moves, and keep a verified snapshot as the rollback point.
Clusters on Elasticsearch versions later than 7.10 fall outside the wire-compatible, rolling upgrade path, so the method is evaluated case by case. Migration Assistant can move workloads across several major versions in one step and supports live traffic capture for low or zero downtime. Snapshot and restore or remote reindexing remain options when data volume and timing allow them.
- Method: compare Migration Assistant with snapshot and restore or remote reindexing against index count, data volume and downtime tolerance.
- Tooling: a Migration Assistant deployment in your environment, configured for your source and target. Confirm supported source versions in the current documentation.
- Cutover: live capture can keep writes flowing during the move, so plan a validation window before switching clients.
- Checks: test application code against OpenSearch clients, since libraries written for newer Elasticsearch clients may need changes.
Managed search services often limit direct access to the cluster, including snapshot repositories, so the first step is confirming what the provider exposes. The method depends on whether you can take a snapshot you can restore elsewhere or must reindex through the search API.
- Method: snapshot and restore if the provider allows a repository you can read, otherwise remote reindexing through the search API.
- Tooling: an OpenSearch target that you run, plus a network path to the source endpoint. Confirm the provider's access and egress rules in writing.
- Cutover: plan a write freeze or dual writes, because snapshots and reindex runs capture data at a point in time.
- Checks: confirm which plugins, index settings and snapshot formats the service uses, and whether any are unsupported on OpenSearch.
Kubernetes deployments add a control layer to the migration. OpenSearch documents installation with Helm and the OpenSearch Kubernetes Operator, and both affect how the target cluster is built and how endpoints change at cutover.
- Method: the same method that fits the source version (rolling upgrade, snapshot and restore, remote reindexing or Migration Assistant), applied to the new cluster.
- Tooling: Helm charts or the OpenSearch Kubernetes Operator to deploy target nodes, with persistent volumes sized before data moves.
- Cutover: change Service or Ingress endpoints in a planned window, and keep the old and new clusters reachable during validation.
- Checks: confirm chart or operator versions match the target OpenSearch release, and test snapshot repository access from the pods, including storage class and credentials.
In an air-gapped network, nothing is downloaded during the migration. Every package, container image, plugin and snapshot repository must be staged inside the enclosure before work starts.
- Method: choose the method your network allows. Snapshot and restore needs a shared repository reachable from both clusters, and Migration Assistant needs its images and dependencies staged.
- Tooling: stage tarball, RPM or Debian packages, or container images through your approved transfer process. The install documentation lists these options.
- Cutover: there is no internet fallback, so rehearse the cutover on a copy and confirm every artifact is present.
- Checks: record checksums for staged artifacts and confirm the OpenSearch version in the staged set matches the planned target.
What usually goes wrong and how to prevent it
Six failure modes appear often in Elasticsearch to OpenSearch moves. Each card gives a prevention step and a check to run before cutover.
Mapping and analyzer drift
Index mappings and analyzers are copied from the source cluster, but search results can still change where the engines differ on defaults or analysis chains. Export every mapping and analyzer, replay a sample of production queries against both clusters, and compare hit counts and ranking on documents you already know.
Clients assuming Elasticsearch features
Application code, language client libraries, Beats, Logstash pipelines and agents may check server versions or call APIs that behave differently on OpenSearch. Inventory each client with its version and endpoints, then confirm every call path against OpenSearch compatibility notes in a staging environment before cutover.
Kibana saved objects that do not import cleanly
Dashboards, visualizations, index patterns and saved searches built in Kibana 7.10.2 do not always carry over intact into OpenSearch Dashboards. Export saved objects from the source, import them into a staging Dashboards instance, and open each dashboard to check panels, index pattern references and any plugin-based visualizations that fail to render.
Lost roles, mappings and TLS settings
Roles, role mappings, internal users, tenants, TLS certificates and audit settings often live only in the source cluster's configuration and are missed during the move. Export the security configuration, rebuild it in the OpenSearch Security plugin model, reissue node and client certificates, and test that each user can reach only the indices they should.
Under-sized target nodes
Nodes sized for the old workload can run short of heap, disk or shard headroom once the migration adds replicas, new indices or longer retention. Model the target with current data volume, shard count, replica count and peak query load, then load test with a copy of production data and watch disk watermarks and heap pressure.
Unreachable snapshots and untested rollback
A rollback plan depends on a snapshot repository that both the source and target clusters can reach, and teams often discover that the repository is misconfigured or lacks credentials only during an incident. Register the repository from both sides, take and restore a test snapshot, and rehearse the full rollback on a production copy before the cutover window.
What teams keep in-house and what they outsource
This table splits the Elasticsearch to OpenSearch migration into work usually kept in-house and work often outsourced, with the skills each part requires so you can see where your team's gaps sit.
| Work area | Who usually owns it | Skills required |
|---|---|---|
| Validating search results | Application owners | Knowledge of expected query results, relevance expectations, and sample queries that represent real user behavior |
| Confirming retention and access rules | Data owners and security | Understanding of which indices hold regulated data, retention obligations, and who may read or change each index |
| Approving change windows and cutover | Change advisory board | Ability to weigh rollback risk, freeze periods, and business impact against the migration plan |
| Choosing the migration method | Outsourced or shared with platform team | Comparing rolling upgrade, snapshot and restore, remote reindex, and Migration Assistant against source version, data volume, and downtime tolerance |
| Building the target cluster | Outsourced or platform team | OpenSearch install methods, node role design, dedicated cluster manager nodes, and shard allocation awareness |
| Deploying Migration Assistant and validation scripts | Outsourced or platform team | Kubernetes or container operations, capture and replay concepts, and scripting for document count and query comparisons |
| Configuring security and cutover runbook | Outsourced, reviewed by internal security | Security plugin configuration with TLS, roles and authentication backends, plus clear rollback steps and client switchover planning |
What you need to provide before work starts
The migration design cannot start until you provide access to the source cluster and its snapshot repositories. Give the migration team read access to cluster state, index settings and snapshot APIs, with credentials issued for this project rather than a personal account. Confirm that the snapshot repository is reachable from the target network, because snapshot and restore depends on it and the other migration methods depend on the same source access.
Provide an inventory of indices, aliases, index templates, ingest pipelines and every client application that reads or writes them. Each client application needs a named owner who can approve test results and sign off cutover. Without an owner, nobody can decide whether an application that uses an older Elasticsearch client library or deprecated APIs is ready to move.
Classify each index by sensitivity and retention requirement, and record which data should be deleted rather than copied. Also decide the target OpenSearch version. Since 3.9.0 was released on September 29, 2026, confirm whether you will land on a 2.x or 3.x line, because that choice determines plugin compatibility and the upgrade path you will need later. Agree change windows with application owners and document the rollback tolerance: how long the business can run on the source cluster if the target fails.
Confirm with your vendor or license agreement: OpenSearch is released under Apache License 2.0, but your Elasticsearch or managed search contract governs what you may export, retain or decommission on the source side. Check whether your terms allow snapshot export and any migration tooling you plan to use, and whether any Elastic-only features your clusters rely on need a replacement before cutover.
Migration questions buyers ask
How much does it cost to migrate from Elasticsearch to OpenSearch?
OpenSearch itself carries no license fee, because all software in the project is released under the Apache License, Version 2.0. The quote comes from the work and infrastructure around it: the source version and the migration method it allows, data volume and index count, the number of clients and pipelines to check, security role and authentication mapping, Dashboards content review, test cycles and cutover support. One-time work covers planning, migration and testing. Recurring costs cover hardware or cloud instances, storage, and the engineers who operate the cluster. Ask any provider for line items split into one-time and recurring costs, with assumptions stated.
How long does an Elasticsearch to OpenSearch migration take?
The duration depends on scope, and no single timeline applies across environments. The main drivers are the source version, the number of clusters and indices, total data volume, how many applications and pipelines connect to the cluster, how much custom security and dashboard content must carry over, and how much testing your change process requires. A rolling upgrade on a small cluster is a different project from a multi-cluster move with live traffic capture. Ask for a timeline tied to a written scope with named phases, test gates and cutover windows, and check which assumptions about your data and environment it depends on.
Can our own team migrate from Elasticsearch to OpenSearch without a partner?
Often yes, if your team already runs Elasticsearch in production and has time for planning and testing. Teams usually check four things first: whether the source version matches a method OpenSearch documents for it, whether existing Elasticsearch security features map to roles the team can support, how clients and pipelines behave against the target, and who owns rollback. Gaps tend to appear in cutover testing and in dashboard and role migration, where experience with both platforms matters. Compare an internal plan with a partner's written scope, and decide based on the skills and staffing you actually have.
Does migrating to OpenSearch require downtime for our applications?
It depends on the method and the cutover design, so confirm it against your own environment. A rolling upgrade replaces nodes one at a time and can keep the cluster serving, but it applies to indices from Elasticsearch 6.0 through 7.10. Snapshot and restore and remote reindexing typically involve a data copy and a switch of clients to the new cluster, so the write window needs planning. Migration Assistant supports live traffic capture for low or zero downtime, which suits workloads that cannot pause ingestion. Define the acceptable write gap and the rollback path before you choose a method.
Which OpenSearch migration method fits our Elasticsearch version?
Start with your source version, since it decides which paths are available. OpenSearch is wire-compatible with Elasticsearch 7.10, can use indices from Elasticsearch 6.0 through 7.10, and supports rolling upgrades from those versions. For jumps across several major versions, Migration Assistant can move workloads in one step, for example from Elasticsearch 6.8 to OpenSearch 2.19. Snapshot and restore and remote reindexing fit cases where you rebuild data on a new cluster. Test the chosen method on a copy of your largest index before committing to it.
Do our Elasticsearch client applications need code changes after migrating?
Often not for workloads that already target Elasticsearch 7.10, because OpenSearch is wire-compatible with that version. Still, confirm each client library, query, mapping and API call against the target version before cutover. Differences tend to show up in client library versions, deprecated features, index settings and vendor-specific calls. Applications that use newer Elasticsearch features, or that check the server product name or version, may need changes. Build a compatibility inventory from your code and logs, run the test suite against the target cluster, and treat each failure as a change item in the scope.
What happens to Kibana dashboards and security roles after migration?
They need a deliberate review, because OpenSearch Dashboards derives from Kibana 7.10.2 and access control comes from the OpenSearch Security plugin. Dashboards, visualizations, index patterns and saved searches should be exported, imported and tested against the target, with any unsupported plugin content listed separately. Roles, users and authentication backends must be mapped again. The Security plugin provides role-based access control, document-level and field-level security, field masking and audit logs, and it supports SAML, OpenID Connect, LDAP and Active Directory. Plan this mapping before cutover so that access is never widened by accident.
How DeployOpen runs OpenSearch migrations
DeployOpen plans and carries out the move from Elasticsearch or a managed search service to self-hosted OpenSearch inside infrastructure you control. The work starts with the method that fits your source version, data volume and tolerance for downtime, then proceeds through a tested cutover.
How we scope
- The written scope names your current Elasticsearch or managed service version and the target OpenSearch version.
- It records which migration method applies: rolling upgrade, snapshot and restore, remote reindex or Migration Assistant.
- It lists client libraries, indices, pipelines and Dashboards objects that must keep working after cutover.
How we build
- We stand up the target cluster with planned node roles, dedicated cluster manager nodes and replicas on separate nodes.
- We run the chosen migration method in a non-production copy first and record the results for each index.
- We check client compatibility and query behavior against representative workloads before any production traffic moves.
How we hand over
- You receive the migration runbook, cutover and rollback steps, and the verification checks used at each stage.
- Documentation covers cluster topology, the security configuration and the snapshot schedule for the new environment.
- Your operators walk through the runbook with us so they can repeat the steps on later index sets without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
- We can plan later moves within the OpenSearch maintenance cycle, including minor releases and the move to a new major version.
- Before work starts, confirm with us in writing which post-cutover support hours and response expectations apply.
