keycloak/docs/documentation/upgrading/topics/prep_migration.adoc
Ruchika Jha f92c27e26d
Make rolling updates for patch releases fully supported and Updated docs, release notes and upgrading guide for zero-downtime patch releases
Closes #45381
Closes #45756

Signed-off-by: Ruchika <ruchika.jha1@ibm.com>
Signed-off-by: Alexander Schwartz <alexander.schwartz@ibm.com>
Co-authored-by: Alexander Schwartz <alexander.schwartz@ibm.com>
2026-02-16 15:11:16 +00:00

32 lines
1.8 KiB
Text

[[_prep_migration]]
== Preparing for an upgrade
Starting with {project_name} 26.6.0 rolling updates of patch releases are supported.
See the https://www.keycloak.org/server/update-compatibility[Rolling Updates Guide] to determine if a rolling update is possible.
Perform the following steps before you upgrade the server.
.Procedure
. Shut down {project_name} if no rolling update is supported, for example if you perform a minor or major upgrade.
. Back up the old installation, such as configuration, themes, and so on.
. If XA transactions are enabled, handle any open transactions and delete the `data/transaction-logs/` transaction directory.
. Back up the database using the instructions in the documentation for your relational database.
[WARNING]
====
The database schema will no longer be compatible with the old server after the upgrade. Because {project_name} does not support rolling back the database changes, if you need to roll back to the previous version, first restore the old installation, and then restore the database from the backup copy.
====
[NOTE]
====
If the `persistent-user-sessions` feature is disabled in your current setup and the server is upgraded, all user sessions will be lost except for offline user sessions.
Users with these sessions will have to log in again.
Note that the `persistent-user-sessions` feature is disabled by default in {project_name} server releases prior to 26.0.0.
====
[WARNING]
====
Information about failed logins for brute force detection and currently ongoing authentication flows is only stored in the internal caches that are cleared when {project_name} is shut down.
Users currently authenticating, changing their passwords, or resetting their passwords will need to restart the authentication flow once {project_name} is up and running again.
====