OpenSearch vs Elasticsearch: which to choose

When to choose OpenSearch or Elasticsearch for self-hosted logs

Choose OpenSearch when your team needs a self-hosted search and log backend under Apache-2.0 terms, with security controls that do not sit behind a paid tier. The OpenSearch Security plugin covers SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token authentication, role-based access control, document- and field-level security, field masking and audit logs. OpenSearch Security Analytics can also match ingested logs against Sigma rules, which lets it act as a SIEM backend without a separate product. If your security staff will build their own detections and dashboards, this path keeps the stack free of tier gating.

Choose Elasticsearch when your organization already standardizes on Elastic tooling and expects to pay for Platinum or Enterprise features. Per Elastic's subscriptions page, the detection engine, machine learning anomaly detection and case management sit under Platinum, which Elastic no longer sells to new customers, while endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit under Enterprise. Confirm current availability with Elastic before you plan around any tier, and ask whether your needs map to Enterprise or to Elastic Cloud.

Four factors should decide this. First, the license terms for your use, including whether you offer the software as a managed service or to internal business units. Second, which paid features you need, such as anomaly-based alerting or host isolation. Third, the release support windows: confirm the current maintenance dates for the OpenSearch line you intend to run and for the Elastic 8.x or 9.x line you are considering. Fourth, your migration appetite, since moving an existing cluster either way involves index compatibility, upgrade paths and reworked dashboards.

Which platform fits which scenario

This table matches common scenarios to the platform that fits them better, along with the condition that tips the choice. Read each row as a starting point: the condition column tells you what to verify in your own environment before committing. The main takeaway is that the decision usually turns on existing Elastic entitlements, the security features you need without a subscription, and whether you are building a product or running an internal SIEM.

Scenario	Better fit	Condition that makes it so
Internal SIEM that needs SSO, RBAC and audit logs without a subscription	OpenSearch	SAML, OIDC, LDAP and document or field-level security are part of the Apache-2.0 Security plugin; confirm the specific controls your assessor expects.
Vendor embedding search or log analytics in its own product	OpenSearch	Apache-2.0 places no managed-service restriction comparable to ELv2, so confirm the license terms with your counsel for your distribution model.
Existing Elasticsearch estate on a current subscription	Elasticsearch	Migration carries index, client and tooling work; staying put makes sense while the subscription tier covers the features you use.
Need for Elastic Security detection, ML anomaly alerts or case management	Elasticsearch	Platinum no longer sells to new customers and anomaly-based alerting sits in Platinum and Enterprise; confirm current tier availability with Elastic.
Team that wants a prepackaged SIEM with OpenSearch as the backend	OpenSearch	OpenSearch Security Analytics applies Sigma rules and correlates findings, but you build and tune the rule content yourself.
Team building on Wazuh, where the indexer is an OpenSearch fork	OpenSearch	Choose plain OpenSearch when you want to own the cluster directly; Wazuh suits teams that want its agents, rules and MITRE ATT&CK mapping on top.
Team building on Graylog with OpenSearch as its search backend	OpenSearch	Graylog 7.2 supports self-managed OpenSearch 1.1.x to 3.7.x or Graylog Data Node, which Graylog recommends; check the compatibility matrix before upgrading.

How OpenSearch and Elasticsearch diverged from the 7.10 roots

OpenSearch and Elasticsearch share a common ancestor: OpenSearch is a fork of Elasticsearch 7.10, and OpenSearch Dashboards derives from Kibana 7.10.2. OpenSearch is wire-compatible with Elasticsearch 7.10, so clients written against that version often connect without changes at the protocol level. That compatibility describes the starting point, not the present. Since the fork, the two projects have shipped different releases, different security and plugin features, and different APIs in places. Wire compatibility with 7.10 does not mean compatibility with today's Elasticsearch 8.x or 9.x lines. Any client library, ingest agent, index template, ILM or ISM policy, or custom plugin you run needs its own check against the exact versions you plan to deploy.

Be precise about the security analytics layer, because the names look similar. OpenSearch Security Analytics matches ingested logs against prepackaged or custom Sigma rules, records findings and correlates them across log types. Elastic's detection engine is a separate Elastic Security capability with its own rule format, alert workflow and tiering, and the Elastic subscriptions page places the detection engine under Platinum, which is no longer sold to new customers. A rule set, alert schema or case workflow built on one will not carry over to the other without rework. Treat them as two different SIEM feature sets that happen to share a search engine lineage. Map each detection you depend on to the product that actually runs it.

Before you commit to either side, run a short compatibility review. Inventory every client, shipper, dashboard export, saved search, scripted query and plugin that touches the cluster, and record the exact client version and API calls each one uses. Test them against a non-production OpenSearch cluster at the version you intend to run, and against an Elasticsearch cluster at the version you would upgrade to. The OpenSearch FAQ describes migration support from Elasticsearch 6.0 through 7.10 indices and rolling upgrades from those versions, and the migration documentation linked on this page covers the procedures. Ask your vendors or integrators to confirm, in writing, which API versions their products support. Where a fact is not in the documentation you reviewed, record it as an open question rather than an assumption.

How each platform is built and deployed

Both platforms run as clusters of nodes that hold data, route queries and coordinate changes, so the build decisions you make early shape the staff you need later. The cards below cover how Elasticsearch splits responsibilities across node roles, what the three-master minimum means for high availability, and how OpenSearch's documented install methods change who runs the cluster day to day.

Elasticsearch node roles

Elasticsearch lets you assign roles per node: master-eligible, data (with hot, warm, cold and frozen tiers), ingest, machine learning, transform, remote cluster client and coordinating-only. Mixing roles on small nodes is simple to start with, but log workloads usually push teams toward separate data tiers for retention and cost. Check which roles your current Elasticsearch deployment uses, because a cluster built around tiers needs a plan for moving indices between them. The same design questions carry over to an OpenSearch cluster, where you should confirm how the node role model maps to your chosen install method.

Three master-eligible nodes minimum

The Elasticsearch node roles documentation states that a highly available cluster needs at least three master-eligible nodes. Two nodes cannot form a quorum that survives the loss of one of them, which is why small two-node designs fail during failover. Budget for three dedicated or lightly loaded master-eligible nodes even when the data tier is small. Confirm with your platform team how quorum is handled during rolling restarts and network partitions, since the same quorum logic applies to any OpenSearch cluster you build.

OpenSearch install methods

OpenSearch documents installation with Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian packages, an Ansible playbook and Windows. Containers and Helm suit teams already running Kubernetes, while tarball, RPM and Debian packages fit virtual machine estates managed by configuration tools. The method you pick decides who owns node pools, TLS setup and upgrades. Ask your provider which install path they support, and whether the same path will be used for upgrades and backups.

Kubernetes operator and Helm trade-offs

The OpenSearch Kubernetes Operator and the Helm charts both target clusters on Kubernetes, but they leave different work to your team. Confirm which tasks the operator automates, such as node pools, rolling upgrades and TLS, and which remain manual under a chart-based install. Elastic offers its own operator, Elastic Cloud on Kubernetes, which is part of the self-managed Elastic product line with Basic and Enterprise tiers. Staffing depends on whether you already have people who run stateful workloads on Kubernetes.

Staffing for each model

A cluster on virtual machines needs people who tune host settings, manage certificates and run upgrades by hand or through configuration management. A Kubernetes-based cluster needs people comfortable with persistent volumes, pod disruption and operator upgrades. Either way, a three-node master tier plus data nodes means more hosts to patch and monitor than a single-node test setup suggests. Ask for a written runbook covering node failure, index recovery and version upgrades before you commit to a design, and confirm who on your side holds on-call responsibility.

Upgrade paths and version support

Elastic lists end of maintenance for the core stack 9.x line on October 15, 2027 and for 8.x on January 15, 2027, with 8.x support ending July 15, 2027. OpenSearch maintains each version until the next major version enters maintenance or one year passes, whichever is longer. Plan each cluster's upgrade cadence against these windows and confirm the current support dates with each vendor before signing a design. Upgrade effort is driven by the install method, so include it in your scoping conversation rather than treating it as a later task.

Capability, license and tier differences side by side

This table sets the license and tier position of each platform against the security and operations features teams usually check first. Read the Elasticsearch column for the tier each feature sits in, and treat any cell marked to confirm as a question for the vendor before you build a plan around it. The main takeaway: the OpenSearch Security plugin covers most of these controls under Apache-2.0, while Elastic reserves several of them for paid subscriptions.

Capability	OpenSearch (Apache-2.0)	Elasticsearch (Basic, Platinum, Enterprise)
License	Apache-2.0 for all project software, with no paid edition described in the FAQ	ELv2 is the default distribution, with SSPL 1.0 and AGPLv3 options
TLS, native users and RBAC	TLS for node and client traffic and role-based access control included	Free in Basic since 2019 for TLS, file and native realms, and RBAC
SAML and OpenID Connect single sign-on	Included in the Security plugin with SAML and OIDC backends	Paid, in the Enterprise tier
Active Directory, LDAP and Kerberos authentication	Supported as authentication backends in the Security plugin	Paid tiers per Elastic's 2019 announcement; confirm current tier
Document and field-level security	Included, with field masking and user impersonation	Paid tiers per Elastic's 2019 announcement; confirm current tier
Audit logs	Included in the Security plugin	Not covered by the supplied facts; confirm tier with Elastic
Detection engine and anomaly detection	Security Analytics matches Sigma rules; confirm anomaly detection with the vendor	Detection engine on Platinum, which is no longer sold to new customers; anomaly alerting on Platinum and Enterprise
FIPS 140-3 mode	Not covered by the supplied facts; confirm with the OpenSearch project	Listed on the subscription page; confirm which tier includes it
Kubernetes operator support	OpenSearch Kubernetes Operator is documented for self-managed clusters	Elastic Cloud on Kubernetes is offered in Basic and Enterprise tiers

What each license allows and what each edition costs

OpenSearch and OpenSearch Dashboards are licensed under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe any paid edition. For a self-hosted team, the search engine, security plugin and dashboards carry no license fee from the project, and no tier decides which features you can switch on. Paid help comes from service providers, and it is priced by the scope you agree in writing.

Fork base: OpenSearch is a fork of Elasticsearch 7.10, and OpenSearch Dashboards derives from Kibana 7.10.2.
Security controls: The Security plugin covers SAML, OpenID Connect, LDAP and Active Directory, role-based access control, document and field-level security and audit logs in the base distribution.
Recurring costs: Infrastructure, storage, staff time and any support contract recur, while adopting the license costs nothing.
Foundation governance: The OpenSearch Software Foundation is a Linux Foundation project, and its board does not oversee the technical direction of the code.

Confirm with your procurement and legal teams that the Apache-2.0 notices and any bundled third-party components meet your software bill of materials policy.

What drives the running cost of each platform

This table sets out the cost components for running OpenSearch and Elasticsearch yourself, who is paid for each one and whether it is one-time or recurring. Use it to build the questions you put to each vendor, partner or internal team. No figures appear here because prices must come from a written quote or the vendor's current price list.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Infrastructure and storage	Your cloud provider or data center team	Recurring	Retention period, replica count, hot and warm tier sizing and ingest volume. Lifecycle policies and tiering reduce it; the frozen and cold tiers on Elasticsearch are a licensed capability to confirm for your subscription.
Staff skills and operating time	Your own engineers, or a partner you hire	Recurring	Team familiarity with the cluster, index lifecycle management and the security configuration. Both platforms need a dedicated owner for upgrades, shard health and capacity planning.
Elastic subscription tier	Elastic, through an annual subscription	Recurring	Which features you need. Basic includes TLS, file and native realms and role-based access control. Single sign-on, field and document-level security and anomaly detection sit in paid tiers. Platinum is no longer sold to new customers, so confirm the current option with Elastic.
OpenSearch licensing	No license fee to the project	Not applicable	Apache-2.0 licensing carries no license fee. Costs shift to hosting, staff and any support contract you choose to buy from a vendor or partner.
OpenSearch support from vendors and partners	Vendor or partner you contract with	Recurring if retained, one-time for setup	Scope of support, response expectations and whether you need upgrades, hardening or documentation. Ask each provider for a written scope and quote, and confirm what is included.
Implementation and migration	Implementation partner or your own team	One-time	Number of indices, custom ingest pipelines, client changes and whether data moves from Elasticsearch 6.0 through 7.10 or from a newer Elasticsearch line. Agree the scope in writing before work starts.
Upgrades and maintenance windows	Your team, or a partner on retainer	Recurring	OpenSearch targets a new minor version about every eight weeks and maintains each version until the next major enters maintenance or one year passes. Elastic maintains each major for a fixed window. Plan the cadence and test cycles against each schedule.

Moving from Elasticsearch to OpenSearch or back

This sequence shows what a team must confirm, inventory and rebuild before switching between Elasticsearch and OpenSearch, so the cutover does not lose security controls or detection content. It works the same way in either direction, but the reverse path depends more on which features are in use.

Confirm version and index compatibility
Start by recording the exact Elasticsearch or OpenSearch version on every node. OpenSearch is wire-compatible with Elasticsearch 7.10, can read indices created from Elasticsearch 6.0 through 7.10, and supports rolling upgrades from those versions, according to the OpenSearch FAQ. Check each index's creation version against that range, and list any indices created by a version outside it. The step is done when a written compatibility table names every index, its source version and whether it can move directly or needs reindexing. Confirm the target release line and its support window on the OpenSearch releases page before you commit to it.
Inventory plugins and paid features in use
Export the list of installed plugins, enabled security features, alerting rules, machine learning jobs and any detection or case management objects. Mark which items depend on a paid Elastic subscription tier, since Elastic places the detection engine, machine learning anomaly detection and case management under Platinum, and endpoint prevention and single sign-on under Enterprise, according to Elastic's subscriptions page. Ask the vendor or your support contact which of these exist in the target distribution. The step closes when every feature has one of three labels: carried over, replaced, or dropped with an approved risk note.
Rebuild security roles and single sign-on
Recreate roles, role mappings, tenants and field or document-level restrictions in the target security plugin, then reconnect the identity provider. OpenSearch Security supports SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JSON Web Token backends, and it provides document-level and field-level security, field masking and audit logs, according to the OpenSearch security documentation. Test each role with a named sample account and confirm it sees only the indices it should. Keep the old role definitions exported so an auditor can compare before and after. Done means a test matrix of users, roles and expected results has passed in a non-production cluster.
Migrate dashboards and detection rules
Export dashboards, saved searches, index patterns and detection rules, then import them into the target Dashboards or analytics tooling. OpenSearch Dashboards derives from Kibana 7.10.2, so objects from that line usually need less conversion, while later Elastic objects may need changes. Where OpenSearch Security Analytics is used, check that Sigma rules map to the log sources you ingest, because the documentation describes matching against prepackaged or custom Sigma rules. Review each rule for field name changes. The step is complete when each dashboard renders the same results on a copy of production data and each rule fires on a known test event.
Move data and validate against a parallel run
Move the indices, either by a documented migration path or by reindexing from the source, and run both clusters in parallel with the same log feeds for a period your security team sets. Migration Assistant is documented for moving data between clusters, and its guidance on whether it fits your case is part of the OpenSearch documentation. Compare document counts, alert volumes and query results per index. Any gap must be explained before cutover. Done when both clusters report matching counts and the team has signed off on the alert comparison in writing.
Cut over log shippers and retire the old cluster
Point agents, collectors and any downstream consumers at the new endpoints, keep the old cluster read-only for a rollback window your change process defines, and confirm that new events land in the new indices. Review TLS certificates and client trust stores at this point, since each endpoint change can break connections. The step closes when ingestion has run cleanly for the agreed window and no client still writes to the old cluster.
Plan the reverse path before you need it
Moving back from OpenSearch to Elasticsearch is not simply the reverse of the steps above, because it depends on which features are in use. Any feature that exists only in OpenSearch, or that you have rebuilt on OpenSearch Security, must be mapped to an equivalent Elastic feature and its license tier before work starts. Confirm index compatibility from the target side, since Elasticsearch release lines have their own support windows listed on Elastic's end-of-life page. Document this path as a separate runbook and test it on a copy of the cluster. Done when the team can state which features would need a paid subscription on the Elastic side and has a costed quote from its vendor or partner for that tier.

Where OpenSearch and Elastic implementation projects run long

The longest parts of an OpenSearch or Elastic project are rarely the initial install. Index lifecycle and storage tiers take the most design time, because log volume, hot, warm and cold data, and snapshot policy decide the node layout and disk budget. Elasticsearch exposes data tiers (hot, warm, cold and frozen) as node roles, and OpenSearch uses its own index state management model, so the lifecycle policies do not port one to one. Before sizing, ask the client for a data inventory listing each log source, its daily volume, its required search window and its retention period. Sizing for log volume is then an exercise in those numbers, not in a generic node count, and the result should be tested against a representative ingest rate before production cutover.

Identity integration and rule or dashboard migration are the next two sources of delay. On the OpenSearch side, the Security plugin covers SAML, OpenID Connect, LDAP and Active Directory, so the question is which of these your identity provider exposes and whether role mappings are already defined. On the Elastic side, single sign-on and field- or document-level security sit in paid subscription tiers, so confirm the licensing position before design starts. Detection rules, Sigma content and dashboards built on the Kibana or OpenSearch Dashboards side rarely move without rework, so inventory them early and decide which ones are still in use. Ask the client for identity provider access, a test tenant and a named owner who can approve role mappings.

Upgrade cycles set the operating rhythm and often cause the largest recurring effort. OpenSearch targets a new minor version about every eight weeks, and versions receive only bug fixes and security patches during maintenance, so the upgrade calendar must be planned rather than reacted to. Elastic publishes end of maintenance dates per release line, and the dates in the Elastic support pages should be checked against the version your cluster runs. Before the project starts, the client should name an owner for upgrades, agree a retention policy that limits how much data each upgrade must carry, and confirm who signs off on maintenance windows. Those three decisions determine whether a retainer or an internal team carries the work over the life of the platform.

Questions buyers ask before choosing or hiring help

Is OpenSearch free to run in production?

Yes, the OpenSearch software is licensed under Apache-2.0, and the OpenSearch FAQ does not describe any paid edition, so the engine, the Security plugin and Security Analytics carry no license fee. Your costs are the infrastructure you run it on, the people who operate it, and any outside help you buy. Elastic works differently. Its default distribution is under the Elastic License 2.0, which is not OSI approved, and its self-managed subscription tiers gate features such as single sign-on, endpoint protection and detection engine capabilities. Confirm in Elastic's licensing FAQ which license applies to your deployment and use case. If you plan to offer a logging service to other organizations, have counsel review the managed service terms before you build on either platform.

How much staff effort does running OpenSearch take compared with Elasticsearch?

Effort depends less on the license than on how many clusters you run, how often you upgrade and how much of the surrounding stack you own. OpenSearch targets a new minor version about every eight weeks, and each version stays in maintenance until the next major version enters maintenance or one year passes, whichever is longer. Maintenance releases carry bug fixes and security patches but no new features, so your team plans patch windows on a steady cadence. Elastic publishes its own end-of-maintenance dates, and the Elastic product end of life dates list October 15, 2027 for the 9.x core stack line and January 15, 2027 for 8.x. Both platforms require the same core skills: node roles, shard sizing, snapshots, certificate rotation and capacity planning. Ask any provider to split effort into build, run and upgrade work, and to name which tasks they own after handover.

Can I migrate from Elasticsearch to OpenSearch in place?

For some versions, yes. OpenSearch is wire-compatible with Elasticsearch 7.10, can use indices created by Elasticsearch 6.0 through 7.10, and supports rolling upgrades from those versions. A cluster on Elasticsearch 7.10 or earlier has a documented in-place path. From Elastic 8.x or 9.x, the facts available here do not establish a drop-in swap, so plan a data migration by reindexing, running both clusters in parallel, or using OpenSearch's migration tooling. Read the Migration Assistant guidance and confirm the supported source versions before you commit. Client applications, agents, index templates, ingest pipelines and Kibana saved objects each need a separate check, because wire compatibility with 7.10 does not guarantee that every API behaves the same way. Test on a copy of production data and keep snapshots for rollback.

What does a fixed-scope OpenSearch implementation include?

A fixed-scope engagement defines deliverables, covered systems and timelines in writing before work starts. For OpenSearch, the work can include planning, implementation in your cloud accounts, data centers or air-gapped networks, customization, integration, hardening, backups, upgrades, documentation and support handover, depending on what the written scope lists. A typical scope names the log sources to connect, the detections to build or tune, the identity provider to integrate, the retention and backup design, and the evidence to collect for compliance readiness. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications. Ongoing support, upgrades and continuous testing are separate retainers. DeployOpen does not publish a price list, so a quote follows from the scope. Ask for each deliverable, the data volume assumptions and the acceptance criteria.

Do I need Elastic's paid features for SIEM use?

It depends on which controls your SIEM design relies on. OpenSearch Security Analytics matches ingested logs against prepackaged or custom Sigma rules, records findings and correlates them across log types, so OpenSearch can serve as a SIEM backend without a separate product. The OpenSearch Security plugin adds SAML, OpenID Connect, LDAP, Active Directory, Kerberos and JWT authentication, role-based access control, document- and field-level security, field masking and audit logs. On the Elastic side, the free Basic tier includes TLS, the file and native realms and role-based access control. Elastic's subscriptions page places the detection engine, machine learning anomaly detection and case management under Platinum, which Elastic no longer sells to new customers, and endpoint malware prevention, host isolation and SAML or OpenID Connect single sign-on under Enterprise. Map each required control to a tier and confirm current entitlements with Elastic before you finalize the design.

What does my team need to provide for an OpenSearch engagement?

You need a named platform owner with time allocated, plus people who know your log sources, identity provider and incident response process. Your team provides access to the target environment, decisions on data sources and retention, detection priorities, and sign-off on alert routing and on-call. Ownership continues after handover: patching, certificate rotation, snapshot restore tests, index lifecycle changes and capacity reviews all need an internal owner. Without that owner, outside help becomes a recurring dependency. Engineers should be comfortable with Linux, VM or container operations, TLS and identity configuration. Security analysts should test each detection against actual events from your environment before relying on it. Ask any provider which tasks transfer to you, what runbooks they deliver and what knowledge transfer the written scope includes.

Primary sources for license and release facts

Before you commit to either platform, check the license, edition and release terms against the source documents yourself, because these change faster than a comparison page can track. Start with the OpenSearch FAQ to confirm that all OpenSearch project software remains under Apache-2.0 and that no paid edition is described. Then open the OpenSearch releases page and note which minor line you would deploy, its maintenance status and its end-of-life date, since OpenSearch maintains each version until the next major version enters maintenance or one year passes, whichever is longer.

For the Elastic side, read Elastic's licensing FAQ to confirm which of the three source licenses (ELv2, SSPL 1.0 or AGPLv3) applies to the distribution you intend to run, and what each one permits for a managed service or an internal platform. Then compare the Elastic subscriptions page against your requirements, paying attention to which security and alerting features sit in the free tier and which need Enterprise, and note that the Platinum tier is no longer sold to new customers. Ask your Elastic representative or reseller to confirm pricing and eligibility in writing, because the subscription page does not give a price list for your deployment.

Finally, check the Elastic product end of life dates for every Elastic major line you might inherit or migrate from, and set a calendar reminder for each end-of-maintenance date. Record the dates, version numbers and license identifiers you verified, with the date you checked them, in your architecture decision record. Repeat the check before any migration cutover, because a license or support change between evaluation and go-live would alter the total cost and the upgrade plan.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For OpenSearch vs Elasticsearch, we start by confirming license obligations, the features your security team needs and the migration path from your current cluster before any build work begins.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We confirm which license terms apply to your deployment model, including any managed service use.
We map required security controls, such as SSO, field-level security and audit logs, to the edition or plugin that provides them.
We record which Elasticsearch or OpenSearch APIs your ingest pipelines, dashboards and alerts depend on.

How we build

We deploy the chosen distribution using the install method your team can operate, such as tarball, packages, Helm or the Kubernetes Operator.
We configure TLS, role-based access control, and the authentication backend your identity provider supports.
We test ingest, search, alerting and rolling upgrade behavior against a staging cluster before production cutover.
We tune node roles, shard sizing and storage tiers against the log volumes you confirm during scoping.

How we hand over

You receive architecture, configuration and runbook documentation covering the cluster as built.
Migration plans include a rollback path, reindexing steps and validation checks agreed with your team.
We walk your operators through upgrades, backups and access reviews so the handover is practical.
Compliance evidence we prepare is documented for your assessors, who issue any audit reports or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover version upgrades when the maintenance window of your chosen release line changes.
Security testing of the deployed cluster and its integrations can be scoped separately in writing.
Ask for the retainer scope in writing, including response expectations, before you commit.

OpenSearch vs Elasticsearch