> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/server-update-and-maintenance/update/pre-update-steps.md).

# Pre-update steps

The pre-update steps you must perform before you start updating SonarQube Server. This page is for SonarQube Server 2026.5.

## Before you start <a href="#before-you-start" id="before-you-start"></a>

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 notes](/sonarqube-server/server-update-and-maintenance/release-notes.md#upgrade-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 <a href="#backup-database" id="backup-database"></a>

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 <a href="#recommended-database-maintenance-steps" id="recommended-database-maintenance-steps"></a>

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.

{% hint style="warning" %}
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.
{% endhint %}

### PostgreSQL <a href="#postgresql" id="postgresql"></a>

```css-79elbk
VACUUM FULL
REINDEX DATABASE <db>
ANALYZE
```

### Oracle <a href="#oracle" id="oracle"></a>

```css-79elbk
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 <a href="#microsoft-sql-server" id="microsoft-sql-server"></a>

```css-79elbk
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD';
EXEC sp_MSforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN';
```

## SonarScanner compatibility <a href="#scanner-compatibility" id="scanner-compatibility"></a>

Check the SonarScanner versions for the SonarQube Server version that you are updating to. See SonarScanners [General requirements](/sonarqube-server/analyzing-source-code/scanners/scanner-environment/general-requirements.md) and individual scanner pages for more details.

<table><thead><tr><th width="213.6746826171875">SonarScanner</th><th>2026.5 LTA</th><th>2026.4</th><th>2026.3</th><th>2026.2</th><th>2026.1 LTA</th></tr></thead><tbody><tr><td>SonarScanner CLI</td><td>8.1</td><td>8.1</td><td>8.0.1</td><td>8.0.1</td><td>8.0.1</td></tr><tr><td>Azure DevOps extension</td><td>8.2.4</td><td>8.2.3</td><td>8.2.0</td><td>8.1.0</td><td>8.0.1</td></tr><tr><td>Jenkins extension</td><td>2.18</td><td>2.18</td><td>2.18</td><td>2.18</td><td>2.18</td></tr><tr><td>SonarScanner for Maven</td><td>5.8.0.7211</td><td>5.7.0.6970</td><td>5.6.0.6792</td><td>5.5.0.6356</td><td>5.5.0.6356</td></tr><tr><td>SonarScanner for Gradle</td><td>7.4.0.8496</td><td>7.3.1.8318</td><td>7.3.0.8198</td><td>7.2.3.7755</td><td>7.2.2.6593</td></tr><tr><td>SonarScanner for .NET</td><td>11.2.0.135473</td><td>11.2.0.135473</td><td>11.2.0.135473</td><td>11.2.0.135473</td><td>11.0.0.126294</td></tr><tr><td>SonarScanner for NPM</td><td>5.0.0</td><td>5.0.0</td><td>4.3.6</td><td>4.3.5</td><td>4.3.0</td></tr><tr><td>SonarScanner for Python</td><td>1.8.0.5390</td><td>1.7.0.5143</td><td>1.4.0.4676</td><td>1.3.0.4086</td><td>1.3.0.4086</td></tr></tbody></table>

## Testing the update <a href="#testing-upgrade" id="testing-upgrade"></a>

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 update process 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.

## Agentic features <a href="#agentic-features" id="agentic-features"></a>

The agentic features run as their own containers, with their own release cycle, so updating SonarQube Server does not update them. Update the Agent Orchestrator and the agent runtimes separately, see [Release cycle model](/sonarqube-server/server-update-and-maintenance/update/release-cycle-model.md).

Update Sonar Vortex alongside SonarQube Server rather than on its own. It runs analyzers of its own, and if they drift from the analyzer versions your deployment uses, the same file can produce different results depending on which path analyzed it. See [Installation overview](/sonarqube-server/server-installation/ai-agents/installation-overview.md#analyzer-versions).

If Sonar Vortex is unavailable while you update, the Remediation Agent keeps working in a degraded state: it still proposes fixes and opens pull requests, but those fixes are not verified by analysis first. SonarQube Server warns administrators when that happens.

There is no ZIP equivalent for these components. If you run SonarQube Server from the ZIP file you can still use the agentic features, but you deploy and update their containers separately. See [Deploying AI agents](/sonarqube-server/server-installation/ai-agents.md).

## Related pages <a href="#related-pages" id="related-pages"></a>

* [Release cycle model](/sonarqube-server/server-update-and-maintenance/update/release-cycle-model.md)
* [Determining the update path](/sonarqube-server/server-update-and-maintenance/update/determine-path.md)
* [Performing the update](/sonarqube-server/server-update-and-maintenance/update/update.md)
* [Post-update steps](/sonarqube-server/server-update-and-maintenance/update/post-update-steps.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.sonarsource.com/sonarqube-server/server-update-and-maintenance/update/pre-update-steps.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.