Actualizar Moodle es una de esas tareas que se posponen. Hay campus virtuales funcionando con versiones de hace tres o cuatro años, y no por dejadez: funciona, hay alumnos dentro, y nadie quiere ser quien toque algo que podría romperse en mitad de una convocatoria.
El problema es que una plataforma que no se actualiza acumula dos cosas. Deja de recibir parches de seguridad, con datos personales de alumnos dentro. Y cada salto que se pospone hace el siguiente más difícil, porque las distancias entre versiones se suman.
Actualizar no es complicado si se prepara bien. Lo que da problemas es hacerlo sin comprobar antes qué hay instalado y sobre qué servidor funciona.
Cuándo conviene actualizar Moodle
Moodle publica versiones con un ciclo de soporte definido. Cada versión recibe actualizaciones de seguridad durante un tiempo determinado y después deja de recibirlas, aunque la plataforma siga funcionando con normalidad.
Ese es el punto que importa: una instalación sin soporte no se cae, simplemente deja de protegerse. Sigue dando servicio con aparente normalidad mientras acumula vulnerabilidades conocidas y públicas, con datos personales de alumnos dentro.
Si no sabéis en qué versión estáis, se comprueba desde la administración del sitio, en la página de notificaciones, donde aparece la versión instalada y si hay actualizaciones disponibles.
En qué versión está Moodle ahora
Moodle organiza sus versiones en dos tipos. Las de soporte estándar, que reciben actualizaciones durante unos dieciocho meses, y las LTS o de soporte a largo plazo, que mantienen las correcciones de seguridad durante tres años.
La última versión estable es Moodle 5.2.3, publicada el 13 de septiembre de 2026. Requiere PHP 8.3 y, como base de datos, MariaDB 10.11, MySQL 8.4, PostgreSQL 16 o SQL Server como mínimo. Ese dato ya es relevante por sí solo: muchos servidores con instalaciones antiguas no cumplen esos requisitos sin actualizar antes el entorno.
La versión LTS vigente es Moodle 4.5, que es donde sigue buena parte de los campus en funcionamiento. En esa versión las correcciones de errores generales terminaron en octubre de 2025 y las de seguridad se mantienen hasta octubre de 2027. Quien esté en 4.5 todavía está protegido, pero con fecha de caducidad conocida.
La próxima versión de soporte a largo plazo será Moodle 5.3, prevista para octubre de 2026, con una interfaz renovada y mejoras de usabilidad. Para una organización que prefiere saltar pocas veces y mantenerse estable, será la referencia natural.
Qué se gana al actualizar Moodle
La seguridad es el argumento más repetido, pero no es el único ni el que más se nota en el día a día. Entre una versión de hace tres años y la actual hay diferencias que el equipo y el alumnado perciben desde el primer día.
Una interfaz más usable
Moodle ha ido rehaciendo su experiencia de usuario versión a versión: navegación dentro del curso, organización de los contenidos, comportamiento en móvil. Es la diferencia entre un campus que parece una herramienta interna y uno que se usa sin pensar.
Y tiene efecto medible: buena parte de las consultas que recibe un equipo de formación no son dudas sobre el contenido, son dudas sobre dónde está cada cosa.
Inteligencia artificial integrada en el núcleo
Las versiones recientes han incorporado proveedores de IA directamente en el núcleo de la plataforma, en lugar de depender de plugins externos. Eso abre la puerta a usos que antes requerían desarrollo a medida: apoyo en la generación de materiales, asistencia en la corrección o resúmenes automáticos.
No sustituye a un desarrollo propio cuando hace falta algo específico, pero sí cubre de serie lo que hace unos años había que construir.
Mejoras para el profesorado
Cada versión trae funcionalidades concretas que ahorran tiempo: mejoras en la corrección de tareas, en el banco de preguntas, en los informes personalizados o en el libro de calificaciones. Son cosas poco vistosas que se traducen en horas recuperadas cada convocatoria.
Compatibilidad hacia adelante
Cuanto más atrás se queda una instalación, más difícil es todo lo demás: integrar un sistema externo, instalar un plugin moderno, aprovechar una funcionalidad nueva. Mantenerse en versiones con soporte no es solo protegerse, es conservar la capacidad de seguir construyendo sobre la plataforma.
Qué comprobar antes de actualizar Moodle
Aquí está la mayor parte del trabajo, y es lo que determina que la actualización sea un trámite previsible o un problema.
La versión de PHP del servidor
Cada versión de Moodle exige un rango concreto de PHP. La 5.2 requiere PHP 8.3 y versiones concretas de base de datos (MariaDB 10.11, MySQL 8.4, PostgreSQL 16 o SQL Server), y si el servidor está por debajo del mínimo la actualización no va a funcionar. Tampoco si está muy por encima, porque las versiones antiguas de Moodle no son compatibles con las más recientes de PHP.
Es lo primero que bloquea una actualización y lo que más veces se descubre tarde. Conviene mirarlo antes que nada, porque a veces implica hablar con el proveedor de alojamiento y eso lleva su tiempo.
Todos los plugins instalados
No se actualiza solo Moodle: se actualizan también todos los plugins. Y ahí es donde aparecen las sorpresas.
Un campus con unos años de vida acumula plugins que alguien instaló para resolver algo concreto: un tipo de actividad, un informe, una integración, un bloque en la portada. Algunos siguen mantenidos y tienen versión compatible. Otros no.
Cuando un plugin lleva tiempo sin actualizarse por su autor, hay tres salidas: buscar una alternativa que haga lo mismo, asumir que esa funcionalidad desaparece, o desarrollar un sustituto propio. Ninguna de las tres se improvisa el día de la actualización, y por eso hay que inventariar los plugins antes.
Desarrollos hechos sobre el núcleo
Este es el caso más incómodo. Si en algún momento alguien resolvió una necesidad modificando directamente el código base de Moodle en lugar de desarrollar un plugin, esos cambios se pierden al actualizar. La actualización sobrescribe el núcleo.
A veces se detecta porque algo que funcionaba deja de hacerlo. Otras veces nadie recuerda que se tocó. Por eso, en una instalación heredada de otro proveedor, conviene revisar si el núcleo está modificado antes de planificar nada.
Es también la razón por la que nosotros no tocamos el núcleo nunca: todo lo que desarrollamos va como plugin o como tema, precisamente para que sobreviva a las actualizaciones. Puedes ver cómo trabajamos en nuestros desarrollos sobre Moodle.
El tema visual
Si el campus tiene un tema propio o muy personalizado, los cambios de versión en la interfaz de Moodle pueden afectarle. No siempre, pero conviene comprobarlo, sobre todo en saltos grandes.
Cómo hacerlo sin interrumpir los cursos
La preocupación real de quien tiene un campus en marcha no es perder datos, es cortar el servicio con alumnos dentro, en mitad de una convocatoria o de un plazo de entrega.
Se resuelve no actualizando nunca directamente sobre el campus que está en uso.
Primero, una copia completa. Se levanta una réplica del campus en un entorno aparte, con los mismos datos, los mismos plugins y la misma configuración.
Sobre esa copia se hace la actualización y se comprueba todo: que los cursos se ven bien, que las actividades funcionan, que los informes siguen saliendo, que las integraciones responden, que los plugins importantes han sobrevivido. Si algo se rompe, se rompe en un entorno donde no hay nadie trabajando.
Y solo cuando la copia funciona, se lleva a producción. Con todo verificado de antemano, la ventana de parada real se reduce a lo imprescindible y se puede programar en el momento de menos actividad.
Es más trabajo que actualizar directamente sobre producción, pero convierte una incidencia imprevista en una parada planificada.
Qué determina el alcance del trabajo
No hay un coste ni un plazo únicos, y desconfiaría de quien los dé sin mirar la instalación. Lo que marca la diferencia es:
Desde qué versión partís. No es lo mismo un salto de una versión que de cuatro años acumulados. Los saltos grandes a veces hay que hacerlos por etapas.
Cuántos plugins hay y en qué estado. Un campus con el Moodle estándar y tres plugins mantenidos es un trabajo acotado. Uno con veinte plugins, varios abandonados, es otra cosa.
Si hay desarrollos a medida o el núcleo modificado. Determina cuánto hay que revisar y, en el peor caso, qué hay que rehacer.
Las integraciones con otros sistemas. Si el campus está conectado con un ERP, un CRM o una tienda online, esas conexiones hay que verificarlas también.
Por eso lo primero que hacemos siempre es una revisión de la instalación. Con eso se sabe qué hay, qué sobrevive al salto y qué hay que resolver antes, y a partir de ahí se puede dar un plazo y un presupuesto reales. Puedes ver todo lo que hacemos sobre plataforma LMS y campus virtuales.
Preguntas frecuentes sobre actualizar Moodle
¿Se pierden los cursos o las calificaciones al actualizar?
No. Una actualización de Moodle conserva cursos, usuarios, calificaciones e histórico de actividad: solo cambia el código de la plataforma, no los datos. Lo que sí puede dejar de funcionar es un plugin sin mantenimiento o un desarrollo hecho sobre el núcleo, y por eso se comprueba todo sobre una copia antes de tocar el campus real.
¿Cuánto tiempo estará el campus parado?
Si la actualización se ha probado antes sobre una copia, la parada real es corta y se puede programar en el horario de menos actividad. Lo que alarga una parada es descubrir problemas durante el proceso, que es justo lo que evita trabajar primero sobre una réplica.
¿Podemos saltar varias versiones de golpe?
Depende de la distancia. Moodle permite saltos directos dentro de ciertos rangos, pero cuando se acumulan varios años a veces hay que actualizar por etapas, pasando por una versión intermedia. Se determina al revisar la instalación.
¿Qué pasa con los plugins que ya no tienen mantenimiento?
Hay que decidir antes de actualizar: buscar una alternativa equivalente, prescindir de esa funcionalidad o desarrollar un sustituto. Lo importante es detectarlo en la revisión previa y no el día de la actualización, cuando ya no hay margen.
¿Podéis actualizar un Moodle que ha llevado otra empresa?
Sí, y es bastante habitual. Empezamos con una revisión de la instalación: versión, plugins, desarrollos a medida, estado del servidor y si el núcleo está modificado. Con ese diagnóstico sabemos qué se aprovecha, qué hay que rehacer y con qué riesgos.