Pre-update steps

Perform the pre-update steps before proceeding with your SonarQube Server update.

Before you start

Consider the following before starting your update:

• SonarQube Server releases come with specific recommendations for updating from the previous versions. You should first read the Release update notes for each version between your current version and the target version.

• Database disk usage recommendations: During your update, tables may be duplicated to speed up the migration process. This could cause your database disk usage to temporarily increase to as much as double the normal usage. Because of this, we recommend that your database disk usage is below 50% before starting a migration.

Backup the database

First, we strongly recommend creating a backup of your database. A backup dump of the database creates a safety net should anything go wrong during the update process. It also allows for testing the update on a testing instance. See Testing the update section below for details.

Recommended database maintenance steps

For large instances, it can be helpful to perform database maintenance tasks like vacuuming, reindexing, and collecting statistics to ensure a smooth and efficient migration. These steps help eliminate table and index bloat, reclaim disk space, and optimize query performance, preventing unnecessary slowdowns during the update process.

Additionally, gathering fresh statistics ensures that the database query planner can make optimal execution choices. Neglecting these optimizations can lead to longer update times, increased disk usage, and potential indexing issues, affecting responsiveness after the migration.

The following commands will lock your database tables so they should be performed during the downtime window. The best effect will be achieved when they are run one after another.

PostgreSQL

VACUUM FULL
REINDEX DATABASE <db>
ANALYZE

Oracle

SELECT 'ALTER TABLE ' || OBJECT_NAME || ' MOVE';
  FROM DBA_OBJECTS WHERE OBJECT_TYPE = 'TABLE' AND OWNER = 'SONARQUBE';

BEGIN
  FOR i IN (SELECT INDEX_NAME FROM USER_INDEXES WHERE TABLE_OWNER = 'SONARQUBE') LOOP
    EXECUTE IMMEDIATE 'ALTER INDEX ' || i.INDEX_NAME || ' REBUILD';
  END LOOP;
END;

BEGIN
   DBMS_STATS.GATHER_SCHEMA_STATS('SONARQUBE');
END;

Microsoft SQL Server

EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD';
EXEC sp_MSforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN';

SonarScanner compatibility

Check the minimum required SonarScanner version for the SonarQube Server version that you are updating to. See SonarScanner general requirements or the individual scanner pages for more information and release details.

SonarScanner	2025.6	2025.5	2025.4	2025.1	9.9
SonarScanner for CLI	8.01	7.2	7.2	7.0.1	4.8
Azure DevOp Extension	8.0.0	7.4.1	7.3	7.1.1	5.11.1
Jenkins extension	2.18	2.18	2.18	2.17.3	2.15
SonarScanner for Maven	5.5.0.6356	5.2.0.4988	5.1.0.4751	5.0.0.4389	3.9.1.2184
SonarScanner for Gradle	7.2.0.6526	6.3.1.5724	6.2.0.5505	6.0.1.5171	3.5.0.2730
SonarScanner for .Net	11.0.0.126294	10.4.0.124828	10.3.0.120579	9.0.2	5.11
SonarScanner for NPM	4.3.0	4.3.0	4.3.0	4.2.6	3.7.0
SonarScanner for Python	1.3.0.4086	1.1.0.2035	1.1.0.2035	0.2.0.520	N/A

Testing the update

We recommend testing your update to:

• Make sure your infrastructure can run the update and the new version of SonarQube.

• Get an idea of how long the update will take.

• Gain a better understanding of the updateprocess and anticipate what you’ll need to do when performing the actual update.

To test your update:

1. Create a staging environment using a recent backup of your production database. Your staging environment should be as similar to your production instance as possible because the resources and time needed to update depend on what’s stored in your database.

2. Use this staging environment to test the update.

3. Observe how long it takes to back up and restore systems and complete the process.

Related pages

• Release cycle model

• Determining the update path

• Performing the update

• Performing the post-update steps