Apache Solr Consulting & Migration
Last reviewed by Tyler Eastridge
AceMQ gives enterprise search teams Apache Solr consultants for upgrades to Solr 10, SolrCloud and ZooKeeper reviews, query and relevance tuning, and a written answer to whether to stay on Solr or move to Elasticsearch or OpenSearch. AceMQ engineers lead each engagement and partner Solr specialists do the Solr-specific work, under one AceMQ contract. It starts with a quote within 1 hour and a written plan before anything changes. AceMQ does not ship its own Solr builds.
A senior engineer, not an SDR. No sales sequence attached.
Without a rewrite of every query just because the Solr version is oldFor production incident cover, see AceMQ Apache Solr 24/7 support.
Customers
Partners
The Problem
Eight Apache Solr problems that teams bring to AceMQ, from a Solr 8 cluster the project no longer maintains to a schema change nobody reindexed and a ZooKeeper ensemble nobody has tested. If one describes your week, that is where the review starts.
Production runs Solr 8, which the Apache project lists as end of life, and nobody has written down how to reach Solr 10
An index built by Solr 8 cannot be opened by Solr 10, and the reindex was never scheduled
A schema change shipped without a reindex, so old and new documents are analyzed differently
Facets and sorts on a high-cardinality field push the heap into long garbage-collection pauses
Deep paging with a large start value gets slower with every page that crawlers and exports request
Every replica is the default type, so read traffic competes with indexing on the same nodes
The ZooKeeper ensemble was sized once and nobody knows what happens when it loses a member
The team is asking whether Elasticsearch or OpenSearch would be easier, and nobody has costed the answer
A good fit if you run Apache Solr in production for site search, catalog or document search, and need an upgrade path to Solr 10, a tuned SolrCloud cluster or an honest answer on whether to move.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy Apache Solr.
How it breaks, and the fix
Each SolrCloud shard has one leader, chosen automatically from its replicas. When the leader's node is lost, ZooKeeper coordinates an election among the replicas that are allowed to lead. A PULL replica cannot lead, so the replica types you chose long before decide whether the election has a winner.
Shard leader lost, election under way
One shard with three replicas, coordinated by ZooKeeper and reached through any node
solr-1 is the shard leader and indexes each update, solr-2 keeps the transaction log and copies the index, and solr-3 copies the index and serves queries. ZooKeeper holds the cluster state.
solr-1 is lost. Updates to the shard wait for an election. solr-2 is eligible and solr-3 is not, because a PULL replica is never a leader. If solr-2 were also gone, the shard would have no leader to elect.
solr-2 is elected leader and indexing resumes. solr-1 comes back as a replica and catches up from the new leader. Queries kept being served by the replicas that stayed up.
The election is the quick part. What decides the outcome is set earlier: how many replicas per shard can become leader, whether the ZooKeeper ensemble keeps a majority, how the commit and update-log settings affect recovery time, and whether SolrJ clients retry through the gap. Replica type is the usual surprise: a layout built for read scaling with PULL replicas can leave one eligible replica between a node failure and a read-only shard.
Our Services
AceMQ runs five Solr service lines: upgrade and version planning, relevance and query performance, SolrCloud and ZooKeeper architecture, migration away from Solr, and a fixed-scope health check. Any of them can roll into 24/7 support with a 15-minute emergency SLA.
A route from Solr 8 or 9 to Solr 10 that states every intermediate version, every reindex and every removed feature, rehearsed before production.
Slow queries, heavy facets and unstable ranking traced to their cause with debug output and metrics, then fixed in analysis, caching or query design.
Shard and replica layout, ZooKeeper sizing and failure behavior designed for the load you have, not the load of the first proof of concept.
A move to Elasticsearch or OpenSearch planned from an inventory of what your application actually uses, with a parallel run before cutover. We also say when the right answer is to stay.
The fixed-scope entry engagement: a written report on the state of the cluster that your own team can act on, with or without AceMQ afterwards.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ Apache Solr support gives you an AceMQ engineer and a 15-minute first response when a cluster is down or failing, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Fixes still come from Apache Solr releases: AceMQ does not ship its own builds.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
How It Works
An AceMQ Solr engagement runs in four stages: a scoping call with a quote within 1 hour, a written assessment, a plan rehearsed on a copy of your data, then delivery with your engineers and a handover. Each stage ends in writing.
Quote within 1 hour
A senior AceMQ engineer asks what you run: Solr version, SolrCloud or user-managed, collection and shard counts, query and index volume, the client libraries in use and who owns the search relevance. A quote request is answered within 1 hour.
Scoped per estate
A written review of configuration against what Solr 10 removed, index age against what the target version can open, analysis chains, cache and commit settings, replica layout, ZooKeeper health and the slowest recurring queries. Findings are ranked by production risk before anything changes.
Scoped per estate
An upgrade path that names every intermediate version and every reindex, or a migration plan with a query inventory and a parallel-run design. The plan is rehearsed on a copy of your data, not on production.
Scoped per estate
Changes made with your engineers, collection by collection, with a rollback point at each step. You keep the runbooks, the test queries and the written results.
A senior engineer, not an SDR. No sales sequence attached.
Typical engagements
Typical Apache Solr engagements from AceMQ: what the environment looks like, what AceMQ assesses or changes, and what the engagement delivers. Each card links to the full write-up.
Software Platform Team
A typical engagement for a team running Solr 8 in production: a written upgrade path to Solr 10 that names every intermediate version, every reindex and every removed feature, rehearsed on a copy first.
Java
Content Publisher
A typical emergency engagement: a SolrCloud shard that stopped accepting updates after a node loss, diagnosed from cluster state, replica types and ZooKeeper, with a written root-cause analysis.
Kubernetes
Global Payments Processor
Emergency remediation of an Elasticsearch cluster that would not return to green after a data node failure, with replicas blocked by disk watermarks.
Elasticsearch
Kibana
LinuxKubernetesSolutions
AceMQ covers Apache Solr end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed Apache Solr on your infrastructure and fully managed Apache Solr on AceMQ infrastructure, plus end-of-life versions.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running Apache Solr for you.
Compare the four Apache Solr support tiersSide by side
All three are built on Apache Lucene, so the analysis and relevance ideas carry over. The cost is in the application: staying means an upgrade, and moving means rewriting every query, facet and client call. Each row below answers one question about the choice.
| Question | Stay on Solr and upgrade | Move to Elasticsearch | Move to OpenSearch |
|---|---|---|---|
| What usually triggers it? | Solr 8 or older in production. The Apache project lists every release below 9.11 as end of life and warns that community help for them may be hard to get. | The team already runs Elastic for logs or security, wants Kibana and Elastic's solutions, or wants Elastic Cloud. | The team runs on AWS and wants Amazon OpenSearch Service, Apache 2.0 terms or a fully open security stack. |
| What changes in the application? | Little. Query parsers and SolrJ stay. Solr 10 needs Java 21, SolrJ 10 needs Java 17, and the cluster connection string moves away from raw ZooKeeper hosts. | Every request is rewritten: Solr's query parameters and JSON Facet API become the Query DSL and aggregations, and SolrJ is replaced by an Elasticsearch client. | The same rewrite into the Query DSL and aggregations, with an OpenSearch client library. |
| What happens to the schema and analysis? | The schema and solrconfig.xml are reviewed against what Solr 10 removed. A change to index-time analysis needs a reindex. | Fields become index mappings and each analysis chain is rebuilt. The Lucene core is shared, so much of the tuning carries over in principle, and what does not is found by testing. | The same: mappings rebuilt, analysis chains rebuilt and tested against real queries. |
| How is the data moved? | A rolling upgrade from 8 to 9 starts at 8.7 or newer. An index more than one major version old must be reindexed, so 8 to 10 means a new collection behind an alias. | Reindex from the source of truth, or run both engines side by side with dual writes. Nothing is copied across as files. | The same: reindex from the source of truth, or dual-write during a parallel run. |
| How is the cluster run? | SolrCloud with a ZooKeeper ensemble, or user-managed mode, which has no built-in failover. Solr 10 can run without the Overseer, and that choice cannot be changed in a rolling upgrade. | Built-in cluster coordination with no separate ensemble. Shard sizing and allocation become the main operational problem. | Built-in cluster coordination, self-managed or on Amazon OpenSearch Service, where you cannot log in to the node. |
| When is it the wrong choice? | When nobody on the team wants to own Solr, or the roadmap needs features that live in the other engines. | When the only reason is that Solr is old. An upgrade to Solr 10 is smaller than a rewrite of every query. | When the reason is cost alone and the rewrite and the parallel run have not been costed. |
| What does AceMQ add? | A written upgrade path rehearsed on a copy, then 24/7 cover with a 15-minute emergency response. | A query and facet inventory, a gap list and a parallel-run plan, then support through the Elasticsearch page. | The same inventory and plan, then support through the OpenSearch page. |
For how Elasticsearch and OpenSearch differ from each other, read OpenSearch vs Elasticsearch compared. For the decision in more detail, read Solr vs Elasticsearch vs OpenSearch: which to run.
One partner, not five
Apache Solr rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
Guides from AceMQ engineers on choosing between Solr, Elasticsearch and OpenSearch, plus the AceMQ services around search: Elasticsearch, OpenSearch and the wider data stack.
FAQs
Five answers on Apache Solr from AceMQ: which versions are supported, whether to stay or move, how to upgrade from Solr 8, who does the work and what AceMQ does not ship.
Still have questions about Apache Solr? Email an Expert
Solr 10.1.0 is the current release and 10.x is the project's stable line. Solr 9.11 is the last release in the 9.x series and receives critical bugfix releases only. The Apache Solr downloads page lists every release older than 9.11, including all of Solr 8, as end of life, and warns that community help for them may be hard to get (read 31 October 2026). AceMQ keeps 8.x clusters running and plans the move to a supported line.
Stay when the application is built around Solr's query parsers and facets and the problem is an old version, because an upgrade to Solr 10 is smaller than rewriting every query. Move when you need something the other engines have, such as Kibana and Elastic's solutions, or Amazon OpenSearch Service. AceMQ inventories what your application uses, costs both paths and puts the recommendation in writing.
Solr 8 to 9 is a rolling upgrade only if the cluster is first on 8.7 or newer, with SolrJ clients on 8.10 or newer. An index more than one major version old must be reindexed, so reaching 10 from 8 means building a new collection behind an alias and switching over. Solr 10 also needs Java 21 and removes features such as HDFS storage and PKI authentication v1. AceMQ rehearses the path on a copy first.
AceMQ engineers lead the engagement and are your point of contact. Solr specialists from AceMQ's partner network do the Solr-specific work. Both are named to you before work starts, and the partner works under the AceMQ contract and SLA.
No. Apache Solr is community software, and fixes come from Apache releases. AceMQ supplies the engineers who upgrade, tune and troubleshoot it, and tells you plainly when a version is past the project's support. It does not ship patched Solr builds or resell a commercial Solr distribution.
Yes. AceMQ works on Apache Solr in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your Apache Solr environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Apache Solr is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer reviews your Solr estate, tells you whether to upgrade or move, and quotes it. Quote requests are answered within 1 hour.
Production incident right now?Email an Apache Solr Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
