Introduction

A code-quality migration can move analysis to a new SonarQube server while scanners still upload results to the old one. Developers can open the new platform in the browser, but CI pipelines continue publishing analysis to the retired server, one repository uses the new host while another still inherits the previous URL, or failures begin only after the old SonarQube token or certificate is removed because scanner properties, CI variables, and shared pipeline defaults often drift separately.

Treat this as an analysis-target problem instead of a generic SonarQube outage. Start by checking which sonar.host.url an affected job actually uses at runtime, because migrations often validate the new server manually while live scanners continue following older CI configuration.

Symptoms

  • SonarQube Scanner still uploads analysis to the old server after migration
  • The new SonarQube instance is healthy, but analysis results keep appearing on the retired platform
  • One repository or pipeline uses the new server while another still uses the previous host URL
  • Analysis failures begin only after the old server, token, or certificate is removed
  • The new platform is available, but migrated scanners never submit to it consistently
  • The issue started after moving SonarQube, CI templates, shared build logic, or secret management

Common Causes

  • sonar.host.url still points to the old SonarQube server in CI or project config
  • Shared pipeline templates or build scripts keep injecting the previous analysis endpoint
  • Repository-level sonar-project.properties, Maven, or Gradle settings override the intended new host
  • One CI variable set or secret scope was updated while another still exposes the earlier server URL
  • Automation, runner images, or bootstrap scripts restored older scanner defaults
  • Validation confirmed the new server accepted manual logins but did not verify which endpoint live analysis jobs actually posted to

Step-by-Step Fix

  1. Capture one affected analysis job and record the effective sonar.host.url, token source, scanner type, and pipeline template it actually uses, because the live scanner path determines where analysis really lands.
  2. Compare that active analysis path with the intended post-migration quality-platform design, because one stale host URL can keep many repositories tied to the retired SonarQube server.
  3. Review CI variables, sonar-project.properties, Maven or Gradle scanner settings, shared pipeline templates, and runner images for references to the old server, because SonarQube targeting depends on both repository config and CI-delivered defaults.
  4. Check each repository, branch template, and pipeline family separately if behavior differs, because migrations often update one analysis path while another still follows the previous host.
  5. Update the authoritative scanner host setting and config-delivery source so affected jobs submit to the intended SonarQube server, because standing up the new platform alone does not retarget existing scanners.
  6. Run a controlled analysis and confirm the intended server receives the project report, because a successful build does not prove the right SonarQube instance accepted the upload.
  7. Verify the old server no longer receives analysis from migrated repositories, because split quality-report paths can remain hidden while both servers stay reachable.
  8. Review token scope, certificates, proxy settings, and server-version compatibility if uploads still fail, because the destination can be correct while auth or transport policy still blocks the new path.
  9. Document which team owns scanner defaults, CI templates, and migration validation so future SonarQube cutovers verify the actual runtime upload target before retiring the previous server.