Upgrade from v6.0.1 to v15/latest

Hi all,
I would like to hear from you if you think it’s possible (it’s a good idea :D) to upgrade from v6.0.1 to v15/latest and if yes what should be an upgrade plan/task?
We are currently using keycloak in kubernetes with external PostgreSQL 10.15 as DS and i read about the upgrade Upgrading Guide but I’m concerned about these step in a containerization env where the persistence is always a big question mark.
A last opinion i would ask from your experience is if migrating to a new latest version is better than upgrading from a old version 6.0.1 to the latest?

Thanks!

I would recommend doing it in few steps, like jump to version 9, then 11 and maybe then do the latest one. There are significant changes between version 6 and the latest version.

Update:
we completed the upgrade directly to v15, we used the codecentric helm chart and pointed to my postgres db that contains the data from v6, and the migration of the application and db went smoooth.
Just clone the charts and set the endpoint to your postgres, in the first run of new version there will be the db upgrade automatically.
We tested everything like multi realm, public client, private client, groups and roles and the upgrade didn’t affect anything.
The only 2 point to notice are:

  • create an index that is the output of the db schema migration at the first startup of v15
  • had to enable uploa-scripts funcionality with jdbc, to run script from admin console to i.e map groupsID(Alternative to Nashorn engine for Scripts?).

We also tested the themes from v6 to v15, as we mount it as init contianer/volumes and they worked without any change.

3 Likes

@NMUHA, Can you please share that did you face any downtime in this process?
If yes, how long was that, and what were the main reasons behind that?

@atulchauhan01 it depends, in our case we were able to have a migration run in parellal as we cloned the postgresql using the cloud provider’s capability and also on the server side we were able to replicate the deployment benefitting from the namespace in Kubernetes cluster. So the downtime is the time redirecting the routing in Istio(Service mesh in k8s).

1 Like