Skip to content

Data & Search4 min read

Elasticsearch 8.x End of Maintenance (15 January 2027): What Changes and What to Do

Elasticsearch 8.x reaches end of maintenance on 15 January 2027. Plan upgrade or OpenSearch migration, rollback, and Australian data residency before EOM risk.

Share

Key takeaways

  • Elasticsearch 8.x: end of maintenance 15 January 2027, end of support 15 July 2027, plan for January, not July.
  • Elasticsearch 7.17 reached end of support on 15 January 2026, so those estates are already outside Elastic support.
  • Stage on 8.19.x and clear Upgrade Assistant blockers before Elastic 9.x; OpenSearch is a separate architecture decision.
  • Rollback is restore or traffic reversal. Elasticsearch does not support in-place downgrade.
  • Trim SIEM ingest before you migrate: less data to move, lower licence volume and a smaller cutover window.
  • Australian migrations can keep clusters, snapshots and replay in ap-southeast-2 or ap-southeast-4 when designed end to end.
On this page7 sections

Elasticsearch 8 end of maintenance lands 15 January 2027: the dated hook for estates still on 8.x and planning Elasticsearch upgrade services. This guide covers Elasticsearch end of life timelines, the Elasticsearch to OpenSearch migration decision, and OpenSearch migration services scope for Australian workloads that must stay in ap-southeast-2 or ap-southeast-4.

The dates that matter

Elastic separates maintenance (bug fixes, performance, security patches) from support (vendor assistance under support terms). Cite elastic.co/support/eol before locking a production date.

ReleaseEnd of maintenanceEnd of support
Elasticsearch < 7.17PassedPassed
Elasticsearch 7.17.x15 Apr 202515 Jan 2026 (unsupported)
Elasticsearch 8.x15 Jan 202715 Jul 2027
Elastic Enterprise Search 8.x15 Jan 202715 Jul 2027 (no 9.x)
Elasticsearch 9.x15 Oct 2027 baseline+6 months

15 July 2027 is a support tail, not six extra months of normal 8.x maintenance. If you are still on 7.17.x, stabilise and plan a supported target immediately.

Elasticsearch 8.x end of maintenance timeline showing 7.17 EOS, 8.x EOM 15 Jan 2027, and 9.x staging via 8.19.x

Classify your estate in 60 seconds

Current stateWhat it meansNext step
7.17.x or olderOutside Elastic supportEmergency stabilisation + target selection
8.0–8.17Not a sensible 9.x staging pointPlan path to 8.19.x
8.19.xCurrent staging family for 9.xUpgrade Assistant + restore rehearsal
Enterprise Search / App SearchNo 9.x continuationApp Search migration

A useful audit returns version bucket, blockers, target options, rollback mechanism and cutover sequence, not a generic “upgrade before EOL” slide. Run the 60-second estate classifier on the EOL hub.

Elastic 9 or OpenSearch?

Use the EOM pressure to decide deliberately, this is the core opensearch vs elasticsearch migration question:

Elastic 9 fits when you depend on Elastic security, observability, ML, Kibana features or Elastic Cloud operations.

OpenSearch fits when the workload is indexing, search and log analytics with portable APIs, especially when Apache 2.0 licensing, AWS integration or cost redesign matters.

To migrate Elasticsearch to OpenSearch, export what you actually use: templates, ingest pipelines, ILM, security realms, alerting, dashboards, transforms, ML jobs, plugins and client APIs, then score both targets against that inventory. Our OpenSearch vs Elastic cutover checklist and ELK on-call cutover guide cover mechanics; this article adds 8.x dated deadlines and Australian constraints.

Elasticsearch does not support in-place downgrade. Rollback is restore, rebuild or traffic reversal. Rehearse before production.

When EOL work becomes a SIEM cost decision

Log and security estates often hit the EOM date at the same time as a licensing review. If Elasticsearch carries your SIEM tier, treat SIEM migration services and platform EOL as one programme: trimming ingest before you move means you migrate less data, licence less volume and cut cutover risk.

The same applies to Splunk cost reduction, QRadar migration services or any effort to reduce SIEM ingest cost: filter and route noise first, then size the target cluster. Our noise-first SIEM migration cut ingest 58% before migration and halved SIEM spend with zero detection coverage lost.

Australian residency during migration

“Hosted in Sydney” is not enough for Elasticsearch support Australia residency reviews:

  • Source and target clusters in ap-southeast-2 or ap-southeast-4
  • Snapshot buckets and replication in approved Regions
  • Dual-write / replay queues and workers in-region
  • No raw payloads to overseas observability SaaS
  • Support bundles and CI fixtures with production data controlled

See Keeping Security and Search Logs in Australia and the Australia delivery hub.

Readiness checklist

  • Confirm exact Elastic Stack version, plugins, templates, ILM and client libraries
  • Decide Elastic 9.x vs OpenSearch from the feature inventory
  • Run Upgrade Assistant on supported 8.19.x
  • Test snapshot restore and record elapsed time
  • Replay representative queries; document count ≠ relevance
  • Define rollback metrics and owner before 15 January 2027

Our tier-1 bank ELK migration preserved detection coverage through dual-write. For SIEM cost pressure, see Splunk noise-first migration.

Limitations

Engineering guidance only. Not legal or licensing advice. Re-check Elastic's EOL page before production approval. Australian residency depends on architecture end to end, not Region selection alone.


Sources: Elastic EOL, Upgrade guidance, verified 8 August 2026.

Next step: Book a version audit · Elasticsearch EOL hub · Australia delivery

ElasticsearchOpenSearchEOLAustraliaMigration

Written by

Anurag Sogani

Founder & Principal Engineer, AiRAT

Anurag leads AiRAT's platform engineering practice, shipping production SOC, XDR and agent-security systems for regulated enterprises across UAE, India, Singapore, Europe, Australia and the US. He writes from delivery work: the frameworks here come out of live programmes, not vendor decks.

Common questions

6 questions

When does Elasticsearch 8.x reach end of maintenance?

Elastic currently lists 15 January 2027 as the end of maintenance for Elasticsearch 8.x, followed by end of support on 15 July 2027.

Is Elasticsearch 8.x end of maintenance the same as end of support?

No. Maintenance ends on 15 January 2027, while support continues to 15 July 2027. Elastic distinguishes product maintenance from support assistance.

Can we upgrade directly from any Elasticsearch 8.x release to the latest 9.x?

Not generally. For current 9.x releases, Elastic requires a supported 8.x staging version, normally the latest 8.19 patch, before the major upgrade and Upgrade Assistant remediation.

Should we upgrade to Elastic 9 or migrate to OpenSearch?

Choose from your actual dependencies: Elastic-specific features, plugins, licence posture, cloud preference, support model, client compatibility, relevance behaviour and migration cost.

Can an Elasticsearch migration keep data in Australia?

Yes. The source, target, snapshots, queues, replay workers and DR can be kept in Australian Regions such as AWS Sydney and Melbourne if no other service exports raw data overseas.

What should a version audit contain?

It should capture exact stack and client versions, plugins, index creation versions, mappings/templates, ingest pipelines, ILM, security configuration, dashboards, ML/transforms, data volume and tested restore time.

Stay current

Engineering insights, when we publish them.

Production notes on AI, security, and data infrastructure. No marketing, only the pieces worth reading.

No spam. Unsubscribe anytime.

Get started

Leave your email - we'll reach out.

Share your work email and we'll follow up with a tailored note on security, AI, or data programmes - usually within one business day.

No spam. We only use your email to respond to this request.

Explore services →