IDPTrust
IDPTrust
idptrust.com
ENES
Servicio de upgrade de Keycloak Built for Keycloak

Upgrade de Keycloak

Delegue la actualización de su instancia antigua en un equipo que solo hace Keycloak.

Nos hacemos cargo del upgrade de principio a fin: evaluación del entorno, migración de datos y configuración, temas y SPIs propios, validación en un entorno espejo y cutover a producción con plan de vuelta atrás. Su equipo no tiene que parar lo que está haciendo.

Solicitar evaluación de upgradeVer las 5 fases

Respuesta en menos de 24 horas laborables

¿Cuándo toca actualizar Keycloak?

Casi nunca hay un día concreto en el que el upgrade se vuelve urgente. Estas son las tres señales que solemos encontrar cuando ya lo es.

Su versión está fuera de soporte

Keycloak publica varias versiones al año y solo mantiene las recientes. Fuera de esa ventana, los CVEs que se publican ya no se parchean para la versión que usted ejecuta.

Sigue sobre WildFly

La distribución sobre WildFly se eliminó en Keycloak 20: si su instancia sigue ahí, lleva años sin recibir parches. Y el salto no es un cambio de binario, porque cambian el arranque, la configuración, el modelo de despliegue y, casi siempre, la base de datos.

Nadie internamente quiere hacerse cargo

Se actualizó una vez, algo se rompió —un tema, un SPI propio, la federación— y desde entonces la instancia está congelada. O simplemente su equipo tiene otras prioridades y el upgrade lleva dos años en el backlog.

Contar nuestro caso

Es un upgrade, no un cambio de plataforma

Sigue siendo Keycloak: sus realms, sus usuarios, sus clients. Lo que hacemos es llevar su instancia a una versión con soporte. Durante el proceso hay migración de datos y de configuración —el esquema de base de datos cambia entre versiones y el salto de WildFly a Quarkus cambia el modelo de despliegue—, pero eso es una parte del upgrade, no un proyecto aparte. No le pedimos que cambie de producto ni de proveedor de identidad.

El upgrade, en 5 fases

Cada fase tiene un entregable revisable. Producción no se toca hasta la última, y para entonces el proceso ya se ha ejecutado entero en un entorno espejo.

  1. 1

    Evaluación del entorno

    Inventariamos versión, base de datos, despliegue, temas, SPIs propios, integraciones y volumen de realms y clients. De aquí salen el alcance, los riesgos reales y la ruta de versiones.

    Entregable: Informe de evaluación y plan de upgrade con riesgos identificados.

  2. 2

    Despliegue de la instancia destino

    Levantamos la nueva instancia sobre la última versión estable (Quarkus) con PostgreSQL, alineada con su infraestructura: contenedores, Kubernetes u on-premise.

    Entregable: Entorno espejo reproducible y documentado.

  3. 3

    Migración de configuración y datos

    Trasladamos realms, usuarios, credenciales, clients, roles, grupos y federación, y adaptamos la configuración a lo que cambió entre versiones.

    Entregable: Instancia destino con su configuración y sus datos, verificada contra el origen.

  4. 4

    Temas, SPIs y validación

    Adaptamos temas, plantillas de email y SPIs propios a las APIs de la nueva versión y validamos flujos de login, MFA, federación e integraciones contra su lista de casos críticos.

    Entregable: Checklist de validación cerrado y personalizaciones funcionando.

  5. 5

    Cutover y acompañamiento

    Ejecutamos el paso a producción en la ventana acordada, con plan de vuelta atrás y seguimiento activo durante las primeras horas.

    Entregable: Producción en la nueva versión, documentación técnica y 4 semanas de soporte post-upgrade.

Qué se lleva

  • Plan de upgrade con riesgos, ruta de versiones, ventana de cutover y plan de vuelta atrás
  • Migración de configuración y datos verificada contra el origen, no un export/import a ciegas
  • Temas, plantillas de email y SPIs propios adaptados y recompilados para la nueva versión
  • Validación de flujos de login, MFA, federación e integraciones antes de tocar producción
  • Documentación técnica del entorno resultante y de cada decisión tomada
  • Formación a su equipo y 4 semanas de soporte post-upgrade

Desde dónde y hasta dónde

  • Desde distribuciones sobre WildFly (Keycloak 19 y anteriores), incluidas instancias muy antiguas
  • Desde versiones sobre Quarkus que se quedaron sin actualizar
  • Desde bases de datos sin soporte hacia PostgreSQL
  • Hasta la última versión estable de Keycloak
  • También saltos puntuales dentro de la misma rama de versión
  • Su despliegue, donde esté: AWS, Azure, GCP, Kubernetes u on-premise

Qué necesitamos de su equipo

Delegar un upgrade no debería significar montar un proyecto interno. El grueso del trabajo lo ejecutamos nosotros; la implicación de su equipo se concentra en cuatro momentos concretos.

Una sesión de descubrimiento de 60–90 minutos

Con quien conozca el despliegue actual. A partir de ahí trabajamos de forma autónoma y le reportamos por escrito al cerrar cada fase.

Una copia, no necesariamente acceso a producción

Nos basta con una exportación de la configuración y una copia de la base de datos. Si su política lo permite, el acceso a preproducción acelera el trabajo, pero no es imprescindible.

Su lista de casos críticos

Qué aplicaciones, integraciones y flujos no pueden fallar. Nosotros convertimos esa lista en el checklist de validación que se firma antes del cutover.

Una ventana de cutover y una persona localizable

Solo para el paso a producción. El resto del proyecto no requiere disponibilidad de su equipo.

Si su organización exige que los cambios en base de datos los aplique su propio DBA, también se puede: generamos el SQL del cambio de esquema y lo aplica su equipo bajo su control de cambios.

Cuánto cuesta un upgrade de Keycloak

No publicamos un precio cerrado porque el esfuerzo depende del punto de partida: no es lo mismo un salto entre versiones menores que una instancia de hace seis años sobre WildFly con tres SPIs propios. Por eso la primera fase es siempre la evaluación del entorno: de ahí sale una propuesta con alcance, plazo y precio cerrados antes de empezar.

Duración habitual: de unos días en un salto menor a 4–6 semanas en un upgrade completo.

¿Y después? Un plan de soporte mantiene la instancia al día —CVEs, parches y las actualizaciones menores del año— para que no vuelva a acumular retraso.

Ver planes de soporte Keycloak

Preguntas sobre el upgrade

¿Un upgrade de Keycloak implica migrar datos?
Sí, y es parte del servicio. El esquema de base de datos cambia entre versiones y Keycloak aplica sus propias migraciones al arrancar. Nuestro trabajo es que eso ocurra de forma controlada: sobre una copia primero, verificando el resultado y con vuelta atrás posible.
¿Es lo mismo un upgrade que una migración de Keycloak?
Se usan como sinónimos, pero conviene distinguirlos. Lo que ofrecemos es el upgrade: llevar su Keycloak a una versión con soporte. Dentro de ese trabajo hay migración de datos y de configuración, porque el esquema de base de datos cambia entre versiones y salir de WildFly cambia el modelo de despliegue. Si lo que busca es migrar desde otro proveedor de identidad hacia Keycloak, eso es otro proyecto y también lo hacemos.
¿Se puede actualizar sin cortar el servicio?
Con matices. Keycloak solo admite actualizaciones sin corte (rolling) entre versiones de parche dentro de la misma rama, y con sticky sessions en el balanceador. Para un salto de versión mayor o menor —y siempre al salir de WildFly— hay que planificar una ventana de cutover. Nuestro trabajo es que sea corta y predecible: para entonces el proceso ya se ha ensayado entero en el entorno espejo.
¿Cuánto tiempo de nuestro equipo consume?
Poco y concentrado: la sesión de descubrimiento inicial, la lista de casos críticos que no pueden fallar, la revisión de los entregables de cada fase y la ventana de cutover. El resto —despliegue, migración, adaptación de temas y SPIs, pruebas— lo ejecutamos nosotros.
¿Qué pasa con nuestros temas y SPIs a medida?
Se adaptan. Es lo que más rompe en un upgrade, porque las APIs internas de Keycloak cambian entre versiones. Los revisamos, los recompilamos contra la versión destino y los probamos en el entorno espejo antes del cutover.
¿Podemos saltar varias versiones de golpe?
En general sí, pero no siempre en un único salto: a veces hay que pasar por una versión intermedia para que las migraciones de esquema se apliquen en orden. La ruta de versiones se define en la evaluación.
¿Perdemos usuarios, credenciales o sesiones?
Usuarios y credenciales se conservan. Las sesiones activas sí se pierden en el cutover: sus usuarios tendrán que volver a autenticarse una vez.
¿Y si algo falla en producción?
Keycloak no revierte los cambios de esquema de base de datos, así que la vuelta atrás real consiste en restaurar la instancia anterior junto con la copia de la base de datos previa al cutover. Eso se prepara, se documenta y se verifica antes de tocar producción, no se improvisa. Y para entonces el proceso ya se ha ejecutado entero en el entorno espejo: el cutover no es la primera vez que lo hacemos, es la última.
¿Necesitamos daros acceso a producción?
No necesariamente. Podemos trabajar con acceso directo, en sesiones conjuntas con su equipo o sobre exportaciones y copias anonimizadas. Si sus normas exigen que los cambios en base de datos los aplique su propio DBA, generamos el SQL del cambio de esquema para que lo aplique su equipo bajo su control de cambios.
¿Ofrecéis mantenimiento después del upgrade?
Sí. Los planes de soporte cubren CVEs, parches y las actualizaciones menores del año. De hecho, estar en una versión con soporte es requisito para entrar en un plan: por eso muchos clientes empiezan por el upgrade.

¿Hablamos de su upgrade?

Cuéntenos qué versión usa hoy, cómo está desplegada y qué personalizaciones tiene. Le decimos qué implica el salto y qué haría falta. Respondemos en menos de 24 horas laborables.

Solicitar evaluación de upgrade