> OctoPerf Enterprise Edition - Migration from 17.0.x to 17.1.0.

Source: https://api.octoperf.com/doc/on-premise-infra/migration/17.0.x-to-17.1.0/

# 17.0.x to 17.1.0

**Back up your database before upgrading.** Once migrated, the database cannot be used by a `17.0.x` server anymore.

## The database is migrated automatically at startup

At the first start of the `17.1.0` server, with no action from you:

- the `user` and `benchresult` indices are migrated,
- a new `userapikey` index is created: the API keys move from the `user` index to this index, with the same values, so the scripts and integrations using them keep working,
- every finished test gets its end date, shown at the top of its report.

On an installation with many test results, the migration can take several minutes. The server logs mark its start and its end, for example when upgrading from `17.0.1`:

```
[START] migration from version=17.0.1
[END] migration from version=17.0.1 to version=17.1.0
```

## Your load generators must be upgraded with the server

The JMeter images move to `17.1.0`. Pull the load generator images again on every machine that runs an [on-premise agent](https://api.octoperf.com/doc/on-premise-agent/provider-type/on-premise/), and restart the agents. If you launch load generators on Kubernetes, update the image tags in your own configuration too.

## If you call the REST API

Polling a task result now ends with a `404` when the task is unknown or expired. Every change is listed in [REST API changes: 17.0.1 to 17.1.0](https://api.octoperf.com/doc/api-changes-17.1/).

See the [17.1.0 release notes](https://api.octoperf.com/doc/release-notes/#1710-27th-september-2026) for the full list of changes.