If you're still comparing options, we cover them in ELK stack alternatives. The job on a self-managed Elasticsearch + Logstash + Kibana + Beats cluster is narrower: keep new logs searchable, decide whether old indexes are worth copying, and stop Beats 8.x from talking to an engine that will fail its version check. This is the cutover onto Hosted OpenSearch, part of the same series as our Splunk and Datadog Log Management guides. For a managed Elastic comparison, see the Elastic Cloud alternative page.
Contents
- The 7.10.2 fork blocks Elasticsearch 8 snapshots
- Dual-ship, Logstash copy, or let indexes age out
- Beats 8.x refuses OpenSearch; Logstash and Fluent Bit do not
- Index templates and ILM are not ISM
- Kibana NDJSON: classic objects yes, Lens and ES|QL no
- Watcher and Elastic roles stay on the old cluster
- Dual-run: counts, mappings, Discover, then rollback
- Flip the fleet and decommission Elasticsearch
The 7.10.2 fork blocks Elasticsearch 8 snapshots
OpenSearch forked the last Apache-2.0 Elasticsearch line at 7.10.2. That date is not trivia. AWS’s migration guidance is explicit: you cannot restore snapshots from Elasticsearch 7.11 or later (including every 8.x cluster) onto OpenSearch. Indexes created on those versions are not snapshot-compatible with the fork. Elasticsearch 6.x/7.10-era snapshots can restore into OpenSearch 1.x in a cluster you fully control; OpenSearch then only promises snapshot restore forward by one major version of OpenSearch itself. See AWS snapshot migration and OpenSearch’s snapshot restore for migration.
On Logit.io the second constraint bites harder than the first. Managed stack limitations state that repository registration and snapshot lifecycle are platform-managed. Even a perfectly compatible 7.10.2 snapshot is not something you register onto https://{stack-id}-es.logit.io yourself. Treat snapshot/restore as a self-managed-cluster technique, not the hosted cutover.
Dual-ship, Logstash copy, or let indexes age out
Pick the data path from the source version and whether compliance actually needs the old indexes:
- Dual-ship new events and let old indexes age out. Default for log clusters on a 14–90 day retention. Point a canary at Logit, prove Discover, then flip the fleet. History dies with your Elasticsearch ILM/delete policy. No snapshot, no reindex tax.
- Copy history with Logstash. Required when the source is Elasticsearch 7.11+ or 8.x, or when you must keep a window of old documents. Official OpenSearch tools docs recommend Logstash with an Elasticsearch input and the OpenSearch output plugin for post-fork sources. Prefer Logstash 7.16.x (or a later 8.x build with the plugin installed) over “whatever 8.x default output you already have.”
- Reindex-from-remote. OpenSearch’s reindex API can pull from a remote cluster, but SSL and
reindex.remote.whitelistlive inopensearch.ymland need a restart. On a managed stack those persistent settings are often rejected. Do not plan the project around remote reindex unless support confirms the whitelist. Same API is fine for reindexing inside your Logit stack after data has landed.
If you still run Elasticsearch 7.10.2 on hardware you own, snapshot/restore onto a throwaway OpenSearch 1.x box can be a one-off archive. It is not the hosted Logit path.
Beats 8.x refuses OpenSearch; Logstash and Fluent Bit do not
OpenSearch’s compatibility matrix is blunt: Beats newer than 7.12.x are not supported. Elastic-licensed Filebeat 7.13+ and all 8.x default distributions run a version/license check against the search engine. Pointing them at OpenSearch fails that check. The last OSS agents listed as compatible are Filebeat, Metricbeat, Packetbeat, Heartbeat, Winlogbeat and Auditbeat OSS 7.12.1 (use OSS 7.10.2 if you rely on ingest pipelines — OpenSearch notes pipeline bugs on 7.12.x). OpenSearch 1.x/2.x can fake 7.10.2 with compatibility.override_main_response_version; OpenSearch 3.x removed that setting, and on Logit you may not be able to persist it anyway.
Do not fight the check. On a Logs stack, ship through Logit’s hosted Logstash so Beats never speak OpenSearch HTTP. Copy hosts from Settings → Endpoints / Install Integration, matching Filebeat, and replace the placeholders with your stack’s Logstash host and SSL port:
output.logstash:
hosts: ["@logstash.host:@logstash.sslPort"]
loadbalance: true
ssl.enabled: true
If you must keep a local Logstash pipeline, the Logs-stack output in local Logstash configuration is TCP/SSL JSON lines into hosted Logstash — not the Elasticsearch output plugin. Again, replace the placeholders with your stack’s Logstash host and SSL port:
output {
tcp {
codec => json_lines
host => "@logstash.host"
port => @logstash.sslPort
ssl_enable => true
}
}
For a dedicated cluster, install logstash-output-opensearch and point hosts at the REST URL from connect to your cluster (the {stack-id}-es.logit.io host in cluster settings). Fluent Bit is the clean escape hatch when you will not pin OSS Beats 7.12.1: it has no Elastic version check. Create the stack first via creating an OpenSearch cluster when the destination is dedicated Hosted OpenSearch; otherwise a log management stack (from $25/mo annual) is the shipper-first path. Same decision as in log stack vs Hosted OpenSearch.
Unlock complete visibility with hosted ELK, Grafana, and Prometheus-backed Observability
Index templates and ILM are not ISM
Elasticsearch index templates do not become OpenSearch ISM policies. On hosted stacks, managed stack limitations and the Index and Template APIs let you create custom indexes with explicit mappings via PUT /{index}, manage aliases, and read templates — not rewrite composable or legacy templates yourself. Put the mapping you need on the create-index request; contact support if a stack-wide template has to change. Elasticsearch ILM has no import into OpenSearch ISM. OpenSearch Index State Management is a different JSON policy (states, transitions, ism_template). OpenSearch Migration Assistant also lists ILM/ISM as manual. On Logs stacks, day-to-day retention is still the plan window, not a DIY hot/warm/delete ladder you snapshot yourselves. Rebuild only the rollover rules you actually need; do not port every ILM phase “because it existed.”
Kibana NDJSON: classic objects yes, Lens and ES|QL no
Export saved objects from Kibana as NDJSON and import under OpenSearch Dashboards (Management → Saved objects). Classic dashboard, visualization, search, and index-pattern objects from the 7.10-era UI often load. OpenSearch’s saved objects docs and the dashboardsSanitizer are honest about the rest: Lens, Canvas, maps, graph, connectors, and rules are omitted. ES|QL-era Discover/Lens objects are Elasticsearch 8 features — there is no conversion. Sanitize exports from Kibana 7.10.2–8.x before import; then rebuild Lens boards as aggregation visualizations. Expect to redo the paging dashboards by hand rather than celebrating a green import of 200 objects of which 40 were Lens.
Watcher and Elastic roles stay on the old cluster
Watcher watches and Kibana alerting rules do not become OpenSearch monitors. Recreate the watches that page humans as OpenSearch Alerting monitors (or ElastAlert 2 YAML on a Logs stack — see the alerting overview). Start with severity, not the full Watcher inventory.
The same is true of Elasticsearch native roles and the security plugin. You cannot administer /_plugins/_security as a customer on hosted stacks. Map people in Logit.io account roles and Dashboards tenants, not by dumping .security indexes. API keys from Endpoints are the stack’s programmatic user; they are not your old elastic superuser.
Dual-run: counts, mappings, Discover, then rollback
Keep Elasticsearch accepting writes until these checks pass on a canary index pattern (for example filebeat-* or logstash-*):
GET {index}/_counton source vs destination for the same time window (expect ingest lag, not a byte-identical archive).GET {index}/_mappingfor the fields you page on — keyword vs text vs date mismatches break aggregations even when the count looks fine.- In Discover: time field set, last-15-minutes populated, one known host and one known error string, plus a saved search that used to be a Watcher input.
Rollback is boring: leave dual-ship in place, point Beats/Logstash back at Elasticsearch only, and do not delete the old cluster or its ILM policies until the dual-run window you agreed with the on-call team expires. Dedicated OpenSearch nodes are priced per node on OpenSearch pricing from $45.52/node/mo annual; Logs from $25/mo, Metrics from $12/mo, APM from $20/mo annual only if those products are in scope. Any sizing table you show finance is a planning assumption unless you measured pri.store.size on your own cluster.
Flip the fleet and decommission Elasticsearch
Open a 14-day trial, create the Logs stack or dedicated cluster, and copy endpoints from the dashboard — not from an old internal wiki. Point one OSS Beat, local Logstash, or Fluent Bit canary at those endpoints, pass the dual-run checks, recreate the first monitor, then retire Elasticsearch HTTP from the rest of the fleet. Leave Kibana up in read-only until the NDJSON import (and the Lens rebuilds) are done. When Discover is where the team actually searches, stop the old cluster. Product detail lives on the Hosted OpenSearch overview; node rates on the pricing page above.
