hostedapachesolr.com shut down permanently on October 31, 2022, and its indexes cannot be recovered. If a Drupal tutorial or an old README sent you there, this is how to move the search of your site to an Opensolr Index.
Pick a region close to your site and the Solr version your Search API module expects. Steps: create an index.
Connect Drupal
Either install Opensolr Search, the Opensolr module for Drupal, or keep Search API Solr: point its server at the address and login of the index (address and login) and upload the config set Search API generates as one ZIP (upload a ZIP).
Reindex
Run drush search-api:index, or start indexing from the Drupal UI. The index is rebuilt from your site, so nothing has to be exported from the old service.
Verify
Search on your site, then open the index in the Opensolr control panel and watch the requests arrive in Live Query Stream.
02 · Not on Drupal
WordPress has the Opensolr Search plugin. Any other stack talks to the index through the standard Solr HTTP endpoints, and the Opensolr account through the REST API.
03 · What you get
Configuration files edited in the browser: configuration.
Site search with crawling, hybrid search and a hosted search page: Enterprise Site Search.
Query analytics, a live request stream and an error audit: analytics.
Backups on demand or every day, with self-service restore: backup.
HTTP authentication and IP rules on every index: security.
Sites running the Opensolr module for Drupal or the plugin for WordPress can get the partner discount: partner discount.
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.
Configurations move. Data does not. Solr cannot open an index written by an older major version, so there is no in-place upgrade. A migration is always a new Opensolr Index, a configuration that loads on it, and a full reindex from your own source: database, CMS, files or crawler. The old index keeps serving until you switch over.
Solr versions below 8.x are retired on Opensolr on 01/01/2027. The Solr versions you can pick today: regions.
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 DenseVectorField and {!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.
Apache Solr 10.0.0 was released on 3 March 2026. It is a real release with real engineering in it, and for website search it changes almost nothing you or your visitors would notice. Here is what Solr 10.0 adds, what it removes, why it leaves search relevance exactly where it was, and how to create a Solr 10 index on Opensolr today.
Solr 10.0 in one picture. The top half is what changed upstream. The bottom half is what your visitors actually use.
01 · WHAT SOLR 10.0 ACTUALLY ADDS
The Solr 10 upgrade notes group the changes into three areas. Most of them live below the surface your application talks to.
A newer runtime
Solr 10 requires Java 21 and runs on Jetty 12 and Lucene 10. Tracing moved from OpenTracing to OpenTelemetry, and ZooKeeper access now goes through Apache Curator. This is maintenance of the platform underneath Solr, not new search behaviour.
Cheaper and faster vector lookups
New quantized vector field types store each vector in fewer bits, which cuts memory at some cost to accuracy. The kNN parser gains efSearchScaleFactor, an early termination strategy, lexically seeded graph exploration and ACORN filtering for filtered vector queries. GPU vector search is available through a pluggable codec. All of these make vector retrieval lighter. None of them decide which document ranks first.
Admin and tooling
An experimental new Admin UI ships alongside the existing one, and the command line tools accept a --credentials option for Basic Authentication.
02 · WHAT IT DOES NOT CHANGE: RELEVANCE
Good website search is decided by how keyword matching and vector matching are combined into one ranked list. Solr 10.0 does not add a way to do that. Keyword scores and vector scores still live on different scales, and simply adding them together still lets one side drown out the other.
That problem is solved on Opensolr today, on Solr 9.00 to 10.00, by the Opensolr hybrid query parser. It scores every candidate document on both sides, normalises the two scores so they can be compared, and blends them with a weight you control. The quantized vector types in Solr 10 point the other way: they trade a little vector precision for memory, which only pays off at a scale most websites never reach.
Speed and memory were never the bottleneck for website search on Solr 9.6. Ranking quality is what visitors notice, and ranking quality is where Solr 10.0 has nothing new to offer. Full detail in the Hybrid Search guide.
03 · WHAT A WEBSITE SEARCH ACTUALLY NEEDS
Most Drupal, WordPress and CMS sites ask their search for the same handful of things. Almost all of them have been part of Solr for well over a decade. Solr 10.0 does not add a single line to this table.
What the site needs
Part of Solr since
On Opensolr (Solr 9.00 to 10.00)
Full-text search with relevance ranking
The first releases
Yes
Facets and filters
Solr 1.x
Yes
Highlighted snippets
Solr 1.x
Yes
Spellcheck, did you mean
Solr 1.x
Yes
Autocomplete suggestions
Solr 3.x
Yes
Search by meaning (dense vectors)
Solr 9.0
Yes
Hybrid keyword and vector ranking
No built-in score fusion, including 10.0
Yes, Opensolr hybrid parser
AI hints and RAG answers
Not in Apache Solr
Yes
04 · SOLR 10 ON OPENSOLR
Solr 10.00 is available on Opensolr: pick it in New York (US-EAST) when you create an index. Vector search and the Opensolr hybrid ranking work the same way on every version from Solr 9.00 to Solr 10.00, so the choice is yours to make on what your application needs.
Your existing indexes stay as they are. An index keeps the Solr version it was created on. Moving to Solr 10 means a new index and a reindex from your source.
05 · WHAT BREAKS WHEN A CONFIGURATION MOVES TO SOLR 10
Solr 10 also removes things that working Solr 9 configurations still use. A configuration that boots today on 9.6 can refuse to load on 10.0 because of any of these.
Component
In Solr 10
What it means
<lib/> in solrconfig.xml
Removed
Per-core jar loading is gone. Every plugin jar has to be installed on the server itself
master/slave replication config
Removed
Only leader and follower terminology is accepted
wt=php, phps, python, ruby
Removed
Clients reading those formats have to switch to JSON
wt=xlsx
Removed
Export CSV and convert it outside Solr
CurrencyField, EnumField
Removed
Schemas must move to CurrencyFieldType and EnumFieldType
ExternalFileField, PreAnalyzedField
Removed
Fields using them have to be redesigned and reindexed
HDFS, analytics module, hadoop-auth
Removed
No replacement inside Solr
Java
Java 21 minimum
Custom plugins built for older Java need a rebuild and a retest
If your project needs Solr 10 on hardware reserved for you alone, we provision it on a dedicated server, with the same management, monitoring and support as the rest of the platform. See Enterprise Solr Cloud or tell us what you need.
Start on Solr 10.00
Create an index on Solr 9.00 to 10.00 and get vector search and hybrid ranking. Need Solr 10 on your own server? Talk to us.
