Why move from OpenSearch 2.x to 3.x and what the supported path looks like
If your self-managed cluster runs OpenSearch 2.x, the first question is how long your current line will keep receiving support. During maintenance, OpenSearch versions get bug fixes and security patches but no new features. The 2.x line is maintained through the 4.0 GA release, so the date that matters is when 4.0 reaches general availability, not a fixed end date you can plan around today. Treat the move to 3.x as a major version change that needs a planned path, not a patch. Start by confirming the exact 2.x build in production, the plugins installed on each node, and whether your applications depend on any feature that only exists in 3.x.
OpenSearch targets a new minor release about every eight weeks. The 3.8.0 release arrived on August 4, 2026, and 3.9.0 followed on September 29, 2026. The 3.x line will keep moving, so the target version needs a deliberate choice. Pick a specific 3.x minor, test it against your own indices, queries and plugins, and then set a routine cadence for later minor upgrades. Ask your internal change board or your partner which 3.x minor they will approve for production, and whether that choice will be revisited on a set schedule. Without that decision, the target moves during the project and the test results go stale.
The supported path depends on two things: your source version and the data in the cluster. Confirm the exact 2.x versions that support a direct upgrade to 3.x in the official migrate or upgrade documentation for the 3.x release you plan to use. If your cluster is not on a supported 2.x version, the route will include an intermediate step. The data matters as much as the version. Indices created under older Elasticsearch-era releases, or under older OpenSearch versions, may need to be reindexed before 3.x can use them. Run an inventory of index creation versions, mappings, index templates, aliases and any custom analyzers so that you know which indices need that work before you pick a method.
What changes between OpenSearch 2 and 3, and what each change requires
This table lists the changes an OpenSearch 2.x cluster must absorb before moving to 3.x, the impact of each, and the work it creates. Check every row against the 3.x release notes and breaking-change list for your exact target version, then build an inventory of nodes, settings, plugins, indexes and security configuration. The main takeaway is that most upgrade failures trace back to a change that was never inventoried before cutover.
| Change | Impact on the cluster | Action needed |
|---|---|---|
| JDK requirement for 3.x | Nodes running a JDK below the minimum stated for 3.x may fail to start or fall outside supported operation. | Confirm the required JDK version in the 3.x release notes. Inventory the JDK on every node, including container images and operator-managed pods, and upgrade it before replacing binaries. |
| Removed settings | Settings removed in 3.x may be ignored or may stop a node from starting, depending on where they are defined. | Compare elasticsearch.yml, jvm.options and cluster settings from the cluster settings API against the removed-settings list in the 3.x breaking changes. Replace or delete each match in staging first. |
| Removed or changed plugins | Plugins without a 3.x-compatible build may fail to install or load, and plugin versions must match the core version. | List installed plugins on every node and check each one against the 3.x plugin compatibility information. Plan a replacement or removal for any plugin without a 3.x build. |
| New request limits | Requests that exceed newly introduced limits may be rejected, which can break bulk ingestion, large queries or client applications. | Read the 3.x limits section in the release notes. Measure current bulk payload sizes, result window settings and aggregation sizes from logs and client configuration, then adjust before cutover. |
| Indexes created before 2.x | Indexes created in older major versions may not be readable or writable in 3.x, and this blocks a direct in-place upgrade. | Check the creation version of each index through index settings or the cat indices output. Confirm compatibility in the 3.x docs, then reindex or migrate any index that predates 2.x. |
| Changes to Security plugin configuration | Changed security configuration, role mappings or authentication backend settings can lock out users or admin certificates. | Export security configuration, roles and role mappings. Back up the security index, compare settings with the 3.x Security plugin documentation, and test SAML, OpenID Connect and LDAP sign-in on a staging cluster. |
Choosing between rolling upgrade, snapshot and restore, remote reindexing and Migration Assistant
A rolling upgrade replaces the software on one node at a time while the cluster keeps serving requests. Each node is stopped, upgraded and rejoined, and the cluster recovers shard copies before the next node is changed. The cluster, its indices and its cluster state stay in place, so no data moves to a new cluster. The OpenSearch FAQ states that OpenSearch supports rolling upgrades from Elasticsearch 6.0 through 7.10, so confirm whether your 2.x source version falls within the documented path for 3.x.
- Fits when the cluster can accept a node-by-node change and the replica count lets shards stay available while one node restarts.
- Downtime: request handling usually continues, but capacity drops during each node change, so peak load must be tested against the reduced cluster.
- Reindexing: indices already on a supported format do not need to be rebuilt. Indices that predate the supported range may still need reindexing first.
- Demands: a pre-upgrade snapshot, a tested rollback procedure, compatibility checks for plugins and client libraries, and an operator who watches cluster health between each node.
Before you plan around this method, check the upgrade documentation for your exact source and target releases.
Snapshot and restore copies indices into a snapshot repository, then restores them into a new cluster that runs the target version. The source cluster keeps serving traffic while the snapshot runs, but any writes made after the snapshot starts must be replayed, captured by a second step, or accepted as lost. The method gives you a clean target cluster and an independent recovery point. OpenSearch documents it as one of its four upgrade and migration methods.
- Fits when you want new nodes, new hosts or a changed topology, and you can freeze or replay writes at cutover.
- Downtime: depends on the write freeze window at cutover. Measure that window on a copy of your data instead of assuming it.
- Reindexing: restored indices keep their stored structure, so each index must be checked for compatibility with the target version before restore.
- Demands: a snapshot repository reachable from both clusters, storage sized for the snapshots, a cutover runbook, and a check of document counts and mappings after restore.
Confirm with the OpenSearch documentation which snapshot formats and version pairs the 2.x to 3.x path accepts for your source version.
Remote reindexing builds indices on a new target cluster by reading documents from the source cluster through the reindex API. Each document is read, optionally transformed and written again, so mappings and settings are rebuilt on the target. This is the method that changes index structure most directly, because the target decides how the data is stored. It works only when the target can reach the source over the network and authenticate to it.
- Fits when you need to change mappings or index layout during the move, or when only some indices need to move.
- Downtime: writes to the source during the copy must be stopped or replayed, or the target will lag behind the source at cutover.
- Reindexing: every index is rebuilt by definition, so run time grows with document count and search results on the target can change while the copy is in progress.
- Demands: network routes and TLS trust between clusters, a role with read access on the source, a method for capturing changes made during the copy, and count checks on each index after it finishes.
For large indices, run a timed test on a representative subset first and confirm the approach against your OpenSearch version.
Migration Assistant is OpenSearch's tool for moving workloads to a new cluster. According to the OpenSearch documentation, it can move workloads across several major versions in one step, for example from Elasticsearch 6.8 to OpenSearch 2.19. It also supports live traffic capture, which records requests sent to the source and replays them against the target so that cutover can happen with low or zero downtime. Confirm the exact source and target pairs it supports for a 2.x to 3.x move before you commit to it.
- Fits when the downtime limit is low or zero, you need to validate traffic against the target before cutover, or the source is several major versions behind.
- Downtime: the documentation describes low or zero downtime with live traffic capture. The actual window depends on how cutover is designed and must be tested.
- Reindexing: documents and metadata pass through the tool's migration pipeline, so index mapping changes must be reviewed before the run.
- Demands: deployment of the tool and its components in your environment, access to both clusters, control over how traffic is routed, a capture and replay test plan, and an operator who can run and monitor a migration pipeline.
Review the OpenSearch Migration Assistant documentation for the current requirements and supported version pairs before you scope the work.
Backups, inventory and a test cluster before the first node changes
Preparation for an OpenSearch 2.x to 3.x upgrade produces the evidence needed to roll back, to know what will break, and to decide the order of node changes. The cards below are the outputs the team should hold before any node is stopped, and each one feeds the plan for the next.
Verified snapshot before any change
Take a snapshot of all indexes and the cluster state to a repository outside the cluster, then restore a representative index into a scratch cluster to prove the copy is usable. Until a restore has succeeded, the snapshot is only an expectation that the data can be recovered. Record the snapshot name, timestamp and repository location in the change record, and confirm that repository credentials and storage access work from every node that might need them during a rollback.
Inventory of plugins and dependent code
List every plugin on every node with its installed version, along with index templates, security roles and role mappings, client libraries and scripts that call settings or APIs changing in 3.x. Assign an owner to each item and mark whether it is custom, vendor supplied or inherited from a application team. The output is a punch list that shows which items must be replaced, reconfigured or retested before the upgrade can proceed.
Test cluster built from production configuration
Build a test cluster from the same configuration files, plugin set, security settings and TLS setup as production, then load a sample of production data that includes indexes created in older versions, since pre-2.x indexes need reindexing. Run the client and script suites against it and time the upgrade steps. Results from this cluster set the order and pace used in production, so the team should be able to repeat the run.
Baseline of health and shard allocation
Capture cluster health, node roles and versions, shard counts per node, unassigned shards, pending cluster tasks and disk watermark settings at a quiet point before the work starts. Also save the current allocation and cluster settings as text so changes can be compared afterward. A baseline that shows existing unassigned shards or a yellow status makes it harder to tell upgrade effects from problems that were already present.
Node change order from availability settings
The OpenSearch cluster documentation recommends dedicated cluster manager nodes, replicas on separate nodes and shard allocation awareness. If cluster manager roles share nodes with data roles, the team must keep enough eligible cluster manager nodes online at each step to keep a quorum. Separate replicas let one node leave at a time, and allocation awareness keeps copies in different zones, so the team should change one zone at a time and wait for recovery between steps. Recovery time measured in the test cluster determines how many nodes can be changed in one window.
Reindexing indexes created before 2.x and checking what the cluster can still read
Before the upgrade, check every index that was created in an older Elasticsearch release, because the rules for what a 3.x cluster can read come from OpenSearch's own 3.x release notes and upgrade documentation, not from the behavior your 2.x cluster shows today. The OpenSearch FAQ states that OpenSearch can use indices from Elasticsearch 6.0 through 7.10 and supports rolling upgrades from those versions. That statement describes the fork's lineage. It does not guarantee how every later major version treats an old index. Confirm the index compatibility rules for the exact 3.x release you plan to target in the official docs, and treat any 2.x assumption as unverified until you have checked it.
Start by inventorying the indexes. List every index with its name, document count, store size, health, alias membership and the application that writes to it. For each index, read the version it was created with from its settings, and separate indexes that originated in Elasticsearch 6.x or 7.x from those created natively in OpenSearch. Include closed indexes, hidden and system indexes that monitoring or security plugins manage, and indexes that exist only in snapshots, because a restore can bring an old index back into a cluster that never had it in its active state. Record which indexes are still written to, since that answer drives every later decision.
For each old index, choose between reindexing and leaving it in place. Leave an index only when the 3.x compatibility rules, as confirmed in the official docs, say the cluster can still read it, and nobody needs to write to it. Reindex an index that is still written to, that users must search across their history, or that other systems depend on. Consider deletion or snapshot-only retention for indexes past their retention period. Illustrative example: a log index from an old Elasticsearch deployment that is past its retention window can be archived in a snapshot and removed, which avoids copying data that nobody reads.
Reindexing has three costs to plan for. Disk space matters first, because the reindex writes a second copy of the data while the source remains, so you need free capacity for both copies plus replicas on the target. Time depends on document count, mapping complexity and the indexing capacity of the target nodes, so measure a representative index on a copy before you schedule the production run. Downstream applications matter most in practice. Hard-coded index names, saved searches, dashboards, ingest pipelines and alerting monitors can break when an index is replaced. Point aliases at the new indexes only after validation, and confirm the remote reindexing or other method you choose is tested against your data.
Upgrade sequence with checks and rollback points
This sequence moves a self-managed OpenSearch 2.x cluster to a 3.x release in stages, so each stage has a check that must pass before the next begins. It also records the last point at which the team can return to a known-good state. Each step names the evidence the platform owner needs before continuing.
Confirm versions and freeze configuration
Record the exact OpenSearch 2.x version on every node, the target 3.x release, and the JDK version each node runs. Confirm which indexes were created on pre-2.x versions and which need reindexing before the upgrade. Freeze configuration changes, including templates, cluster settings, plugins and security roles, until the upgrade closes. The step is done when the version inventory and the change freeze are approved in writing by the platform owner. Rollback is still a clean stop at this point because nothing in the cluster has changed.
Take and verify a snapshot
Create a snapshot of all indexes and cluster state in a snapshot repository the upgraded cluster can reach, and keep it separate from the nodes being changed. Verify that the snapshot shows a complete status and that a test restore of a sample index succeeds on a separate cluster. Confirm that the security configuration files and certificates are backed up outside the cluster. The step is done when the restore test passes and the backup owner signs off. This snapshot is the fallback for the rest of the sequence, so record its name and location in the change ticket.
Upgrade the test cluster and run the test plan
Build a test cluster from the same deployment method and configuration as production, restore the snapshot into it, and upgrade it to the 3.x target. Run the test plan covering search and indexing queries, ingest pipelines, dashboards, scheduled jobs and every client application that connects. Compare results and latencies with the pre-upgrade baseline. The step is done when every test case has a recorded result and any failure has an owner and a fix or an accepted risk. Do not proceed to staging until the test plan passes, because findings here are cheaper to resolve than in production.
Update JDK and settings on staging
On the staging cluster, install the JDK version the 3.x release requires and review cluster and node settings against the removed or changed settings listed in the release notes for the target version. Remove or replace settings that no longer apply, and record every change. Restart the staging nodes in the same order production will use and confirm that the cluster returns to green health. The step is done when staging starts cleanly, the settings review is documented, and the staging test plan passes again on the updated runtime.
Pick the production method
Choose the production method by comparing the options OpenSearch documents: a rolling upgrade on the existing cluster, snapshot and restore into a new cluster, remote reindexing, or Migration Assistant. Consider the source version, downtime tolerance, the number of indexes and clients, and whether the target needs new hardware. Ask the implementation partner or your own team to confirm the method against the official migration documentation for the exact source and target versions. The step is done when the method, the cutover plan and the rollback path are approved. Rollback depends on this choice, so record it explicitly.
Upgrade production one node group at a time
Upgrade production one node or one group of nodes at a time, starting with a node that holds no cluster manager role. Before each node is stopped, confirm that cluster health is green and that shards have finished relocating. After the node rejoins, wait for green health and check that shard allocation is complete before moving to the next node. Keep the cluster manager nodes for last and upgrade them one at a time. The step is done when every node reports the target version and the cluster is green. Until the first node is upgraded, rollback means stopping. After that, return to the snapshot and follow the documented procedure.
Verify security plugin and client traffic
After all nodes run the target version, test the Security plugin: sign in through each configured authentication backend, confirm role-based and document-level access for representative users, and check that audit logs record the expected events. Then confirm client traffic by running the client test scripts against production and comparing error rates and latencies with the baseline. The step is done when authentication, authorization, audit logging and client applications pass their checks and the owners of each application accept the result. Keep the snapshot until the platform owner closes this step.
Document the closing rollback point
Record the final cluster version, node list, configuration changes, test results and the snapshot taken before the upgrade. State the date until which the pre-upgrade snapshot will be kept and who is authorized to approve its deletion. Confirm with the vendor documentation whether a downgrade path exists for your exact versions, and record the answer. The step is done when the runbook and the rollback record are filed with the change ticket and signed by the platform owner. Without this record, the team cannot show the auditor or the next operator what state the cluster was in and how to return to it.
What makes an OpenSearch 2 to 3 upgrade take longer
This table lists the factors that most often extend an OpenSearch 2 to 3 upgrade, why each one adds work, and what to inventory or measure before you estimate effort. Use the measurements to compare your environment with a test cluster, and treat any driver with a high count as a reason to schedule a longer rehearsal.
| Driver | Why it adds effort | What to measure to size it |
|---|---|---|
| Plugins (number and type) | Each plugin needs a version that runs on the target release, and custom plugins must be rebuilt and retested. | Installed plugins per node, the 3.x compatibility status of each, and which plugins your team built. |
| Custom security roles and authentication backends | Role mappings, document and field-level rules and each backend (SAML, OpenID Connect, Active Directory and LDAP, Kerberos, JSON Web Token) need separate login and access tests. | Count of roles, role mappings and document or field-level rules, and each authentication backend in use with its test coverage. |
| Data volume and indexes needing reindexing | Indexes created in earlier versions must be reindexed, and reindex time grows with document count and store size. | Index count by creation version, total primary store size, document count and reindex throughput measured on a test copy. |
| Client applications and pipelines | Changed settings, removed options and new request limits can break clients, ingest pipelines and scripts that rely on old behavior. | Inventory of clients, ingest pipelines, scripts and dashboards, plus deprecation warnings logged by the current cluster. |
| Topology (cluster manager, allocation awareness, multi-site) | Rolling restarts must keep shards available across zones, and multi-site clusters need coordinated node and cutover sequencing. | Node roles per host, dedicated cluster manager count, zones or racks used for allocation awareness, shard and replica counts, and number of sites. |
| Deployment method | Docker, Helm, the Kubernetes Operator, packages, Ansible and Windows each have their own rollout steps, image or package sources and configuration paths. | Methods in use and node count per method, whether configuration is in version control, and whether rolling restarts are automated. |
| Availability target for cutover | A rolling upgrade keeps mixed versions running during the window, and stricter targets may require Migration Assistant with live traffic capture and more rehearsals. | Agreed maximum interruption for reads and writes, tolerable data lag, and the number of full rehearsals completed in staging. |
Testing and rollback before production cutover
Define pass criteria with your application owners before the first test run starts, because a comparison without agreed thresholds only produces a list of differences. For each application, agree which search results may change in order (relevance scores, ties, field ordering), which aggregation totals must match exactly, how much latency increase is acceptable, and which index write paths must succeed without retries. Record the baseline from the 2.x cluster using the same query set, data snapshot and client settings you will use on 3.x. Sign-off should name the person who accepts each category of failure, so a difference in one dashboard panel does not stall cutover while nobody owns the decision.
Cover the whole platform, including search. Check cluster health and shard allocation under normal load and after a node restart. Test index creation, bulk writes, updates and deletes, and confirm that indices created on earlier versions remain readable and writable the way your applications expect. Compare search and aggregation results against the 2.x baseline, including queries that use sorting and filters on fields whose mappings changed. Verify Security plugin roles, document-level and field-level security, field masking and the audit log entries your compliance team relies on. Exercise OpenSearch Dashboards saved objects, ingest pipelines and every client library version that talks to the cluster.
Decide rollback checkpoints in advance. The 2.x cluster should remain intact until the cutover is accepted, and the restore path should be tested before any production traffic moves. Take a snapshot of every index on 2.x, verify the repository, and rehearse a restore into an isolated 2.x cluster. Confirm the snapshot compatibility rules for your version pair in the migrate or upgrade documentation, because a snapshot that a target version cannot read fails late in the process. Also confirm whether global cluster state, security configuration, index templates and ingest pipelines are included in the snapshot or must be exported separately. Time the restore at production data volume, since that duration sets the practical rollback window.
Rollback stops being practical once applications write to 3.x. A snapshot taken before cutover does not contain those documents, so returning to 2.x means either replaying those writes into 2.x or accepting their loss. Set a go or no-go point after which the decision moves from rollback to fix-forward, and agree it in the same meeting where pass criteria are set. Before that point, capture every write that lands on 3.x, for example through a change feed or an application-side queue, so a replay is possible. Name who can declare a rollback and which evidence triggers it, and rehearse that decision once before cutover day.
Questions teams ask before upgrading OpenSearch 2 to 3
What drives the cost of an OpenSearch 2 to 3 upgrade?
Cost follows the number of clusters, the size and age of the indexes, the custom code and integrations that touch them, and how much testing your team can already supply. Indexes created before 2.x, reindexing, JDK 21 changes, removed settings and removed plugins each add scope that must be inventoried and tested.
Who pays for what: a DeployOpen engagement is fixed-scope, so you pay for the planning, upgrade work and documentation defined in the written agreement. Your team carries staff time for application owners, approvals and change windows, and your infrastructure costs stay with you.
One-time or recurring: the upgrade itself is one-time. Support or upgrade retainers recur.
In a quote, ask for: the inventory assumptions, the upgrade method, the test environments, the deliverables and the change-window plan, with each line tied to a specific cluster or application.
How long does an OpenSearch 2 to 3 upgrade take?
No single figure can responsibly cover every OpenSearch upgrade, so the written scope should give duration per cluster and per phase. Duration depends on the number of clusters, data volume, index age, whether indexes need reindexing, the number of custom plugins and client integrations, how many application owners must test, and how many change windows you can use.
A rolling upgrade of a small cluster with clean indexes follows a very different path from a multi-cluster estate that needs reindexing and a cutover. Ask the provider to show the phases: inventory, test upgrade, remediation, production runs and handover. Each phase should list its entry and exit criteria, its dependencies and the owner who signs off. Check the proposed dates against your own change calendar and the release timing of the target version.
What must our team provide before an OpenSearch upgrade starts?
Start with a current inventory of every cluster, its node role layout, indexes, templates, aliases, plugins, clients, ingest pipelines and scheduled jobs that touch OpenSearch.
Access: administrator or role-mapping access for the Security plugin, network paths to each cluster, snapshot repository access and your deployment tooling.
Test data: a representative, sanitized copy of the indexes, ideally in a non-production environment that matches production configuration.
Change windows: dates, freeze periods and the people who approve a rollback.
Owners: a named person for each application or index family who can confirm queries, dashboards, alerts and acceptance. Without these owners, test results have no one to accept them. Name one decision-maker for the go or no-go call as well.
Can our platform team upgrade OpenSearch 2 to 3 without outside help?
It can, often for a small and well-documented estate, if the team has run OpenSearch in production, has time for a full test cycle and can own the rollback. Whether it can do the work alone depends on how many clusters and applications are involved, how much custom code and plugin use exists, whether older indexes need reindexing and whether application owners can staff the testing.
Consider the cost of a failed production window and who is on call during it. Teams often split the work, keeping inventory and day-to-day operations in-house while buying specific pieces such as migration planning or a rehearsal. DeployOpen plans, implements, documents and supports self-hosted open-source platforms in your infrastructure, so you can scope the full upgrade or selected parts in writing. Compare the internal effort against that written scope before you decide.
When is a rolling upgrade enough, and when is Migration Assistant needed?
A rolling upgrade fits when the cluster can be upgraded in place, the source version is supported on that path and the data does not need to be rebuilt on a new target. OpenSearch documents four methods: rolling upgrades, snapshot and restore, remote reindexing and Migration Assistant.
Migration Assistant can move workloads across several major versions in one step, for example from Elasticsearch 6.8 to OpenSearch 2.19, and it supports live traffic capture for low or zero downtime. It becomes the stronger option when the source version is far behind, when you are building a new cluster on new infrastructure or when your downtime window is very short.
Confirm the supported paths for your exact source and target versions in the OpenSearch documentation, and read the Migration Assistant decision guide before committing. The method changes the effort, so the written scope should name it and explain the choice.
What happens if an OpenSearch 3 upgrade fails partway through?
A failed upgrade is handled by the rollback plan agreed before the change window opens. Before any production step, take a snapshot, verify that it can be restored, record the source configuration and define the conditions that trigger a rollback along with who approves it.
If a node or cluster fails mid-upgrade, the team stops, checks cluster health and shard allocation, then decides whether to resume, restore from the snapshot or send traffic back to the previous cluster if it is still running. Your scope should state who is on call, how far the change window can extend and how application owners will be informed.
The written scope should also say whether DeployOpen covers incident support during the window or continues through a retainer afterward. Ask for a rollback rehearsal before go-live.
Is OpenSearch 2 still maintained, and when should we plan the move?
Yes. OpenSearch versions stay under maintenance until the next major version enters maintenance or one year passes, whichever is longer. During maintenance, a version receives bug fixes and security patches but no new features. Version 2 is maintained through the 4.0 GA release.
That means your timing question depends on the release plan for 4.0 and your own patch and risk policy, not only on the 2.x end date. Work backward from your change calendar, your number of clusters and the effort described in the written scope. Confirm current support dates on the OpenSearch releases page before you set a target date, because the project publishes new minor versions about every eight weeks.
Does DeployOpen run OpenSearch upgrades inside our own infrastructure?
Yes. DeployOpen plans, implements, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For OpenSearch, the clusters, data and credentials stay in your environment while the work proceeds under a fixed-scope written agreement.
DeployOpen does not issue audit reports, attestations or certifications. Upgrade evidence, such as inventories, test results and runbooks, can support your compliance readiness, but independent auditors and certification bodies make the assessment.
Scope, deliverables and timelines are agreed in writing before work begins. Ongoing upgrades, support and testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen scopes, delivers and supports an OpenSearch 3.x upgrade
DeployOpen plans and delivers OpenSearch 2.x to 3.x upgrades inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks. The work starts with an inventory of your indexes, plugins, settings and clients, then moves through build, testing and handover. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- Inventory of indexes created before 2.x, which need reindexing, and their size and ownership.
- Review of removed settings, plugins, JDK 21 requirements and new request limits against your configuration.
- Choice between rolling upgrade and Migration Assistant, recorded with the reasons, in the written scope.
How we build
- Staging cluster built to match production topology, plugins and security configuration before any live change.
- Reindex and client changes tested against representative data, with query and ingest behavior compared.
- Security plugin roles, TLS and audit logging checked after the upgrade against the access model you approved.
How we hand over
- Runbook covering the chosen method, rollback points, verification steps and the cutover sequence.
- Before and after configuration records, index mappings and plugin inventory delivered as documentation.
- Knowledge transfer sessions with your platform team, covering monitoring, snapshots and the next upgrade steps.
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover.
- Patch and maintenance review as new releases arrive, so security fixes reach your environment.
- Post-upgrade checks on cluster health, shard allocation and snapshot restores, agreed in the scope.
