SonarQube upgrade failure: 25.12 → 26.3 blocked with “source version too old” despite correct DB sta

SonarQube Server / Community Build Writing rules
1

SonarQube upgrade 25.12 → 26.3 blocked: “source version too old” despite valid DB state

Hi,

I’m trying to upgrade SonarQube from 25.12 to 26.3 (Kubernetes + PostgreSQL 16). The 25.12 instance runs correctly on the same database, but the 26.3 startup fails during Web Server initialization.

:cross_mark: Error

DatabaseServerCompatibility: The version of SonarQube you are trying to upgrade from is too old.
Please upgrade to the 25.12 version first.

This happens even though 25.12 has already been successfully run against this DB.

:puzzle_piece: Environment

  • SonarQube: 25.12.0 → 26.3.0
  • DB: PostgreSQL 16.11
  • Kubernetes StatefulSet (Helm)
  • Embedded Elasticsearch 8.19.8

:bar_chart: DB state (after successful 25.12 run)

SELECT kee, text_value FROM internal_properties WHERE kee = 'installation.version';
→ 9.3.0.51899

I tried to modify this value by 25.12.x and i restarted the server and same error

SELECT count(*) FROM internal_properties;
→ 14

SELECT min(version), max(version), count(*) FROM schema_migrations;
→ 1 | 6802 | 407

No upgrade/migration flags found:

SELECT * FROM internal_properties WHERE kee LIKE '%upgrade%' OR kee LIKE '%migrate%';
→ empty

:warning: Observations

  • 25.12 runs fine on this DB

  • schema_migrations contains full 25.x migration set (up to 2025060xx)

  • no upgrade locks or migration flags exist

  • installation.version is still:

    9.3.0.51899

  • 26.3 fails immediately with “too old version” error

:red_question_mark: Question

What is the actual source of truth for DB version detection in 26.3 upgrades?

Because:

  • schema_migrations looks valid
  • DB works with 25.12
  • but 26.3 refuses upgrade claiming version is too old

Is there another internal version marker or required intermediate upgrade step between 25.12 → 26.3?

2

Hello @MorgannLBT and welcome to the Community!

There is a known bug (even mentioned in our docs!) which affects some users in this precise way you’re describing. The solution typically is to upgrade to 26.1 first, and then to 26.3 (though you may consider v26.6 as it is the current version). Normally this wouldn’t be required, it’s an exception because of this bug. Can you give it a try?