You're viewing the current version of Migration Assistant documentation (Kubernetes/EKS-based). For the classic ECS/CDK-based version, see the classic documentation.

Solr migration

Solr migrations use a different architecture than Elasticsearch migrations because Solr and OpenSearch have fundamentally different schema formats and data layouts.

Supported versions

The following table lists the supported source and target versions.

The version string in your workflow configuration must match the format SOLR <major>.<minor>.<patch>. Examples: SOLR 8.11.4, SOLR 9.7.0, SOLR 6.6.0.

Solr migration differences

Unlike Elasticsearch, which shares a common Lucene data format and similar REST API with OpenSearch, Solr uses its own schema format (schema.xml) and a different Lucene index layout. Solr migrations use a specialized component called SolrReader, which reads Solr backup data and translates Solr schemas to OpenSearch mappings. For step-by-step S3 backup setup and workflow configuration, see the Solr backfill guide.

Migration phases

Solr migrations follow these phases.

Phase 1: Data migration (backfill)

1. Create a Solr backup – Use Solr’s backup API for SolrCloud collections, or file-system copy for standalone cores.
2. Run SolrReader – Reads the Solr backup’s Lucene segment files, extracts documents, and translates Solr schema.xml field types into OpenSearch mappings.
3. Bulk-index into OpenSearch – Documents are indexed into the target with translated mappings.

The following table shows how SolrReader performs schema translation.

Phase 2: Validate and cutover

After backfill completes, validate document counts and sample queries against the target. Once confident, point your application directly at OpenSearch.

Solr migrations support backfill only—Capture and Replay (live traffic migration) is not supported for Solr sources. You will need to update your application’s query layer to use the OpenSearch API.

Migrated components

---

Related documentation

• Solr backfill guide