Major LTS jumps can require database migrations that must complete in sequence. If you skip supported intermediate versions, the schema and application state may not be transformed correctly, which can break the upgrade or leave the instance unstable. Following the documented multi-hop path reduces migration risk and ensures each step finishes cleanly before the next version is introduced.
Why SonarQube upgrade paths are sequenced
SonarQube is not designed to “jump” cleanly across every long-term support release. The upgrade path exists because each supported step may apply a specific database migration, update internal metadata, and adjust stored state in a way the next version expects. Skipping a required hop can leave the platform in a partially migrated condition, which is why the documented path matters.
That sequencing is what makes a major upgrade predictable rather than experimental. The vendor only supports certain intermediate versions because those releases are the ones that can safely transform the schema and application state in the right order. If you try to compress the path, you can end up with a version of the application that no longer matches the database it is reading.
In practice, the “intermediate upgrade” is less about bureaucracy and more about compatibility boundaries. A release may be able to read the data produced by the previous supported version, but not the data format from a much older one. The migration chain ensures each step finishes cleanly before the next executable and set of rules are introduced.
What can fail if you skip the documented hop
The main failure mode is a schema or state mismatch. Some migrations are incremental by design, so they assume earlier transformations have already created columns, tables, indexes, or application records in the expected shape. When that assumption is false, the upgrade can fail mid-process or appear to succeed but behave inconsistently afterward.
That is why unsupported shortcuts are risky even when the target version itself looks compatible. The problem is often not the final release alone, but the path needed to get there. A direct leap can skip data transformation logic, leaving orphaned records, missing fields, or stale configuration assumptions that the new version depends on.
Operationally, this is also a recovery issue. Once a migration begins, you want a clean checkpoint at each supported step so you can validate the instance, take backups if needed, and prove that the platform is still healthy before proceeding. The intermediate version acts as a controlled staging point for that verification.
How to plan a safe multi-hop upgrade
The safest approach is to treat the upgrade as a sequence of discrete transitions, not one large event. Verify the exact supported source version, the required intermediate LTS version, and the destination version from the vendor documentation before you schedule downtime. Then confirm database backup, rollback expectations, and any plugin or extension compatibility constraints for each hop.
For maintainability, use the same discipline you would apply to any stateful platform upgrade: validate after each step, not only at the end. If the intermediate release includes database migration work, let it complete fully and confirm the instance starts normally before moving on. That reduces the chance of compounding failures across versions.
If you manage multiple environments, rehearse the path in a lower environment that mirrors production closely enough to expose migration errors, plugin conflicts, or performance regressions. The goal is not just to reach the latest version, but to prove that the path to it is repeatable and that the database state remains coherent at every stage.
Risk and Threat Considerations
Skipping required upgrade hops creates a reliability risk first, but it can become an availability and integrity problem quickly. A failed or incomplete migration may leave the SonarQube instance unusable, or worse, running with data that no longer matches the application logic expected by the upgraded code.
Failure mechanism: The upgrade path depends on ordered database transformations and application-state changes. If those transformations are not applied in sequence, the instance can encounter schema mismatches, partial migrations, or incompatible metadata that prevent normal operation.
Impact: The result can be broken upgrades, prolonged downtime, failed analysis processing, or an unstable platform that appears live but is not trustworthy for development or quality workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Sequenced upgrades are controlled configuration changes with validation steps. |
| CP-9 — System Backup | Backups are essential before stateful migrations that can fail mid-upgrade. | |
| Recommendation — Enforce change control and validation for each supported upgrade hop. Take verified backups before each migration step and test restore readiness. | ||
| ISO/IEC 27001:2022 | A.8.32 — Change management | Upgrade sequencing is a controlled production change requiring approval and verification. |
| Recommendation — Apply formal change management to document and approve each upgrade stage. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Supported upgrade paths depend on controlled software states and validated configurations. |
| Recommendation — Use a controlled configuration baseline and validate the system after each upgrade. | ||
Practitioner Guidance
What to verify: Confirm the supported starting version, every required intermediate LTS step, and the exact migration notes for each hop before you begin. Treat plugin compatibility and backup integrity as part of the upgrade decision, not as afterthoughts.
Implementation sequence: Upgrade one supported step at a time, wait for the migration to complete, validate that the service starts cleanly, and only then proceed to the next version. If a hop fails validation, stop and resolve it before advancing.
Practitioner takeaway: The safest SonarQube upgrade is the one that preserves state continuity, because each supported hop exists to prove the database and application still agree before the next version changes the rules again.
Related resources from NHI Mgmt Group
- How should teams secure non-human identities across cloud and SaaS?
- How should organisations govern non-human identities across their environment?
- How should security teams reduce standing access across users and non-human identities?
- How do organisations reduce privilege creep across human and non-human identities?
