What this service covers
OpenSearch upgrade and support work is paid for in labor, testing and operating time, not in license renewals. All software in the OpenSearch project is released under the Apache License, Version 2.0, and the project FAQ does not describe a paid edition. The cost of an upgrade therefore comes from planning, staging, rehearsal, the change window and the people who keep the cluster running afterward. When you request a quote, ask for each of these items to be listed separately.
Four conditions usually start upgrade work. The first is a release line approaching the end of its maintenance period. The second is a planned move from 2.x to 3.x, which is a major version change that should be tested as its own project. The third is a plugin or client that blocks the target version, such as a Dashboards plugin or an application client that has not been validated against it. The fourth is drift: a cluster installed with Docker, Helm, the Kubernetes Operator, a tarball or packages that has since been changed by hand, so the documented upgrade steps no longer match what is running.
Maintenance rules set the pace. OpenSearch releases a new minor version about every eight weeks. During maintenance, a version receives bug fixes and security patches but no new features, and version 2 is maintained through the 4.0 GA release. Maintenance periods and release timing can change, so confirm the current end-of-maintenance dates for your version on the OpenSearch releases page before you set a schedule, and plan against the dates you find there.
For many teams the split between in-house and partner work is straightforward. If you keep an upgrade calendar, run a staging cluster that mirrors production and have one person who owns the Security plugin configuration, routine minor upgrades can stay in-house. The major move from 2.x to 3.x and the first upgrade cycle after it are where outside help is most often used, because plugin compatibility, role mappings and client behavior can all change at once. Ask any partner to state in writing which upgrade methods are in scope, such as rolling upgrade, snapshot and restore, remote reindexing or Migration Assistant.
What the work includes
The work runs from inventory through a rehearsed cutover and into ongoing minor-release support. Scope is agreed in writing before work starts, and retainers cover ongoing minor-release handling.
Version and plugin inventory
The written inventory lists every OpenSearch and OpenSearch Dashboards node version, each installed plugin with its version, client libraries and the index settings that depend on them. It shows which components have a compatible target and which need replacing or removing before the move. Ask the team which plugins are custom or unofficial, since those need their own compatibility checks.
Runbook and staging rehearsal
Each target version gets a runbook with ordered steps, pre-checks, timing notes and rollback commands. The rehearsal runs the same steps on a copy of production data in a staging cluster, so the team measures durations and finds plugin or client failures before the window. Ask for the rehearsal report to record every deviation from the runbook.
2.x to 3.x migration plan
Moving from 2.x to 3.x changes more than a minor version, so the plan covers plugin compatibility, client libraries, index settings and the upgrade method chosen. It sets explicit rollback criteria, such as failed cluster health checks or query errors above an agreed threshold, and names who decides to roll back. Confirm the target 3.x minor release at planning time.
Window execution and post-upgrade checks
Work runs inside a maintenance window agreed in writing, with a named decision maker and a go or no-go checkpoint before each node change. After the upgrade, checks confirm Security plugin roles and role mappings, take a fresh snapshot and test a restore, and verify that application clients connect and index. Results are recorded in the cutover record.
Recurring support for minor releases
A retainer covers handling of minor releases, which the project targets about every eight weeks, including inventory updates, runbook revisions and rehearsals for each target. Versions under maintenance receive bug fixes and security patches but no new features, so the retainer should set which versions your team tracks. Ask how the support calendar schedules rehearsals around your change freeze dates.
Written deliverables
Five documents are delivered: the written inventory, the upgrade runbook, the rehearsal report, the cutover record and the support calendar. Because scope, deliverables and timelines are agreed in writing before work starts, ask for this list to be attached to the statement of work. Ask for the file formats and storage location to be stated in the scope as well.
What drives effort and duration
This table lists the factors that most change the work of an OpenSearch upgrade, why each one matters and how to keep it under control before the window opens.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Node count and roles | Each node role changes the restart order and the health checks between node restarts. | Inventory the role of every node and keep dedicated cluster manager nodes where the docs recommend them. |
| Data volume and index count | More shards and stored data lengthen restarts, shard recovery and snapshot verification. | Delete or close unused indices and review shard counts before the upgrade is scheduled. |
| Installed plugins | Each plugin needs a build that matches the target version, and some must be replaced or rebuilt. | List every plugin and confirm its status for the target version with the maintainer before planning. |
| Ingest pipelines and Dashboards objects | Pipelines and saved Dashboards objects can break when field names, processors or APIs change. | Export pipelines and Dashboards objects to version control and test them on a staging copy. |
| Clients and applications calling the API | Each client library, script and integration needs regression testing against the target version. | Build a client inventory, test the most critical calls first and check each client's compatibility claim. |
| Security plugin configuration depth | SAML, OIDC, LDAP or Kerberos backends and document or field-level rules add settings that must be retested. | Document backends, role mappings and access rules, and keep security configuration in version control for review. |
| Indices from Elasticsearch 6.0 to 7.10 | Older indices must be confirmed as compatible with the target, and some may need reindexing as a separate work stream. | Identify these indices early and decide for each one whether to reindex, migrate or retire it. |
| Number of environments | Each environment repeats the upgrade, test and sign-off work, and differences between them add rework. | Build environments from the same code and upgrade development first, then staging, then production. |
| Size of the maintenance window | A shorter window limits how many nodes restart and how much testing fits into one change. | Agree the window length and rollback point in writing and prepare the rollback steps before the window opens. |
Project phases and outputs
Each phase closes with a written output, so the go or no-go decision rests on evidence from your own cluster.
Inventory the current cluster
Record the OpenSearch version, install method (Docker, Helm, the Kubernetes Operator, tarball, RPM, Debian or Ansible), installed plugins, client libraries and their versions, and every index with the version it was created under. Output: an inventory that shows which indices and clients fall inside the rolling-upgrade range and which may need a Migration Assistant or reindex path.
Select the target version
Choose the target release and review its release notes against the inventory, checking breaking changes, plugin availability and client compatibility. For the move to 3.x, confirm whether any indices or clients predate the rolling-upgrade range, because that decides between a rolling upgrade and Migration Assistant or reindexing. Output: a written target decision record with the chosen path.
Rehearse the upgrade in staging
Restore a recent snapshot into a staging cluster that matches production topology and plugins, then run the chosen path from start to finish. Log every error, workaround and the time each stage takes on your data, because durations depend on your volume and should be confirmed from your own rehearsal. Output: a rehearsal log with each issue resolved or assigned.
Write the runbook and rollback plan
Turn the rehearsal log into a step-by-step runbook with commands, named owners, health checks and decision points. Define the rollback trigger and procedure, including which snapshot is restored and how clients are repointed. Output: an approved runbook and rollback plan that the on-call team has reviewed.
Hold the go or no-go review
Present the inventory, rehearsal results, runbook and rollback plan to the change owner, security lead and application owners, then agree the criteria for proceeding. Record the decision, the named approvers, any conditions and the abort criteria. Output: a signed go or no-go record that fixes the maintenance window.
Execute the window and run post-checks
Take a fresh snapshot, run the approved steps in order, and verify cluster health, shard allocation, index counts, plugin status and client connectivity. Run the agreed post-checks, including sample queries and security role tests, before closing the window. Output: a completed change log and post-check report.
Hand over and set the support calendar
Transfer the runbook, inventory, configuration and access records to your operations team, and walk them through monitoring and alerts. Build a support calendar that tracks new OpenSearch minor releases, which arrive about every eight weeks, along with maintenance and end-of-life dates for your running version and plugin updates. Output: a handover record and a support calendar with named owners.
In-house or partner: who does which part
This table shows the usual owner and required skills for each upgrade task, so you can see which parts your team typically keeps and which parts teams often hand to a partner, with the split varying by organization.
| Work part | Usual owner | Skills required |
|---|---|---|
| Release monitoring and calendar | Usually in-house, with the platform owner tracking minor releases and patch windows | Ability to read release notes and map them to change windows and approval cycles |
| Staging environment upkeep | Often shared, with in-house owning the environment and a partner sometimes building or refreshing it | Linux administration, container or package tooling, and keeping staging data representative of production |
| Plugin compatibility checks | Often outsourced at first, then moved in-house once the plugin list is stable | OpenSearch plugin administration, reading plugin version matrices, and JVM-level troubleshooting when plugins fail |
| Security plugin and identity configuration | Usually kept in-house for ongoing changes, with a partner often helping on the first upgrade | OpenSearch Security administration, role and backend role mapping, and familiarity with your SSO provider |
| Snapshot and restore testing | Commonly kept in-house as a recurring test, with a partner often designing the first test run | Linux storage and repository access, snapshot lifecycle knowledge, and documented recovery steps |
| Migration Assistant or reindex work | Often outsourced for major version moves, with in-house data owners validating results | Data engineering for reindex and mapping changes, plus JVM tuning for large transfers |
| Client and application regression testing | Usually owned by application teams, with the platform team coordinating test timing | Query and client library knowledge, test data design, and understanding of search relevance expectations |
| Incident response during upgrades | Commonly shared, with in-house on call and a partner available on retainer or per engagement | Linux and JVM troubleshooting, cluster health diagnosis, and rollback decision-making under time pressure |
What goes wrong and how to prevent it
Most failed OpenSearch upgrades trace back to a small set of predictable gaps. Each card names the failure and the prevention step that closes it.
Upgrading an unsupported line
OpenSearch versions stay in maintenance until the next major version enters maintenance or one year passes, whichever is longer. Version 1 reached end of life on May 6, 2025, so a 1.x cluster no longer receives bug fixes or security patches. Build a version inventory covering every node, Dashboards instance and plugin, and confirm each line is still maintained before choosing the target.
Skipping a staging rehearsal
Run the full upgrade in a staging cluster restored from a recent production snapshot, with the same plugins, security configuration and index mappings. Time each step and record every error, so the production window is planned from measured work rather than estimates. Repeat the rehearsal until the runbook completes without manual fixes.
Plugins and clients that lag
A plugin built for the current release may not load on the target version. Client libraries written for Elasticsearch may also expect responses or behavior that OpenSearch handles differently. Build a compatibility matrix listing each plugin, client and Dashboards object with its supported OpenSearch version, and confirm each row with the maintainer before the window opens.
Security change that locks out apps
A change to roles, role mappings, authentication backends or TLS settings can stop applications and Dashboards users from connecting, even when the cluster reports healthy. Export the Security plugin configuration before the upgrade, rehearse each application login and service account against the target, and confirm a recovery administrator account that does not depend on the changed settings.
Indices outside the rolling range
Rolling upgrades support indices from Elasticsearch 6.0 through 7.10. Indices created before 6.0 fall outside that range and need another method, such as remote reindex or Migration Assistant. Check the creation version of every index across all clusters early in planning, since this discovery often happens during the window and changes the plan.
Rollback with no tested snapshot
A rollback depends on a snapshot taken before cutover that has been restored at least once in rehearsal. Confirm how long the restore takes and whether the window allows for it plus data verification. Write the rollback decision point with the time by which the call must be made, the criteria that trigger it and the named person who makes it.
How the work changes by starting point
Staying within the 2.x line is the lowest-change path. The work is a move between minor releases inside the same major version, usually run as a rolling upgrade with the cluster kept in service. During maintenance, 2.x receives bug fixes and security patches but no new features, so the target minor release should be chosen against its maintenance status on the planned date.
- Plan: select the target minor release from the OpenSearch releases page and confirm it is still in maintenance when the window opens.
- Extra checks: compare plugin versions and Dashboards objects against the target release before the first node moves.
- Verify: confirm cluster health and shard allocation after each node, and take a snapshot before the upgrade starts.
- Confirm: the supported rolling upgrade sequence for your current minor version in the OpenSearch migrate or upgrade documentation.
A move to the 3.x line is a major version change, so the plan needs a compatibility review before a window is booked. OpenSearch documents four methods for this kind of move: rolling upgrades, snapshot and restore, remote reindexing and Migration Assistant. The method should follow from what your clients, plugins and index settings need, not from the tool you already know.
- Inventory: list plugins, client libraries, index templates and any custom code that relies on 2.x behavior.
- Method choice: a rolling upgrade keeps the cluster in service, while snapshot and restore or remote reindexing suits a parallel build followed by a cutover.
- Window: fit the cutover and the rollback steps inside the maintenance window, and keep the 2.x fallback intact until acceptance is complete.
- Confirm: the 3.x release you will target, its plugin compatibility list and whether your current minor version has a documented upgrade path to it.
Clusters running Elasticsearch need a migration plan as well as an upgrade plan. OpenSearch is a fork of 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. Clusters older than that range, or clusters that depend on Elastic-licensed features, need a different method and a longer review.
- Version check: confirm the exact Elasticsearch version and whether it falls within the supported range for rolling upgrades.
- Migration Assistant: evaluate it for moves across several major versions in one step, and for live traffic capture, which the documentation describes as supporting low or zero downtime.
- Client and feature audit: find client libraries, API calls and licensed features that need replacement or additional testing.
- Confirm: the supported source versions and the recommended method for your version with the OpenSearch migration documentation before any effort is estimated.
Kubernetes deployments add a layer of change control. OpenSearch documents installation with Helm and with the OpenSearch Kubernetes Operator, so the upgrade plan has to cover the chart or operator version, the container image version and the persistent volumes that hold the data. A change to any one of them can affect the others.
- Version pinning: track chart, operator and image versions separately, and test the combination you plan to deploy in a non-production cluster.
- Storage: confirm that persistent volume claims, storage classes and snapshot repository access survive pod rescheduling and node drains.
- Rollout behavior: verify that the upgrade sequence respects cluster manager placement and replica distribution before node groups are changed.
- Platform upgrades: when the Kubernetes version also changes, confirm that the operator or chart supports both versions in the same window.
- Confirm: the release notes and chart values for your target version with the vendor and with your platform team.
OpenSearch documents tarball, RPM and Debian packages as install methods. On connected hosts, upgrades replace packages on each node in turn. In air-gapped networks, every release artifact, Dashboards package and plugin must be staged internally before the window opens, so artifact inventory becomes a planning task in its own right.
- Artifact staging: mirror the target OpenSearch packages, Dashboards packages and each plugin into an internal repository, and record checksums for each file.
- Plugin matching: list the plugin versions that match the target release, since they cannot be downloaded during the window.
- Host sequence: upgrade one node at a time, and confirm service restart and cluster health before moving to the next.
- Offline test: run the staged set through a rehearsal in a non-production environment with the same network restrictions.
- Confirm: the install method for each host type and the checksum and signing guidance published for the release you plan to deploy.
What you need to provide
Before we can scope an OpenSearch upgrade, we need a clear picture of what is running today. For every cluster, send the current version and install method (Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian package, Ansible or Windows), along with the node roles in use. Include a list of installed plugins and their configuration files, because plugin compatibility is one of the first questions a move to a new minor or major version raises.
Share the Security plugin configuration and the identity backends it uses, such as SAML, OpenID Connect, Active Directory, LDAP, Kerberos or JSON Web Token authentication. Include the role mappings and tenants, and confirm that TLS is enabled for node and client traffic. We also need a current snapshot repository and evidence that a restore has been tested recently. A backup that has never been restored is not a rollback plan, and we will ask you to demonstrate one restore before any change window is booked.
We need a staging environment that mirrors production closely enough to rehearse the upgrade, or your written permission for us to build one. Provide the list of applications, clients, ingestion pipelines and dashboards that connect to each cluster, and name an owner for each cluster and each application who can confirm behavior after the change. Agree a maintenance window with the business in advance, and name the decision-maker who will make the go or no-go call and approve a rollback if the checks fail.
Finally, grant read access to the OpenSearch release notes and the release calendar, or name the person on your team who will review them against your plugins and clients. Releases ship about every eight weeks, and the upgrade plan depends on which version your team targets and when. Confirm these inputs with your own environment owners, since the exact upgrade path and effort depend on what they find.
Frequently asked questions
How often does OpenSearch release minor versions, and must we upgrade each one?
OpenSearch targets a new minor version about every eight weeks, and your team decides which releases to adopt. The releases page lists 3.8.0 on August 4, 2026 and 3.9.0 on September 29, 2026, which shows the cadence in practice. Each release brings bug fixes, security patches and sometimes new features, so review the release notes against your use cases before scheduling a move. Adopting every minor is optional, but staying on a line that has left maintenance means losing fixes, so track the maintenance status of your version.
What does the maintenance rule mean for when we should move?
Each OpenSearch version stays under maintenance until the next major version enters maintenance or one year passes, whichever is longer. During maintenance it receives bug fixes and security patches but no new features. Version 1 reached end of life on May 6, 2025, and version 2 is maintained through the 4.0 GA release. Plan your move before your current line leaves maintenance, and confirm the exact end-of-life date for your version on the releases page, because it depends on when the next major enters maintenance.
Is moving from OpenSearch 2.x to 3.x an in-place upgrade or a migration?
It depends on your cluster, your source version and the method you choose, so confirm the path in the migration documentation for the target release before you commit. OpenSearch documents four methods: rolling upgrades, snapshot and restore, remote reindexing and Migration Assistant. Rolling upgrades keep the cluster serving during the change, while snapshot and restore and remote reindexing move data into a separate target cluster for cutover. Migration Assistant can move workloads across several major versions in one step and supports live traffic capture for low or zero downtime. Document which method fits your indices, plugins and clients.
How do we check that our plugins work with the target OpenSearch version?
Check each plugin against the target release in its own documentation, then test in a staging cluster built from the same configuration. Start with an inventory: the Security plugin, analyzers, ingest processors, Dashboards plugins and the client libraries your applications call. For each item, record the version in use, the version the target release requires and whether the project has published support for it. Run queries, ingest jobs and Dashboards workflows against staging, then review Security plugin roles and authentication after the change. Treat any item without confirmed support as a blocker until your team has a tested answer.
Can our own team handle OpenSearch minor upgrades without a partner?
Often yes, if your team already operates the cluster and has a tested runbook, a staging environment and a recent snapshot. Minor upgrades involve less change than a major move, but they still touch every node, the security configuration and any plugins you depend on. Ask whether your engineers have performed rolling restarts on a cluster with dedicated cluster manager nodes and replicas on separate nodes, and whether someone owns the release check each cycle. A fixed-scope upgrade suits one planned change, while a support retainer suits a team that wants each release cycle covered on a recurring basis.
What do we need to provide for an OpenSearch upgrade engagement?
Plan for named owners who can approve the change window, grant access to clusters and accounts, and make decisions about data and retention. Provide a current snapshot policy, a non-production cluster that matches production, the inventory of plugins and client applications, and the maintenance window dates. Ask the partner to list these items in the written scope, along with who signs off at each stage and who handles rollback. The effort your staff must contribute depends on how many clusters, client applications and custom configurations you run, so confirm those counts before requesting a quote.
How DeployOpen delivers this service
DeployOpen plans OpenSearch upgrades and ongoing support as written, fixed-scope work inside infrastructure you control, with each step agreed before it starts. The work covers the move from your current release, plugin compatibility checks, rehearsal in a non-production environment and a hand-over your team can run.
How we scope
- We confirm your current OpenSearch and Dashboards versions, node roles and the plugins your clusters depend on.
- The written scope names the target release, the maintenance window and which upgrade method is planned: rolling upgrade, snapshot and restore, remote reindex or Migration Assistant.
- We agree the rollback point, the acceptance checks and the decision owner before any change is made to a cluster.
How we build
- We rehearse the upgrade on a copy of production configuration and record the steps, timings and any plugin or client changes needed.
- Each plugin, index template, ingest pipeline and Dashboards object is checked for compatibility with the target version before the window opens.
- We take and verify snapshots, run cluster health and query checks after each stage, and document every deviation from the plan.
How we hand over
- You receive the runbook, the upgrade record, the compatibility matrix for your plugins and the rollback procedure.
- We walk your operators through the cluster health, snapshot and monitoring checks they will run after go-live.
- We list the open items, such as deprecated settings or plugins that need a vendor decision, with owners and dates agreed with you.
How we support
- Ongoing support can be taken as a retainer, covering patch and minor-release planning against the release cadence your team chooses.
- Retainer scope should state which OpenSearch versions are covered, how security patches are handled and how major-version moves are priced separately.
- Ask us to confirm response expectations, the environments covered and how changes are logged before you sign the retainer.
