Clarification on Reindex Requirement: ES 7.17 → OpenSearch 2.19

OpenSearch
1

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):Elasticsearch: 7.17.29
OpenSearch: 2.19.5
OpenSearch Dashboards: ( not using)
JDK: 17
OS: ( Windows/Linux)
Browser: (Chrome)

Describe the issue:

We are migrating from Elasticsearch 7.17.29 to OpenSearch 2.19.5.

As per OpenSearch documentation, index compatibility is supported from 6.8 up to Elasticsearch 7.10. However, in our case, we performed the following:

  • Copied the path.data directory from Elasticsearch 7.17.29
  • Started OpenSearch 2.19.5 using that data
  • OpenSearch started successfully
  • Indices are accessible and searchable without errors

Example:
“version.created”: “7172999” (Elasticsearch 7.17 index)

Basic queries like _search are working correctly:

  • No shard failures
  • Documents are returned as expected

This creates confusion regarding whether reindexing is actually required.

Configuration:

Migration approach:

  • Source: Elasticsearch 7.17.29
  • Target: OpenSearch 2.19.5
  • Method used: Direct copy of path.data (no reindex performed)

Cluster behavior:

  • OpenSearch starts without errors
  • Indices are in green state
  • Queries work as expected

We are not using features introduced after Elasticsearch 7.10 (to the best of our knowledge).

Relevant Logs or Screenshots:

Index version check:
GET _all/_settings?filter_path=**.version.created

Output:
“version.created”: “7172999”

================================

Search test:
GET /as012026/_search

Result:

  • hits returned successfully
  • _shards.failed = 0

======================================

info:
GET /

Response:
{
“name”: “AlphaCentauri”,
“cluster_name”: “acqu”,
“version”: {
“distribution”: “opensearch”,
“number”: “2.19.5”,
“lucene_version”: “9.12.3”,
“minimum_wire_compatibility_version”: “7.10.0”,
“minimum_index_compatibility_version”: “7.0.0”
}
}

Observation:
OpenSearch reports minimum index compatibility version as 7.0.0, while our index was created in Elasticsearch 7.17. This adds to the confusion since the index is working despite documentation mentioning compatibility up to 7.10.

(No errors observed in logs so far)

Questions:

  1. Is reindexing mandatory when migrating from Elasticsearch 7.17.x to OpenSearch 2.19.5?
  2. Is copying path.data a supported migration approach, or is this considered unsafe?
  3. Should reindexing be done:
    • From Elasticsearch → OpenSearch (recommended approach?)
    • Or within OpenSearch after copying data?
  4. Are there risks related to:
    • Future OpenSearch upgrades
    • Lucene compatibility
    • Snapshot/restore or shard recovery?
  5. If we are not using features beyond Elasticsearch 7.10, does that make this approach valid?

I want to confirm whether the current working setup is officially supported or just incidental behavior.

Best regards,

Ajay.

2

@ajay459 I’m curious about the migration process.

Did you copy all of the files from the /usr/share/elasticsearch/data? How did you deploy your cluster (Docker, Helm charts or binary)?

Also could you send settings of one of the indices in your running OpenSearch cluster?

GET <index_name>/_settings
3

Hi @pablo ,

1)Did you copy all of the files from the /usr/share/elasticsearch/data?

Yes

2)We are using embedded elasticsearch(jars).

3)GET <index_name>/_settings

{
  "temporary": {
    "settings": {
      "index": {
        "replication": {
          "type": "DOCUMENT"
        },
        "number_of_shards": "1",
        "provided_name": "temporary",
        "max_result_window": "65536",
        "creation_date": "1776331690341",
        "analysis": {
          "analyzer": {
            "case_insensitive_sort": {
              "filter": [
                "lowercase"
              ],
              "tokenizer": "keyword"
            }
          }
        },
        "number_of_replicas": "0",
        "uuid": "RWHCqNYZSpST5GUnng-pRw",
        "version": {
          "created": "136408327"
        }
      }
    }
  }
}

We are using below mentioned mapping.json and settings.json.

mapping.json:

==================

{
	"date_detection": false
	,"numeric_detection": false

	, "properties": {
		"es:type": {
			"type": "keyword"
		},
		"bt:md-dse": {
			"type": "long"
		},
		"cmis:contentStreamFileName": {
			"type": "text",
			"fields": {
				"raw": {
					"type": "keyword"
				}
			}
		},
		"cmis:contentStreamLength": {
			"type": "long"
		},
		"cmis:contentStreamMimeType": {
			"type": "keyword"
		},
		"cmis:createdBy": {
			"type": "keyword"
		},
		"cmis:creationDate": {
			"type": "long"
		},
		"cmis:lastModificationDate": {
			"type": "long"
		},
		"cmis:lastModifiedBy": {
			"type": "keyword"
		},
		"cmis:name": {
			"type": "text",
			"fields": {
				"raw": {
					"type": "keyword"
				},
				"lower_case_sort": {
					"type": "text",
					"analyzer": "case_insensitive_sort"
				}
			}
		},
		"cmis:objectId": {
			"type": "keyword"
		},
		"cmis:baseTypeId": {
			"type": "keyword"
		},
		"cmis:objectTypeId": {
			"type": "keyword"
		},
		"cmis:secondaryObjectTypeIds": {
			"type": "keyword"
		},
		"cmis:versionLabel": {
			"type": "keyword"
		},
		"cmis:versionSeriesId": {
			"type": "keyword"
		},
		"es:cAcl": {
			"properties": {
				"read": {
					"type": "keyword"
				}
			}
		},
		"es:owner": {
			"type": "text",
			"fields": {
				"raw": {
					"type": "keyword"
				}
			}
		},
		"bt:checksum": {
			"type": "keyword"
		},
		"bt:datasourceid": {
			"type": "keyword"
		},
		"cmis:repositoryId": {
			"type": "keyword"
		},
		"bt:docid": {
			"type": "keyword"
		},
		"bt:fsa_accessTime": {
			"type": "long"
		},
		"bt:fsa_archiveFlag": {
			"type": "boolean"
		},
		"bt:fsa_creationTime": {
			"type": "long"
		},
		"bt:fsa_filePath": {
			"type": "text",
			"fields": {
				"raw": {
					"type": "keyword"
				}
			}
		},
		"bt:fsa_fileSize": {
			"type": "long"
		},
		"bt:fsa_hiddenFlag": {
			"type": "boolean"
		},
		"bt:fsa_modificationTime": {
			"type": "long"
		},
		"bt:fsa_owner": {
			"type": "keyword"
		},
		"bt:fsa_readOnly": {
			"type": "boolean"
		},
		"bt:fsa_symLink": {
			"type": "boolean"
		},
		"bt:fsa_systemFile": {
			"type": "boolean"
		},
		"bt:tags": {
			"type": "keyword"
		},
		"cmis:description": {
			"type": "text",
			"fields": {
				"raw": {
					"type": "keyword"
				}
			}
		},
		"cmis:checkinComment": {
			"type": "text",
			"fields": {
				"raw": {
					"type": "keyword"
				}
			}
		},
		"bt:retention_period": {
			"type": "long"
		},
		"cmis:rm_expirationDate": {
			"type": "long"
		},
		"es:parents": {
			"type": "keyword"
		}
	},
	"dynamic_templates": [
		{
			"strings": {
				"match_mapping_type": "string",
				"mapping": {
					"type": "text",
					"fields": {
						"raw": {
							"type": "keyword"
						}
					}
				}
			}
		}
		,{
			"decimals": {
				"match_mapping_type": "double",
				"mapping": {
					"type": "double"
				}
			}
		}
	]
}

=========

settings.json:

{
  "analysis": {
    "analyzer": {
      "case_insensitive_sort": {
        "tokenizer": "keyword",
        "filter": ["lowercase"]
      }
    }
  },
  "index": {
    "max_result_window": 65536,
    "number_of_shards": 1,
    "number_of_replicas": 0
  }
}
4

@ajay459 This is interesting. I’ve tried your approach with clean ES 7.17.29 and 2.19.5

OpenSearch nodes dies with the following errors

  • unknown field [geoip-downloader] while parsing persistent_tasks
  • data_stream unknown field [_meta]
  • Skipping unknown custom object with type index_lifecycle
  • Skipping unknown custom object with type licenses

Did you remove any plugins from OpenSearch or Elasticsearch default deployment? Did you remove any system indices from ES before doing migration?

Regarding the process itself, it is not documented and not recommended.
Without working example, I can assume that upgrade process mail fail without reindexing.
Each index has OpenSearch version ID attached. This version is checked during each upgrade. OpenSearch may fail to proceed with upgrade if won’t recognise the version.

5

hi @pablo ,

Yes, we removed Elasticsearch and OpenSearch plugins because our deployment is embedded and relies only on required modules and jars. We also removed system indices from Elasticsearch prior to migration.

image
image1004×534 28.2 KB

Regarding the versioning point: it is correct that each index carries an internal version identifier, and OpenSearch validates this during upgrade or usage.

However, in our observed setup:

  • After copying path.data from Elasticsearch (7.17.29) to OpenSearch (2.19.5), we perform a reindex operation in OpenSearch instance.

  • The newly created index in OpenSearch is then assigned an OpenSearch-specific version.created value.

  • Even without reindexing, when an Elasticsearch-created index is accessed in OpenSearch, the Opensearch automatically adds an "upgraded" version field.

Example:

"version": {
  "created": "7172999",
  "upgraded": "136408227"
}

This indicates:

  • created → original Elasticsearch version (7.17.x encoding)

  • upgraded → OpenSearch internal version assigned after the index is opened/used

From this behavior, OpenSearch appears to recognize and annotate legacy Elasticsearch indices rather than rejecting them outright.

Regarding the statement that the process is not documented or recommended — that is understood. However, based on the cluster response below:

GET /
{
  "version": {
    "distribution": "opensearch",
    "number": "2.19.5",
    "minimum_wire_compatibility_version": "7.10.0",
    "minimum_index_compatibility_version": "7.0.0"
  }
}

The key point is:

"minimum_index_compatibility_version": "7.0.0"

This explicitly indicates that OpenSearch 2.19.5 supports indices created from version 7.0.0 and above.