Release Cycle, LTA Strategy, Upgrade Paths, and Migration Planning: Configuration, Design Patterns, and Trade-Offs

1. Design principle: reduce simultaneous unknowns

Updates fail most expensively when several layers change at once. If the SonarQube version, database engine, Java major, OS image, plugins, scanners and CI integration all change in one maintenance window, a failure has too many plausible causes. A strong migration plan separates required dependencies from optional modernization and records a validation gate after each meaningful step.

2. LTA versus latest release

For commercial SonarQube Server, the current release receives new features/enhancements/patches, while the current LTA receives longer-lived vulnerability/blocker fixes and support. An organization may choose LTA to reduce feature-change frequency or current releases to adopt features sooner. Neither choice removes the need to apply supported patches.

For Community Build, do not write an “LTA strategy.” There is no Community Build LTA. Use the calendar-version update rules and decide how quickly your organization follows current monthly releases.

3. Replacement instance versus in-place host

Even with a replacement container, the database migration is still stateful. Blue/green server containers do not make a shared migrated database simultaneously compatible with old and new binaries.

4. Scanner upgrades before or after the server?

Do not automatically upgrade every scanner in the same commit as the server. First inventory scanner versions and JRE auto-provisioning. Current SonarScanner CLI baseline is 8.1.0.6389. When auto-provisioning is enabled on supported scanners, runtime management is simpler; when it is disabled, current scanner guidance requires modern Java, with Java 17 support already ended/deprecated in 2026.

A practical staged pattern is: prove representative existing scanners against the target, then upgrade obsolete scanner versions in a separate controlled change where required. This isolates “server migration problem” from “scanner/toolchain migration problem.”

5. Plugin removal/update strategy

Every third-party plugin is executable server-side supply-chain state. Before the server update, classify each plugin as built-in replacement available, target-compatible, update required, or remove. Never copy the old extensions/plugins directory wholesale into the target. Use the current version matrix and provenance checks from Chapter 26.

plugin_key | source_version | target_compatible_version | action | rollback_artifact
-----------|----------------|---------------------------|--------|------------------
example    | 1.x            | none                      | remove | source JAR checksum
example2   | 2.x            | 3.x                       | update | both pinned JARs

6. Staged versus big-bang rollout

A staged update separates at least four acceptance planes:

1. Infrastructure: target starts, DB migration completes, health/logs acceptable.
2. Analysis: representative project uploads and target ceTaskId succeeds.
3. Policy: issues/metrics/gate/new-code results are understood, especially if bundled analyzers changed.
4. Automation: Web API, webhook, CI, provider decoration and IDE Connected Mode dependencies still work.

Only after these planes pass should the migration be accepted. Data Center rollouts add cluster coordination and belong to Chapter 30.

7. Web API V2 and deprecation debt

Chapter 23 established that Web API V2 is an endpoint-by-endpoint transition. An update plan must inventory actual endpoints and inspect deprecation evidence, not globally rewrite /api/... to /api/v2/.... Current post-update guidance explicitly tells operators to review deprecated Web API endpoint/parameter usage.

Treat an API deprecation as migration backlog with an owner and target release. Do not wait for a future release to remove the endpoint during the maintenance window.

8. Worked decision table

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.