Migrate from Apache Solr to OpenSearch

None of the four documented OpenSearch upgrade and migration methods names Apache Solr as a source. OpenSearch documents rolling upgrades, snapshot and restore, remote reindexing and Migration Assistant. The first two are built around moving between versions of OpenSearch or Elasticsearch. Rolling upgrades apply to clusters already running OpenSearch, and to Elasticsearch clusters within the range the OpenSearch FAQ describes, which is indices from Elasticsearch 6.0 through 7.10. For a Solr collection, those methods are not a starting point. Your first question is which documented path, if any, accepts your specific Solr version, and the answer has to come from the current OpenSearch documentation.

Snapshot and restore and remote reindexing both depend on the source exposing its data through the mechanisms those methods use. Snapshot and restore moves data through a repository that the source cluster writes and the target cluster reads. Remote reindexing pulls documents from a source cluster's API into an OpenSearch index. Both methods are documented for Elasticsearch and OpenSearch sources. Treat them as unavailable for a Solr collection until the documentation for your target OpenSearch version says otherwise. Do not assume a method accepts another engine's data because the two products share some ancestry or similar concepts. Ask for the exact supported source versions in writing before the plan relies on either method.

Migration Assistant is the method designed to move workloads across several major versions in one step. Its documentation gives an example from Elasticsearch 6.8 to OpenSearch 2.19 and describes live traffic capture for low or zero downtime. Its documented sources are Elasticsearch and OpenSearch clusters. Whether it accepts your Solr version is a question you must confirm in the current Migration Assistant documentation, then prove on a test cluster loaded with a copy of a representative collection. Record the Solr version, the OpenSearch target version and the outcome of the test run, and keep that record with the migration plan so the decision can be audited later.

Without a supported path, the common approach is to export documents from Solr and bulk load them into OpenSearch indices that you create in advance. Another option is a custom pipeline that reads from Solr and writes through the OpenSearch bulk API. Neither route is a documented OpenSearch migration method, so your team or your implementation partner owns more of the work. That includes mapping Solr field types to OpenSearch mappings, keeping stable document identifiers, handling multivalued and nested fields, and deciding how writes that arrive during the export are captured. Ask for the chosen method, its validation steps and its rollback plan in writing before the build starts.

Choose the path before schema work begins, because the path sets the cutover pattern and the validation effort. If a documented method accepts your Solr version, schema and query work still applies, but the data movement becomes a documented procedure. If none does, plan a custom or bulk-load route with its own checks, including document counts per collection, sampled field-by-field comparisons and result comparisons between Solr and OpenSearch for your most-used queries. Keep the test cluster as a separate environment that someone can rebuild from scratch, so each test run starts from the same state.

Schema translation starts with pinning the source. Solr schemas, held in managed-schema or schema.xml, define field types that chain tokenizers and token filters, along with fields, dynamic fields and copyField directives. Each field type needs a counterpart in OpenSearch: a field mapping in the index template plus a custom analyzer in the index settings. Solr 6 through 9 differ in some behaviors, so the team must pin the exact source version before analysis begins and keep the configset under version control. Record the Solr release each collection runs today, along with the Java runtime it uses, because a translation checked against one release can be wrong for another. Mixed versions across collections are common in long-lived clusters, so confirm each one individually with the migration owner.

Tokenization is where most schema defects appear, so test it before indexing any production data. Assemble sample documents that cover stemming, stopword handling, synonyms, casing, punctuation, numeric and identifier strings, and every language your collections index. Run each sample through the analysis output for the pinned Solr version and through the OpenSearch _analyze API against the target index, then compare the token streams term by term. Filter order, filter class names and default parameters often differ even when the intent matches, so each mismatch needs a recorded decision: an equivalent filter, an adjusted parameter, or an accepted change. Confirm that each Solr filter has a supported counterpart in the OpenSearch 3 line in the project documentation before assuming a match. Store the sample set and expected tokens with the schema so later changes go through the same tests.

Query translation covers the parameters that application code sends with every request. The q and fq parameters, the choice of query parser, sort, rows, facet fields and hl highlighting settings each need an OpenSearch equivalent. The main query typically becomes a bool query, with scoring clauses in must or should and filter clauses in filter context, so filter queries stop contributing to relevance. Facets become aggregations, and their bucket limits, minimum counts and sort order must be set explicitly to match what users see today. Highlighting settings map to the highlight block, but fragment size and tag options should be confirmed against the front end that renders them. Local parameters, function queries and custom query parser plugins have no automatic translation, so list each one as a separate item with an owner and a test.

Expect relevance scores to differ, even when every analyzer matches. Solr and OpenSearch both build on Lucene, but query-time boosts, multi-field query handling, similarity parameters and the way queries are composed into clauses can produce different orderings. Treat raw score values as non-comparable across the two platforms and judge results by ordering for representative queries. Build a golden query set: a list of queries drawn from search logs and business owners, each paired with the documents that must appear in the top results and the documents that must not. Ask the search product owner to approve the expected results before cutover. Run the set against the source and target collections, record each difference, and decide which ones are acceptable tuning work and which ones block the cutover.

A write freeze is needed when the backfill has to read a consistent view of each Solr collection from start to finish. A bulk export and load can run longer than the window in which writes keep arriving. If documents are added, updated or deleted in Solr while the copy runs, the OpenSearch index can miss some changes, hold older versions of others, or keep documents that were deleted after they were copied. The freeze also has visible effects outside the migration team. Upstream indexing pipelines that write to Solr must queue, pause or fail, and their owners need to know which. End users may see search results that lag behind source records. Agree the freeze scope with the owner of every writer before anyone sets a date.

There are three ways to shorten the freeze, and each suits different pipelines. The first is capturing live writes during the backfill. Migration Assistant documents live traffic capture for low or zero downtime, but you must confirm that the path you choose captures Solr update requests for your source and target versions before you plan around it. The second is replaying a change feed. If your pipelines already publish each write to a durable queue, you can record writes from the snapshot point and apply them to OpenSearch after the bulk load. This works only when document IDs are stable across both systems and events for one document are applied in order. The third is batching a delta. After the bulk load, you copy only documents changed since the snapshot, which requires a reliable last-modified or version field in Solr, then freeze briefly for the final pass.

The length of the freeze depends on three things: collection size, indexing throughput at cutover, and the path you chose. None of these can be estimated reliably from outside your environment, because write rates during business hours and during batch jobs can differ a great deal. Measure on a copy of the production collections, not on a small sample. Time a full backfill, record the write rate of each pipeline over a representative period, and test whether a delta or replay catches up faster than new changes accumulate. Ask any implementation partner to show these measurements and the assumptions behind a proposed freeze window.

Before scheduling, make three decisions. First, identify every writer to each collection, including scheduled jobs and manual updates, because a missed writer will not show up as an error. Second, confirm that the chosen path reconciles deletes as well as adds. Third, set cutover criteria in writing, such as matching document counts and a sample of field-level comparisons, and keep the Solr collections intact and read-only until those checks pass so that you retain a rollback point. Ask for the rehearsal on a copy to be part of the quoted scope, since its results set the freeze length you will commit to.