Back to all use cases

ConsultingSoftware / Digital Platforms

A Solr upgrade path written down and rehearsed before production is touched

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.

Overview

A typical engagement starts with a product search or document search service on Solr 8, which the Apache project lists as end of life. The team wants to reach a supported line but has not worked out what the path involves, or whether Elasticsearch or OpenSearch would be easier.

Challenge

Solr 8 indexes cannot be opened by Solr 10, so the move is a reindex, not an in-place upgrade. Solr 10 needs Java 21 and removes features that older configurations may still use, and a rolling upgrade has prerequisites on both the cluster and the SolrJ clients. Without an inventory, the effort and the risk are guesses.

Environment

A SolrCloud cluster on Solr 8 with a ZooKeeper ensemble, several collections, SolrJ and HTTP clients and a custom analysis chain, running on virtual machines in the customer's own data center.

Approach

AceMQ engineers inventory the collections, configuration, analysis chains and clients, then compare them with the Apache project's Solr 9 and Solr 10 upgrade notes. The path is written as ordered steps and rehearsed on a copy of the data, with a rollback point at each one. If the inventory shows that a move to Elasticsearch or OpenSearch would be cheaper, the plan says so.

Solution

  1. Inventory of collections, solrconfig.xml, schema, analysis chains and client libraries in use
  2. Check of each against the features removed in Solr 10, such as HDFS storage and PKI authentication v1
  3. Upgrade path with every intermediate version named, including the Solr 8.7 and SolrJ 8.10 prerequisites for a rolling upgrade to Solr 9
  4. Reindex plan using a new collection behind an alias, so traffic switches only after validation
  5. Java 21 runtime and SolrJ client change list
  6. Written stay-or-move comparison that costs the upgrade against a migration to Elasticsearch or OpenSearch

Outcome

The engagement delivers a written upgrade plan the customer's own engineers can run: ordered steps, the reindex strategy, the configuration changes, the test queries used to validate each step and a rollback point at each stage. It also delivers a costed stay-or-move recommendation.

Technologies

Apache SolrSolrCloudZooKeeperJava
  • Assessment

    Elasticsearch to OpenSearch Migration Assessment

    Digital Media PlatformSoftware

    Assessment of the technical and licensing implications of moving a large Elasticsearch estate to OpenSearch, including client and plugin compatibility.

    OpenSearchElasticsearchAmazon S3Terraform
    Read case study: Elasticsearch to OpenSearch Migration Assessment
  • Support

    SolrCloud Replica Recovery and Leader Election Support

    Content PublisherCross-Industry

    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.

    Apache SolrSolrCloudZooKeeperKubernetes
    Read case study: SolrCloud Replica Recovery and Leader Election Support
  • Consulting

    Apache Pulsar Multi-Tenancy Design

    Managed Services ProviderSoftware

    Designing tenant, namespace, and policy structure so independent teams can share a Pulsar cluster without interfering with each other.

    Apache PulsarApache BookKeeperKubernetesZooKeeper
    Read case study: Apache Pulsar Multi-Tenancy Design

Related Reading

Need Apache Solr Architecture Guidance?

AceMQ's senior Apache Solr engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.