2026-06-16

Before and After: What Changes When You Move to OpenSearch LTS

Learn what changes with OpenSearch LTS and the key factors to consider when evaluating an accredited provider.

Reading time: 5 minutes

By Alannah Melly

The launch of the OpenSearch Long-Term Support (LTS) program at OpenSearchCon Europe in April 2026 introduces something that has been absent from the OpenSearch ecosystem since the project’s inception: a formalised, structured path from “running open source software in production” to “running supported, auditable, enterprise-grade infrastructure.”

For organisations that have been waiting for that structure before committing fully to OpenSearch for mission-critical workloads, the program removes the last remaining hesitations. But understanding what it delivers — and what to look for when choosing an accredited provider — is important context before making that commitment.

What Running OpenSearch Without LTS Actually Looks Like

Most teams running OpenSearch in production before the LTS program worked around the absence of formal support structures through a combination of internal expertise, community monitoring, and informal vendor relationships. This works — until it doesn’t. The failure modes are predictable:

A version reaches end-of-maintenance quietly, with no formal notification or transition plan.
A CVE is disclosed and the team has no committed patch timeline — only a community issue tracker to monitor.
An audit asks for vendor accountability documentation that doesn’t exist.
Version debt accumulates because there is no structured upgrade path or support window to plan around.

None of these are failures of the open source model. They are the natural consequence of applying enterprise support expectations to a project that, until now, hadn’t formally defined them.

What Changes with LTS

The LTS program introduces defined answers to each of these failure modes:

	Without LTS Support	With Eliatra LTS Support
Support lifecycle	Versions go end-of-maintenance with no formal notice	18-month minimum per LTS release (2.19 and 3.6 first)
CVE response	No guaranteed timeline	60-day maximum for medium/high severity CVEs
Security notifications	Public disclosure only	Early alerts for accredited providers
Compliance documentation	No SBOM artefacts available	SBOMs across all 152 OpenSearch repositories
Vendor accountability	No certified vendor	Foundation-accredited provider, vetted and named
Codebase integrity	Risk of proprietary forks	No-fork policy — all fixes contributed upstream

The No-Fork Policy and Why It Matters

One of the most important and least-discussed aspects of the LTS program is the upstream-first development requirement. Any fix or patch developed for an LTS version by any accredited provider must be contributed back to the main OpenSearch project.

This matters for two reasons. First, it prevents the silent fragmentation that happens when commercial vendors maintain private patched branches — a situation that creates supply chain audit complexity and, over time, meaningful divergence from the open source codebase. Second, it means improvements made by any one accredited provider benefit all OpenSearch users, not just paying customers. The program is designed to strengthen the open source commons, not extract value from it.

What to Look for in an Accredited Provider

The Foundation accreditation model means there will be multiple vetted providers to choose from. Here is what matters when evaluating them.

Depth in the OpenSearch Ecosystem

Accreditation sets a floor, not a ceiling. The most valuable LTS providers are those who have been deeply embedded in OpenSearch — contributing code, maintaining repositories, and supporting customers in production — long before the formal program existed. That prior expertise is what makes LTS support substantive rather than nominal.

Security Specialisation

A 60-day CVE remediation SLA is only meaningful if the provider has the security engineering capacity to back it up. Look for providers with a demonstrated track record of security work in the OpenSearch project itself, not just operational support.

European Coverage and Data Sovereignty

For organisations subject to GDPR, the CRA, or data localisation requirements, the jurisdiction and operational location of your support provider matters. Not all accredited providers are equivalent here.

Upstream Contribution History

The no-fork policy is enforceable through the Foundation, but a provider’s prior history of upstream contribution is a strong leading indicator of how seriously they will treat that obligation. Providers who have been contributing to OpenSearch for years before accreditation are more likely to maintain that commitment under the program.

Why Eliatra

Eliatra is one of three founding accredited providers under the OpenSearch Software Foundation’s LTS program. We are a founding member of the Foundation itself. Our engineers maintain the Security and Operator repositories for OpenSearch — two of the most critical components for enterprise deployments. We created Search Guard, the security plugin that became foundational to OpenSearch Security.

We have been supporting OpenSearch in production since its earliest days, with customers in financial services, healthcare, public sector, and technology across Europe and beyond. The LTS program formalises what we have always done — and gives our customers a structure to point to.

For organisations that have been running OpenSearch with informal support arrangements, or that have been deferring a move to OpenSearch because of the absence of formal support guarantees, the LTS program closes that gap.

Ready to move to a supported, auditable OpenSearch deployment? Contact Eliatra to discuss your LTS options. https://eliatra.com/opensearch-lts/