FWIW, I recommend the following and none of it depends on what Solr is doing with Lucene. Lucene versions are just one possible pain point. Changes to an UpdateProcessor could cause a new field to be written, or bad data to be written to a field, bugs happen, etc. There are lots of possible problems.
1. Have a recovery plan before you start. Things can go sideways for any number of reasons 2. Have a UAT system of equal size and layout, upgrate it first then load test and functionallity test heavily. 3. Test your recovery plan on UAT - just like unverified backups are useless so are unverified recovery plans. 4. Space allowing, make a backup (and verify it) 5. Only touch production after validating forwards and backwards on UAT. Not everyone listens, some can't afford the time or cost, but every skipped element is an additional risk taken. Did you start a thread regarding the crashing? -Gus On Wed, Feb 25, 2026 at 12:33 PM Arrieta, Alejandro < [email protected]> wrote: > Hello, > > I think I saw something similar on Solr 8.x. > If you decide on B) option, on top of the backup, users may need to save > the new/updated indexed data after the upgrade, as it will be lost with the > rollback. > > Maybe the tool proposed in this thread "Automatic upgrade of Solr indexes > over multiple versions" can add in the future the downgrade option and be > option C). > > Kind Regards, > Alejandro Arrieta > > On Wed, Feb 25, 2026 at 11:53 AM Jan Høydahl <[email protected]> > wrote: > > > Hi, > > > > At a customer we upgraded from Solr 9.8.1 to 9.10.1 recently to stay on > > top of CVEs etc. > > Today we had the need to roll back Solr due to some crash situation. > > But after downgrading to 9.8.1 the nodes don't get up with errors about > > missing codec "Lucene912". > > > > Par of Solr/Lucene's back-compat promise is that we won't do breaking > > chagnes in minor versions. > > But this kind of codec changes between minor versions breaks the ability > > to downgrade - you need a full reindex. > > I find a related discussion in Lucene about this > > https://github.com/apache/lucene/issues/14623#issuecomment-2866257196 > > > > We currently do not clearly document this limiation in RefGuide. > > > > In my eyes we (Solr) have two choices: > > > > A) Stay at the same lucene minor version throughout a Solr major version > > and keep back-compat also for downgrades > > B) Start doumenting in release notes when a new lucene version will > > prevent future downgrade, and advise users to back up their index before > > upgrading if they want the ability to roll back. > > > > Thoughts? > > > > Jan > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
