> 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/post-update-steps.md).

# Post-update steps

The tasks you must perform after you update SonarQube Server. This page is for SonarQube Server 2026.5.

## Post-update checklist <a href="#checklist" id="checklist"></a>

Here’s a list of steps to perform after the update:

* Verify the SonarScanner version, see [Verifying the installed SonarScanner version](#verify-sonarscanner-version) for more information.
* For an Oracle database: optionally clean up the database to reclaim disk space, see [Cleaning up the Oracle database](#clean-up-oracle-db) for more information.
* For a PostgreSQL database: clean up the database, see [Cleaning up the PostgreSQL database](#clean-up-postgresql) for more information.
* For a Microsoft SQL database with Windows authentication: verify the JDBC driver version, see [Verifying the Microsoft SQL JDBC driver version](#verify-jdbc-version) for more information.
* If using an external configuration to control SonarQube Server (through a script or running as a service): update the service to point to the new installation directory, see [Updating a service to point to the new installation directory](#update-external-service) for more information.
* If SonarQube Server is running as a service on Linux with SystemD, then you must configure SonarQube Server to run as a service by updating the `sonarqube.service` file.
* If you use the Web API, check at some point the usage of deprecated Web API endpoints and parameters: see [Monitoring API deprecation](/sonarqube-server/server-update-and-maintenance/maintenance/deprecations/monitoring-api-deprecation.md).
* (Recommended) Migrate existing security hotspots to vulnerabilities before updating to SonarQube Server 2027.1 (see below).

See the sections below for more details on each step.

{% hint style="info" %}
If some projects fail to reindex after the update, see **Reindexing a single project** in [Reindexing](/sonarqube-server/server-update-and-maintenance/maintenance/reindexing.md).
{% endhint %}

## Verifying the installed SonarScanner version <a href="#verify-sonarscanner-version" id="verify-sonarscanner-version"></a>

When updating SonarQube Server, you should also make sure you’re using the latest versions of the SonarScanners to take advantage of features and fixes on the scanner side. Please check the documentation pages of the scanners you use for the most recent version compatible with SonarQube Server and your build tools:

* SonarScanner for Maven: [SonarScanner for Maven](/sonarqube-server/analyzing-source-code/scanners/sonarscanner-for-maven.md)
* SonarScanner for Gradle: [SonarScanner for Gradle](/sonarqube-server/analyzing-source-code/scanners/sonarscanner-for-gradle.md)
* SonarScanner for .NET: [Installing the scanner](/sonarqube-server/analyzing-source-code/scanners/dotnet/installing.md)
* SonarScanner for NPM: [Installing the scanner](/sonarqube-server/analyzing-source-code/scanners/npm/installing.md)
* SonarScanner for Python: [SonarScanner for Python](/sonarqube-server/analyzing-source-code/scanners/sonarscanner-for-python.md)

## Cleaning up the Oracle database <a href="#clean-up-oracle-db" id="clean-up-oracle-db"></a>

On Oracle, the database columns to be dropped during an update are marked as UNUSED instead of being physically removed. This is intentional: Oracle performs the operation instantly and without locking the rows.

This cleanup is optional. Unused columns are invisible to all queries and have no impact on the functionality of SonarQube Server. Run the cleanup only if you want to reclaim disk space.

To list the tables that contain unused columns, run:

```sql
SELECT table_name FROM all_unused_col_tabs;
```

To reclaim the disk space, choose one of the following two options.

### Option 1: Drop the unused columns directly <a href="#drop-unused-columns" id="drop-unused-columns"></a>

```sql
ALTER TABLE foo DROP UNUSED COLUMNS;
```

{% hint style="warning" %}
This operation rewrites every row on disk and holds an exclusive lock for its entire duration. On large tables, such as `ISSUES` or `PROJECT_MEASURES`, it can take several hours and makes SonarQube Server unavailable. Plan a maintenance window accordingly.
{% endhint %}

### Option 2: Rebuild the table online <a href="#rebuild-table-online" id="rebuild-table-online"></a>

For large datasets, we recommend rebuilding the table online. This keeps the database accessible during the operation:

```sql
ALTER TABLE foo MOVE ONLINE;
```

With `MOVE ONLINE`, Oracle maintains all indexes automatically. They remain USABLE, and no rebuild is required.

{% hint style="info" %}
`MOVE ONLINE` is an Oracle Enterprise Edition feature and is not available on Express Edition (XE). Even with `ONLINE`, Oracle acquires a short lock (a few seconds) at the end of the operation to apply the final delta. The operation also requires significant temporary disk space, roughly a second copy of the table, and I/O while it runs.
{% endhint %}

### Choosing between the two options <a href="#which-option-to-choose" id="which-option-to-choose"></a>

Both options free the disk space taken by the unused columns. The difference is the trade-off between downtime, temporary disk space, and the Oracle edition you run:

|                     | Option 1: `DROP UNUSED COLUMNS`            | Option 2: `MOVE ONLINE`                |
| ------------------- | ------------------------------------------ | -------------------------------------- |
| Downtime            | Full exclusive lock for the whole duration | Almost none (brief lock at the end)    |
| Extra disk required | No (edits in place)                        | Yes (needs a second copy of the table) |
| Oracle edition      | Any edition                                | Enterprise Edition only (not XE)       |

## Cleaning up the PostgreSQL database <a href="#clean-up-postgresql" id="clean-up-postgresql"></a>

You can fix the table and index bloating by performing [vacuuming](https://www.postgresql.org/docs/18/routine-vacuuming.html#VACUUM-FOR-SPACE-RECOVERY) in order to reclaim unused disk space. In some specific cases, a [reindex](https://www.postgresql.org/docs/18/routine-reindex.html) is required afterward.

## Verifying the Microsoft SQL JDBC driver version <a href="#verify-jdbc-version" id="verify-jdbc-version"></a>

If you use Microsoft SQL Server with Windows Authentication, make sure that you’re using a supported version of the Microsoft SQL JDBC Driver package. The minimum supported version is the one mentioned on the [Installing database](/sonarqube-server/server-installation/installing-the-database.md) page.

## Updating a service to point to the new installation directory <a href="#update-external-service" id="update-external-service"></a>

If you use an external configuration, such as a script or Windows Service to control your server, you’ll need to update it to point to the new value of installation directory (\<newSonarQubeHome>).

For Linux it depends how you implemented the service.

For Windows, update your service by running the following commands:

```css-79elbk
sc delete SonarQube
<newSonarQubeHome>\bin\windows-x86-64\SonarService.bat install
```

## Migrating security hotspots to vulnerabilities <a href="#migrate-hotspots" id="migrate-hotspots"></a>

Security hotspots are being removed from SonarQube Server. Built-in rules no longer raise hotspots, and all existing hotspot findings must be migrated to vulnerabilities or code smells (in Standard Experience), which appear as security issues or maintainability issues (in MQR Mode). In SonarQube Server 2027.1, this migration will be forced automatically during the update. If your instance has a large number of hotspots, migrate them in advance to avoid a long forced migration at the 2027.1 update.

These endpoints require the Administer System permission.

### Checking the current status <a href="#check-migration-status" id="check-migration-status"></a>

Call `GET /api/hotspots/migration_status` to see how many hotspots remain to migrate. You can call this endpoint at any time, including while a migration is running. The `complete` field is `true` when no hotspots remain.

Example response:

```json
{
  "remainingHotspots": 31668,
  "complete": false
}
```

### Previewing the migration <a href="#preview-migration" id="preview-migration"></a>

Before running the migration, use dry-run mode to see how many hotspots would be migrated per project, without making any changes.

* Endpoint: `POST /api/hotspots/migrate_to_issues?dryRun=true`
* Optional parameter: `project`, the project key. If omitted, all projects are included in the preview.

Example response:

```json
{
  "dryRun": true,
  "projects": [
    {
      "projectKey": "my-project",
      "migrated": 7917,
      "skipped": 0
    }
  ]
}
```

### Running the migration <a href="#run-migration" id="run-migration"></a>

* Endpoint: `POST /api/hotspots/migrate_to_issues`
* Optional parameter: `project`, the project key.

{% hint style="warning" %}
If you omit the `project` parameter, all projects are migrated at once. On large instances, migrate project by project to avoid long-running processes and database load spikes. If the migration is started without any key and puts the database under too heavy load, the SonarQube Server instance must be restarted to stop the migration process.
{% endhint %}

Example response:

```json
{
  "dryRun": false,
  "projects": [
    {
      "projectKey": "my-project",
      "migrated": 7917,
      "skipped": 0
    }
  ]
}
```

### Handling skipped hotspots <a href="#handle-skipped-hotspots" id="handle-skipped-hotspots"></a>

Skipped hotspots belong to rules that have not yet been migrated to a vulnerability or code smell type, most likely from a custom plugin. Update the plugin to a version that no longer produces hotspots, then re-run the migration.

### Resuming an interrupted migration <a href="#resume-migration" id="resume-migration"></a>

The migration is idempotent. If it’s interrupted by a server failure or restart, re-run the same endpoint. Already-migrated hotspots are not reprocessed, and the migration continues from where it left off. No manual cleanup is required.


---

# 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/post-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.
