Actualizar Koha consiste en llevar la instancia a una versión soportada aplicando, en orden, las actualizaciones del esquema de la base de datos que cada versión intermedia introdujo. Los datos no se pierden: el proceso es acumulativo y el propio Koha ejecuta las migraciones de esquema al arrancar la versión nueva. Lo que sí se rompe con frecuencia son las personalizaciones —CSS del OPAC, plantillas modificadas, plugins y reportes SQL propios—, y por eso una actualización seria se ensaya antes en una copia.
Esta guía explica cómo funciona el ciclo de versiones de Koha, qué riesgos trae quedarse atrás, cómo se planifica un salto de varias versiones y qué revisar antes de tocar producción.
Cómo funciona el ciclo de versiones de Koha
Koha publica dos versiones mayores al año, en mayo y en noviembre, alrededor del día 22 de cada mes. La numeración sigue el año y el mes: 25.05 es la de mayo de 2025 y 25.11 la de noviembre de 2025. Entre versiones mayores se publican versiones de mantenimiento mensuales —25.11.03, por ejemplo— que solo traen correcciones de errores y parches de seguridad.
La comunidad mantiene varias ramas a la vez y las nombra por su antigüedad relativa: stable es la más reciente, oldstable la anterior y oldoldstable la que va dos atrás. Además, desde la versión 22.11 existe una rama LTS cada dos años, siempre en noviembre, con un mantenimiento extendido de alrededor de tres años y medio, pensada para instituciones que necesitan estabilidad prolongada.
Este es el estado de las ramas a septiembre de 2026:
| Rama | Versión | Publicada | Para quién |
|---|---|---|---|
| Estable | 26.05 | Mayo de 2026 | Instituciones que quieren las funciones más recientes |
| Anterior estable | 25.11 | Noviembre de 2025 | Opción conservadora y muy usada en producción |
| Dos versiones atrás | 25.05 | Mayo de 2025 | Aún recibe mantenimiento, pero conviene planificar la salida |
| LTS | 24.11 | Noviembre de 2024 | Instituciones que priorizan estabilidad y ciclos largos de cambio |
Como regla práctica, la comunidad mantiene dos o tres versiones mayores al mismo tiempo, con una vida útil que en promedio ronda los dieciocho meses por rama, salvo las LTS. Una instancia que lleva tres o cuatro años sin tocarse ya está fuera de mantenimiento.
Qué riesgo tiene quedarse en una versión antigua
- Sin parches de seguridad. Cada versión de mantenimiento suele corregir vulnerabilidades reales —inyección SQL, cross-site scripting, ejecución de código en plantillas—. Fuera de las ramas mantenidas esos parches no llegan, y el OPAC es un servicio público expuesto a internet.
- Dependencias del sistema operativo caducadas. Koha corre sobre Debian o Ubuntu con Perl y MariaDB; si el sistema operativo también quedó sin soporte, el problema deja de ser solo de Koha.
- Funciones que nunca llegan. Módulos completos, mejoras de accesibilidad del OPAC y de la API REST solo existen en versiones recientes.
- El salto se encarece con el tiempo. Actualizar cada seis o doce meses es rutina; hacerlo después de cuatro años es un proyecto con pruebas, retrabajo de personalizaciones y recapacitación.
- Menos gente que pueda ayudar. Las listas de la comunidad y los proveedores trabajan sobre las versiones vigentes; en una versión descontinuada las respuestas son escasas.
Qué cambia entre versiones mayores
Estos son algunos hitos que explican por qué el salto se nota tanto cuando se vienen arrastrando varios años. La lista no es exhaustiva —cada versión mayor trae cientos de correcciones y decenas de mejoras—, pero sirve para anticipar qué va a cambiar en pantalla y en la operación.
| Versión | Cambio destacado | Impacto en la biblioteca |
|---|---|---|
| 22.11 (LTS) | Rediseño completo de la interfaz del personal y llegada del módulo ERM de recursos electrónicos | El personal necesita reorientarse; aparece gestión de acuerdos, licencias y paquetes electrónicos |
| 24.05 | Facetas de Elasticsearch configurables desde la administración del motor de búsqueda | Quien use Elasticsearch gana control sobre el facetado sin tocar archivos del servidor |
| 24.11 (LTS) | Migración del OPAC y de la interfaz del personal a Bootstrap 5 | Es el cambio que más rompe CSS y plantillas personalizadas: cambian nombres de clases de maquetación |
| 25.05 y 25.11 | Mejoras continuas de accesibilidad del OPAC, API REST y consolidación del estilo Bootstrap 5 | Mejor experiencia pública; más superficie de integración vía API |
| 26.05 | Restauración de registros y ejemplares eliminados desde la interfaz, y visor de mensajes EDIFACT | Un borrado accidental deja de ser irreversible sin intervención técnica |
De todos estos, el que más trabajo genera en una actualización es el paso a Bootstrap 5. Si tu OPAC tiene CSS propio escrito para versiones anteriores, hay clases de alineación y de espaciado que cambiaron de nombre y que dejarán de aplicarse. No es un problema grave, pero sí es trabajo real que debe estar cotizado.
El salto de varias versiones: la ruta correcta
Koha no salta directo de una versión muy antigua a la actual sin pasar por las intermedias: cada versión mayor añadió sus propias actualizaciones de esquema y todas deben aplicarse en orden. La ruta probada es esta:
- Clonar producción a un servidor de pruebas: base de datos completa, archivos de configuración, plantillas y CSS personalizados.
- Registrar el punto de partida: versión exacta de Koha, versión del sistema operativo, de MariaDB o MySQL, motor de búsqueda en uso y lista de plugins instalados.
- Actualizar el sistema operativo si también quedó fuera de soporte. Es habitual que un Koha de cuatro años viva sobre un Debian que ya no recibe parches.
- Subir rama por rama, dejando que Koha aplique las actualizaciones de esquema en cada escalón y verificando que la instancia arranque antes de seguir.
- Reconstruir los índices de búsqueda al llegar a la versión de destino.
- Revisar personalizaciones: CSS del OPAC, plantillas modificadas, plugins, avisos y reportes SQL guardados.
- Probar con el equipo de la biblioteca los flujos reales: catalogar, prestar, devolver, reservar, renovar, generar el reporte de fin de mes.
- Programar la ventana de producción fuera del horario académico, con respaldo inmediatamente anterior y plan de retorno.
Actualización del esquema de la base de datos
Esta es la parte que más ansiedad genera y, paradójicamente, la más automatizada. Al arrancar por primera vez en la versión nueva, Koha detecta la versión registrada en la base de datos y ejecuta las actualizaciones pendientes en secuencia. En catálogos grandes puede tardar desde minutos hasta más de una hora, porque algunas de esas actualizaciones reescriben tablas completas.
Tres precauciones que no son negociables: tomar un volcado completo de la base de datos inmediatamente antes de empezar, verificar que hay espacio libre en disco suficiente para el crecimiento temporal de las tablas, y no interrumpir el proceso a mitad de camino. Si algo falla, se restaura el volcado y se vuelve a empezar; por eso el ensayo previo en un clon es la diferencia entre un incidente controlado y una emergencia.
Qué se rompe: plugins, plantillas y CSS
El núcleo de Koha migra bien. Lo que exige revisión es todo lo que se construyó encima:
- Plugins: cada uno declara con qué versiones de Koha es compatible. Un plugin sin mantenimiento puede quedarse en el camino y hay que decidir si se reemplaza, se adapta o se descarta.
- Plantillas modificadas directamente: si alguien editó los archivos de plantilla del OPAC en el servidor, esos cambios se pierden al actualizar. Lo correcto es reimplementarlos con las preferencias de personalización que ofrece el propio Koha.
- CSS del OPAC: el punto crítico del salto a Bootstrap 5. Hay que revisar clases de alineación, espaciado y flotado.
- Reportes SQL guardados: consultan tablas directamente. Si una versión cambió la estructura de una tabla, el reporte deja de funcionar o —peor— devuelve cifras equivocadas sin avisar. Hay que revalidarlos uno por uno.
- Integraciones: autenticación con LDAP o SAML, autopréstamo por SIP2, cosecha OAI-PMH y cualquier consumo de la API REST deben probarse explícitamente.
- Avisos y plantillas de correo: los mensajes de vencimiento y reserva disponible pueden requerir ajustes si cambiaron las variables disponibles.
Capacitación después del salto
Si la instancia viene de antes del rediseño de la interfaz del personal, el equipo va a encontrar un sistema distinto el lunes por la mañana. Aunque la lógica de catalogación y circulación es la misma, cambian la navegación, los menús y la ubicación de varias acciones. En nuestros proyectos de actualización esto se resuelve con una o dos sesiones cortas por área —catalogación, circulación, adquisiciones— apoyadas en una guía interna con capturas de pantalla del sistema ya actualizado, no del manual genérico.
Conviene además reservar las dos primeras semanas posteriores con soporte reforzado. La mayoría de los tiquetes en ese periodo no son fallas: son preguntas de «dónde quedó esta opción».
Checklist previa a la actualización
- Volcado completo de la base de datos, verificado y restaurado al menos una vez en el ambiente de pruebas.
- Copia de los archivos de configuración, plantillas y CSS personalizado.
- Inventario de plugins con su versión y su compatibilidad declarada.
- Listado de reportes SQL guardados que deben revalidarse.
- Versión objetivo decidida: estable reciente o LTS, según la tolerancia al cambio de la institución.
- Ventana de mantenimiento acordada con la biblioteca, fuera del calendario de exámenes o matrículas.
- Plan de retorno escrito: en qué condiciones se aborta y cuánto tarda restaurar.
- Responsable de comunicar a los usuarios que el OPAC estará fuera de servicio durante la ventana.
Si tu instancia lleva años sin actualizarse y además vive en un servidor que nadie mantiene, la actualización es el momento natural para replantear la infraestructura: revisa hosting de Koha, nube gestionada o servidor propio. Si el catálogo también arrastra duplicados y registros sin ejemplar, conviene combinar la actualización con una depuración, como se describe en la guía de migración a Koha. Para el panorama general de la plataforma está la guía de Koha y su implementación, y si quieres que lo hagamos nosotros, revisa el servicio de Koha.