Solr Migration Option 1 - Opensolr Converts Your Configuration

The route most teams take: Opensolr converts the configuration and provisions the new index, you reindex into it.

For most customers this is the right call. You write through the contact form with the index name and the target Solr version. You get the price and a payment link by email. Within under 4 business hours of payment we deliver:

1. A new Opensolr index provisioned on the Solr version you choose (any region you choose). Different name from the old one so the two can coexist.
2. Your schema.xml converted: every TrieField → PointField with docValues as appropriate, every removed-in-modern-Solr element rewritten or replaced (full table in the schema.xml table), schema version bumped, _version_ field added if missing.
3. Your solrconfig.xml converted: luceneMatchVersion bumped, master/slave → leader/follower terminology, removed handlers stripped, cache classes updated to Caffeine (full table in the solrconfig.xml table).
4. Stopwords / synonyms / protected-words files carried forward unchanged.
5. Connection details delivered to you: hostname, port, path, HTTP basic auth username and password.
6. The old index stays untouched and continues to serve production traffic until you flip the application over.

What happens next is on you: you reindex into the new index from your source-of-truth (how to reindex), validate it (validation and cutover), then point your application at it. Both indexes coexist for as long as you need — up to the retirement date.

The 4-business-hours target covers any standard config — including custom analyzer chains, language-specific tokenizers, custom request handlers, and edismax tuning. Genuinely exotic cases (custom Java plugins / JARs, non-standard distributed-search topologies) we quote separately, but those are rare.

Solr migration