Release Cycle, LTA Strategy, Upgrade Paths, and Migration Planning: Core Concepts and Mental Model

1. The practical problem: an update is not “replace the container tag”

Chapter 28 established that SonarQube disaster recovery starts from the durable database and a tested restore. That recovery discipline becomes the safety boundary for every update. A new SonarQube version can change the database schema, embedded Elasticsearch representation, bundled analyzers, Java requirements, plugin compatibility, Web API behavior and integration expectations. Replacing one binary or image therefore changes several coupled systems even if your project source code does not move.

A production update is reproducible only when you can answer, before the maintenance window: what version am I on, which release stream am I following, what exact path is supported, what database backup proves my rollback point, which plugins/scanners/APIs/integrations are compatible, and what post-update evidence will make me accept the migration?

2. Two release models you must not mix

SonarQube Community Build uses calendar versioning such as 26.9.0.129388. It has no LTA concept. Current path rules allow direct updates between versions in the same year; moving across years normally requires the December bridge release, with the documented January 2026 exception available because of known December 2025 issues.

Commercial SonarQube Server uses YYYY.ReleaseNumber.Patch, publishes a release about every two months, and designates one yearly Long-Term Active (LTA) release. The current release stream is 2026 Release 4.1; the current LTA is 2026.1.5. Server path rules require every LTA that lies in an update path.

3. Mental model: compatibility inventory → rehearsal → migration → proof

The update starts with the current release and all attached dependencies. The supported path and update notes define the sequence. A protected database backup creates the rollback point. A staging rehearsal proves that the target can migrate a copy of the database. Only then should the production server change. After startup, representative scanner, API, CI and IDE checks prove that the new server is usable rather than merely reachable.

flowchart TD
  A[Current release/LTA + compatibility inventory] --> B[Supported update path]
  B --> C[Read every intervening update note]
  C --> D[Protected DB backup + rollback manifest]
  D --> E[Staging rehearsal on cloned DB]
  E --> F[Target server migration]
  F --> G[Plugin + scanner + API + CI/IDE validation]
  G --> H[Fresh analysis + report-task.txt + ceTaskId]
  H --> I{Acceptance criteria met?}
  I -->|Yes| J[Accept target and retain evidence]
  I -->|No| K[Stop target + restore backup + previous server]

4. State map before change

5. Read-only inspection first

# Server state
curl -fsS "$SONAR_HOST_URL/api/system/status" | tee evidence/pre/system-status.json

# Scanner/runtime
sonar-scanner --version | tee evidence/pre/scanner-version.txt
java -version 2>&1 | tee evidence/pre/java-version.txt

# Exact repository revision used for representative validation
git rev-parse HEAD | tee evidence/pre/revision.txt

# Installed plugin inventory (requires suitable API permission on your instance)
curl -fsS -H "Authorization: Bearer $SONAR_API_TOKEN" \
  "$SONAR_HOST_URL/api/plugins/installed" > evidence/pre/plugins.json

# PostgreSQL identity and size/headroom evidence (run with authorized DB account)
psql "$SQ_DB_URL" -Atc 'show server_version;' | tee evidence/pre/postgres-version.txt
psql "$SQ_DB_URL" -Atc "select pg_size_pretty(pg_database_size(current_database()));" \
  | tee evidence/pre/database-size.txt

Also inventory the deployment source: Compose/Helm values, systemd unit, Kubernetes manifests, environment-variable names, secret references, proxy/TLS settings, and any manually installed JARs. Do not dump secret values into the evidence packet.

6. Determine the path before choosing the maintenance window

For this chapter's executable Community Build lab, 26.7.0.124771 → 26.9.0.129388 is a same-year direct update. Direct does not mean “skip documentation”: read the 26.8 and 26.9 release/update notes and validate all target requirements. A cross-year Community Build update uses a different path rule. Commercial Server uses the LTA-aware calculator and requires intermediate LTAs when they lie between source and target.

7. Backup ID and rollback decision point

A backup is part of the update transaction. Record its timestamp, database identity, vendor-tool command, size and checksum, and prove a restore rehearsal before production. Define the point of no simple return: once the new server migrates the database, the old server must not be pointed at that migrated schema.

backup_id: sq29-20260908T120000Z
source_version: 26.7.0.124771
source_database: sq29_source
backup_sha256: <recorded checksum>
target_version: 26.9.0.129388
rollback_trigger: validation checklist fails before acceptance
rollback_action: stop target -> restore backup -> switch old server -> start old server
never_do: start old server against migrated target database

Knowledge check

Official references and version notes

• SonarQube downloads — current Community Build, commercial current release, and current LTA identities.
• Community Build — Determining the update path — direct same-year updates; December/January bridge rules across calendar years; no Community Build LTA concept.
• SonarQube Server — Release cycle model — two-month releases, yearly LTA, active-version support model, and YYYY.Release.Patch versioning.
• SonarQube Server — Determining the update path — intermediate LTA rules and update-path calculator.
• Community Build — Pre-update steps — read every intervening release note, back up the database, test first, and leave database disk headroom for migrations.
• Community Build — Performing the update — fresh installation/image, compatible plugins, configuration review, startup/migration and validation flow.
• Community Build — Post-update steps — scanner verification, database cleanup, service-path updates and API-deprecation review.
• Community Build — Other migration-related tasks — rollback requires restoring the pre-update database backup before switching back to the previous server.
• Community Build — Server host requirements — ZIP installations currently require JDK 21 or 25.
• Community Build — Database requirements — PostgreSQL 14–18 is supported in current Community Build.
• Plugin version matrix — verify every third-party plugin against the target before update.
• Deprecation policy — public APIs/features are deprecated before removal; migration planning must inventory those dependencies.
• SonarScanner CLI 8.1.0.6389 — scanner baseline used for post-update validation.
• Official SonarQube Docker tags — exact source/target image identities used by the rehearsal.