IDPTrust
IDPTrust
idptrust.com
ENES
Keycloak upgrade service Built for Keycloak

Keycloak upgrade

Delegate the upgrade of your legacy instance to a team that does nothing but Keycloak.

We take the upgrade end to end: environment assessment, data and configuration migration, custom themes and SPIs, validation on a mirror environment, and a production cutover with a rollback plan. Your team doesn't have to drop what it's doing.

Request an upgrade assessmentSee the 5 phases

We reply within 24 business hours

When is it time to upgrade Keycloak?

There is rarely a specific day when the upgrade becomes urgent. These are the three signals we usually find once it already is.

Your version is out of support

Keycloak ships several releases a year and only maintains the recent ones. Outside that window, newly published CVEs are no longer patched for the version you run.

You are still on WildFly

The WildFly-based distribution was removed in Keycloak 20: if your instance is still there, it has gone years without patches. And the jump is not a binary swap — startup, configuration, the deployment model and, almost always, the database all change.

Nobody internally wants to own it

You upgraded once, something broke — a theme, a custom SPI, federation — and the instance has been frozen ever since. Or your team simply has other priorities and the upgrade has been in the backlog for two years.

Tell us about your case

It's an upgrade, not a platform change

It is still Keycloak: your realms, your users, your clients. What we do is bring your instance onto a supported version. The process does involve migrating data and configuration — the database schema changes between versions, and moving off WildFly changes the deployment model — but that is part of the upgrade, not a separate project. We are not asking you to change product or identity provider.

The upgrade, in 5 phases

Every phase has a reviewable deliverable. Production is untouched until the last one, and by then the whole process has already run end-to-end on a mirror environment.

  1. 1

    Environment assessment

    We inventory version, database, deployment, themes, custom SPIs, integrations and the number of realms and clients. This is what sets the scope, the real risks and the version path.

    Deliverable: Assessment report and upgrade plan with identified risks.

  2. 2

    Target instance deployment

    We stand up the new instance on the latest stable release (Quarkus) with PostgreSQL, aligned with your infrastructure: containers, Kubernetes or on-premise.

    Deliverable: A reproducible, documented mirror environment.

  3. 3

    Configuration and data migration

    We move realms, users, credentials, clients, roles, groups and federation, and adapt the configuration to whatever changed between versions.

    Deliverable: Target instance carrying your configuration and data, verified against the source.

  4. 4

    Themes, SPIs and validation

    We adapt themes, email templates and custom SPIs to the new version's APIs, and validate login flows, MFA, federation and integrations against your list of critical cases.

    Deliverable: Signed-off validation checklist and working customizations.

  5. 5

    Cutover and follow-up

    We run the switch to production in the agreed window, with a rollback plan and active monitoring through the first hours.

    Deliverable: Production on the new version, technical documentation and 4 weeks of post-upgrade support.

What you get

  • An upgrade plan with risks, version path, cutover window and rollback plan
  • Configuration and data migration verified against the source — not a blind export/import
  • Custom themes, email templates and SPIs adapted and rebuilt for the new version
  • Validation of login flows, MFA, federation and integrations before production is touched
  • Technical documentation of the resulting environment and of every decision taken
  • Team training and 4 weeks of post-upgrade support

Where we upgrade from — and to

  • From WildFly-based distributions (Keycloak 19 and earlier), including very old instances
  • From Quarkus-based versions that were left behind
  • From unsupported databases onto PostgreSQL
  • To the latest stable Keycloak release
  • Also one-off jumps within the same release stream
  • Your deployment, wherever it runs: AWS, Azure, GCP, Kubernetes or on-premise

What we need from your team

Delegating an upgrade shouldn't mean spinning up an internal project. We do the bulk of the work; your team's involvement is concentrated in four specific moments.

A 60–90 minute discovery session

With whoever knows the current deployment. From there we work autonomously and report in writing at the close of every phase.

A copy — not necessarily production access

A configuration export and a database copy are enough. Access to a pre-production environment speeds things up if your policy allows it, but it is not a requirement.

Your list of critical cases

Which applications, integrations and flows cannot fail. We turn that list into the validation checklist that gets signed off before the cutover.

A cutover window and someone reachable

For the production switch only. The rest of the project requires no availability from your team.

If your organization requires your own DBA to apply database changes, that works too: we generate the schema-change SQL and your team applies it under your change control.

How much does a Keycloak upgrade cost

We don't publish a fixed price because the effort depends on the starting point: a jump between minor versions is not the same job as a six-year-old WildFly instance with three custom SPIs. That is why the first phase is always the environment assessment: it produces a proposal with fixed scope, timeline and price before any work starts.

Typical duration: from a few days for a minor jump to 4–6 weeks for a full upgrade.

And afterwards? A support plan keeps the instance current — CVEs, patches and the year's minor upgrades — so you never fall behind again.

See Keycloak support plans

Upgrade questions

Does a Keycloak upgrade involve migrating data?
Yes, and it is part of the service. The database schema changes between versions and Keycloak applies its own migrations on startup. Our job is to make that happen under control: on a copy first, verifying the result, and with a rollback available.
Is a Keycloak upgrade the same as a Keycloak migration?
The words get used interchangeably, but they are worth separating. What we offer is the upgrade: bringing your Keycloak onto a supported version. That work does include migrating data and configuration, because the database schema changes between versions and leaving WildFly changes the deployment model. If what you need is migrating from another identity provider to Keycloak, that is a different project — and we do that too.
Can you upgrade without downtime?
With caveats. Keycloak only supports zero-downtime rolling updates between patch releases within the same release stream, and with sticky sessions on the load balancer. For a major or minor version jump — and always when leaving WildFly — a cutover window has to be planned. Our job is to make it short and predictable: by then the whole process has already been rehearsed on the mirror environment.
How much of our team's time does it take?
Little, and concentrated: the initial discovery session, the list of critical cases that cannot fail, reviewing each phase's deliverable, and the cutover window. Everything else — deployment, migration, adapting themes and SPIs, testing — is on us.
What happens to our custom themes and SPIs?
They get adapted. This is what most often breaks an upgrade, because Keycloak's internal APIs change between versions. We review them, rebuild them against the target version and test them on the mirror environment before the cutover.
Can we jump several versions at once?
Usually yes, but not always in a single hop: sometimes you have to pass through an intermediate version so schema migrations apply in order. The version path is defined during the assessment.
Do we lose users, credentials or sessions?
Users and credentials are preserved. Active sessions are lost at cutover: your users will have to authenticate again once.
What if something fails in production?
Keycloak does not roll back database schema changes, so a real rollback means restoring the previous installation together with the database backup taken before the cutover. That is prepared, documented and verified before production is touched — not improvised. And by then the process has already run end-to-end on the mirror environment: the cutover is not the first time we do it, it's the last.
Do you need access to production?
Not necessarily. We can work with direct access, in joint sessions with your team, or from exports and anonymized copies. If your rules require your own DBA to apply database changes, we generate the schema-change SQL for your team to apply under your change control.
Do you offer maintenance after the upgrade?
Yes. Support plans cover CVEs, patches and the year's minor upgrades. In fact, running a supported version is a requirement to enter a plan — which is why many clients start with the upgrade.

Let's talk about your upgrade

Tell us which version you run today, how it is deployed and what customizations you carry. We'll tell you what the jump involves and what it would take. We reply within 24 business hours.

Request an upgrade assessment