An Opensolr Index on an old Solr version moves to a current one in three steps: a new index, a configuration that loads on it, and a reindex from your own source. This is the overview; each step has its own page.
Three ways to do it
Option 1: Opensolr converts your configuration
A new index with your schema.xml and solrconfig.xml converted and loading, in under four business hours. You reindex.
Option 2: a new index with the default configuration
For schemas close to stock: create a new index, point your client at it, reindex.
Option 3: convert the configuration yourself
For heavily customised configurations, with the full conversion tables.
01 · Why migrate now
Solr versions older than 8.x are end-of-life upstream — no security patches, no bug fixes, and the Lucene index format is several majors behind. In practice that means:
- No vector / KNN search. Solr 9 added
DenseVectorFieldand{!knn}. On Opensolr, hybrid search, AI Hints and AI Reader run on the regions with site search, Solr 9.00 to 10.00 (regions). - Better relevance. BM25 tuning, edismax improvements, the unified highlighter, Learning-to-Rank — all matured significantly between 5.x and 9.x.
- Faster, smaller indexes. PointFields use BKD trees instead of TrieField term tokens. Range queries on numerics and dates run an order of magnitude faster, on-disk size shrinks.
- Security. CVE coverage stops at the version Apache currently supports. Old Solr also ships with default request handlers (e.g.
/replication?command=...) that have known abuse vectors. - Server retirements. Solr versions below 8.x are retired on Opensolr on 01/01/2027. If your index runs one of them, you receive an email with the cutoff date and the affected index names.
02 · Configurations move. Data does not.
A Solr backup is a snapshot of the Lucene segment files (.cfs, .fdt, .tim, .si, segments_N). Lucene reads segments only from the previous major version — Solr 9 reads Lucene 9 and Lucene 8 segments and nothing older. Try to open a Lucene 5 / 6 / 7 segment in Solr 9 and the IndexReader throws IndexFormatTooOldException at startup.
There is therefore no “upgrade in place” path. A migration always means:
- Provision a brand-new index on a current Solr version.
- Convert the configuration files (
schema.xml,solrconfig.xml, plus any stopwords / synonyms / protected-words text files) so they load on the target Solr. - Reindex every document from your source-of-truth — the place that originally fed the old index. Database, CMS, file store, crawler, ingestion API, whatever it is.
Step 1 and Step 2 are what Opensolr does for you under option 1. Step 3 is yours, every time, regardless of which option you pick. The cost-and-time of step 3 depends entirely on how big and how reachable your source-of-truth is.
One exception — if your only source of data is the old Solr index itself (you no longer have the database / CMS / file store that fed it), how to reindex has a fallback cursorMark dump-and-reload script. It works most of the time but it is not a real reindex — it cannot regenerate fields whose values are computed at index time. Read the caveats first.
03 · Parallel running and cutover
There is no rip-and-replace day. The old index and the new index run side by side for as long as you need to be confident in the new one — up to the retirement date communicated in your email.
Timeline shape
- Day 0: we provision the new index (different name, different cluster) and load the converted config. Old index is untouched, still serving production traffic.
- Day 0–N: you reindex into the new index from your source-of-truth. The old index stays writable so production can continue indexing into it during this period if you want.
- Day N: you validate the new index (doc count parity, sample query parity — see validation and cutover), then point your application at the new connection details.
- Day N+x: after a quiet observation window, you delete the old index from the Opensolr control panel. The old server slot is freed and can be retired.
- Hard deadline: the retirement date in the email. Old index stops accepting traffic on that date regardless of where you are in the process — plan accordingly.
During the parallel period your application can either keep talking to the old index only (simplest) or dual-write to both (zero data loss across the cutover). Dual-write only matters if you are still adding documents during the migration window. For static or slowly-changing indexes a single read-write source — the old one — is fine until the moment of cutover.
04 · Questions
Will I lose data?
No. The old index stays untouched throughout. You delete it yourself once the new one is good. Both run in parallel until the retirement date.
How long does the config migration take?
On our side: under 4 business hours from receipt of payment, regardless of index size. The reindex on YOUR side depends on your data volume and source-of-truth speed — minutes for small sites, hours-to-days for large catalogs.
Is there downtime?
No. The old index stays live until you flip your application config. Cutover is a single config change on your side, instantaneous.
Why can't you migrate the data too?
Lucene index segments are not forward-compatible across major versions. There is no way to read Solr 5/6/7 segments with Solr 9. Apache Solr itself does not offer this. Reindex from your source-of-truth is the universally correct answer.
Will my queries break?
Common edismax / dismax / lucene syntax is identical. Things to verify: defaultSearchField / defaultOperator assumptions (now per-request), faceting on numerics (need docValues), highlighting params with hl.q wrappers.
What if I have replicas?
We rebuild the leader/follower setup on the new environment and replicate the converted config to every follower automatically.
What about my custom plugins / JARs?
Custom Java plugins must be recompiled against the target Lucene/Solr version. Send the source / JAR — we quote separately if recompilation is needed. This is rare.
Can I get vector / hybrid / AI search after migrating?
Yes, when the new index is in a region with site search (regions). Every plan includes a monthly AI allowance of 500 AI requests; see pricing and API Quota. How it works: hybrid search.
Where do my old backups go?
Existing backups stay with the old index until it is deleted or retired. Download the ones you want to keep (download a backup): they cannot be restored into a newer major version, so they are an archive only.
What if I miss the retirement deadline?
Do not wait for it: Solr versions below 8.x are retired on 01/01/2027, and the cutoff date is in the email you receive. Start the move early enough to reindex and validate before that date.
What if I don't have a source-of-truth anymore?
Use the cursorMark dump-and-reload script in how to reindex as a fallback. Read the caveats first — computed fields, embeddings, and parent/child links cannot be reproduced this way. The dump is a copy of the stored fields, not a true reindex.
Solr migration
Solr migration: overview (this page)