A newer Keycloak, with nobody locked out on the day

We plan the route, rehearse the full cutover on a copy running alongside production, and have a tested rollback ready on the day.

Sound familiar?

Which of these sounds like your team?

The gap keeps widening

The longer you wait, the more breaking changes one upgrade has to absorb.

Custom code at risk

Will the themes and extensions you built still load on the new release? Nobody knows yet.

An old WildFly install

The Quarkus-based release needs your configuration redone in a new format.

A new home for Keycloak

Alongside the upgrade, you are moving to Kubernetes or switching cloud providers.

Zero tolerance for an outage

The switch has to happen while people carry on signing in.

An undo nobody has tested

If the new version misbehaves, there is no rehearsed way to return to the old one.

Process

How we work

  1. 01

    Take stock

    Before any plan, we need to know what you run: Keycloak versions, extensions and every system that talks to it.

  2. 02

    Map the route

    We write out the upgrade sequence and note what could go wrong at each stage.

  3. 03

    Do a dry run

    A copy of production goes through the entire cutover before the real one does.

  4. 04

    Cut over

    On the agreed date the real switch happens, and reverting stays possible throughout.

Specifics

Technical details

  • Before planning, we go through what changed in every major release between your version and the target
  • If you are still on WildFly, your standalone.xml settings are translated into the Quarkus distribution's configuration options
  • Keycloak's database migration is rehearsed on a copy, and only after a restore from backup has worked
  • Anything custom, whether SPIs, themes or authentication flows, is ported to the new APIs and tested
  • We sign in to every connected app, OIDC or SAML, and confirm Active Directory or LDAP still answers
  • The surrounding deployment is brought up to date as well, from container images and Kubernetes or Operator config to clustering, caching, health checks and monitoring

Options

Flexible to fit you

  • Keep the current servers and upgrade themorStand up fresh servers next to the old ones
  • Go straight to the target releaseorStop at intermediate releases on the way
  • Deploy with the scripts you haveorLet the Keycloak Operator manage it
  • Keycloak stays in your data centreorKeycloak moves onto Kubernetes or a cloud
  • Grootan looks after it once liveorYour engineers take the keys

Measurement

What we measure

  • Whether people can still sign in after each step
  • Which applications start throwing errors, and how often
  • How long sign-in is unavailable on cutover day
  • Proof that no user or configuration data went missing

FAQ

Questions we hear

Is it safe to jump straight to the newest version?

Usually. The trade-off is that one big jump bundles every breaking change together, so whether it is wise depends on what the first review turns up.

Will users notice any downtime?

Often they won't. A zero-downtime switch depends on your deployment, which may let old and new run side by side or let nodes update in turn.

We still run the WildFly distribution. Can you move us?

Yes. Translating your WildFly settings for the Quarkus distribution is part of the job.

How is an upgrade priced?

Every setup is different, so the price follows the scope and how complex the work turns out to be. We talk it through on the first call.

Let's plan your next Keycloak upgrade

Related

More Keycloak services