Actualizar Moodle 4.5 a 5.3 LTS: guía práctica y checklist

Moodle 4.5 puede actualizarse directamente a Moodle 5.3 LTS. No hace falta instalar cada versión intermedia, pero sus cambios sí llegan al campus: otro entorno de servidor, un directorio público distinto, cambios en los bancos de preguntas y componentes que han salido del núcleo. La ruta admitida por Moodle es solo una parte de la preparación.

Esta guía está dirigida a responsables de plataforma, administradores y equipos de ingeniería. También ayuda a dirección académica y operación a decidir qué debe comprobarse antes de reabrir. El objetivo es llegar a un campus que conserve los recorridos acordados, con un procedimiento de recuperación que pueda ejecutarse si el cambio falla.

Las fuentes se consultaron el 15 de octubre de 2026. Se trata de Moodle LMS: las distribuciones derivadas y los servicios gestionados necesitan sus propias comprobaciones. Adapta los comandos y las rutas a tu instalación y ensaya el procedimiento en preproducción antes de intervenir en el campus.

Elegir destino y momento: 4.5 todavía tiene soporte de seguridad

Moodle 5.3 LTS se publicó el 5 de octubre de 2026. El calendario oficial diferencia soporte general y correcciones de seguridad:

Por tanto, seguir temporalmente en 4.5 no equivale a usar una rama sin correcciones de seguridad. Hay margen para preparar el salto, manteniendo los parches de la rama actual. Tampoco conviene dar por hecho que esperar unos días resolverá un plugin sin mantenimiento.

El calendario sitúa 5.3.1 el 7 de diciembre de 2026; es una fecha prevista, no una versión ya disponible. La decisión de publicar debe atender a compatibilidad, incidencias relevantes, ensayos y calendario académico. Un campus puede preparar ahora la infraestructura y el ensayo y fijar después su versión exacta de producción.

Ruta admitida y requisitos de Moodle 5.3

Las notas oficiales de 5.3 permiten actualizar desde 4.4 o posterior. El origen 4.5 entra en esa ruta; el núcleo no exige pasar sucesivamente por 5.0, 5.1 y 5.2. Para versiones anteriores hay que planificar pasos intermedios verificando los requisitos de cada destino.

Se utiliza el motor que corresponda a la instalación. No hay que disponer de todos. Oracle dejó de estar soportado desde Moodle 5.0.

PostgreSQL 16 y MariaDB 10.11 corresponden a requisitos anteriores: no deben copiarse como mínimos de 5.3. Tampoco «PHP 8.3 o superior» permite dar por soportada cualquier versión futura. Comprobar una familia admitida y su parche concreto evita esa ambigüedad.

El informe de Administración del sitio → Servidor → Entorno ayuda a identificar requisitos. Hay que contrastar también el PHP de la web y el de consola: pueden utilizar distintos ejecutables, extensiones y configuraciones. Memoria, almacenamiento, cachés y capacidad se dimensionan con el campus; cumplir mínimos no demuestra rendimiento bajo su carga.

Qué cambia entre 4.5 y 5.3 aunque el salto sea directo

La preparación debe recorrer las notas intermedias. Esta selección organiza los cambios con efecto en el ensayo; no sustituye sus listas completas.

Moodle 5.0: evaluación, temas y componentes retirados

Las notas de 5.0 incorporan bancos de preguntas compartidos y cambios en los intentos de cuestionario. Conviene probar permisos para usar preguntas, categorías, tipos de pregunta de terceros, intentos anteriores y nuevos, calificación y restauración de cursos.

La guía de actualización de 5.0 recoge Bootstrap 5 y la salida del núcleo de Chat, Survey, Atto, autenticación CAS y componentes MNet. Si se usan, hace falta decidir cómo conservar su función y sus datos. Que un componente salga del núcleo no significa que deba borrarse sin revisar su alternativa mantenida. Los temas propios necesitan comprobar sus plantillas, estilos e interacciones. También cambia la configuración de proveedores de IA y se anuncia la retirada de MimeTeX, completada en 5.2: se ensaya el editor, la integración de IA y la representación de fórmulas cuando formen parte del campus.

Moodle 5.1: nueva raíz pública y ubicación de plugins

Desde 5.1, el servidor web debe apuntar a la carpeta public, no a la raíz completa de instalación. Los plugins que estaban en mod, local o theme pasan a sus ubicaciones bajo public. config.php permanece fuera de esa carpeta. Se revisan las rutas usadas por despliegues y tareas de las extensiones. Los scripts del núcleo, incluido cron, permanecen en admin/cli, fuera de public. Aviso oficial de 5.1.

Moodle 5.2: entorno y recorridos que siguen evolucionando

5.2 eleva PHP a 8.3 y rediseña el acceso y MFA. Retira el bloque Activities y MimeTeX, elimina las páginas de subsección y permite migrar sus descripciones a actividades de texto y medios o eliminarlas. Se comprueban fórmulas, accesos anteriores al contenido y enlaces externos a subsecciones. También incorpora la comprobación del enrutamiento en el informe de entorno. Aunque una actualización desde 4.5 no se detenga en esta rama, se prueban autenticación, roles y evaluación con el conjunto final. La incorporación de telemetría es una capacidad opcional: no hace falta implantarla para completar la actualización. Notas de 5.2.

Moodle 5.3: tema, navegación y contenido que requiere una decisión

5.3 actualiza la interfaz y la navegación e introduce mejoras de evaluación e IA. Para una instalación existente interesan especialmente estas comprobaciones:

• Classic sale del núcleo. Si hay que conservar el tema y sus ajustes, su versión mantenida debe prepararse antes de la actualización. Instalarlo después no recupera automáticamente sus selecciones anteriores. Revisar también cualquier tema forzado en config.php. Notas del tema en v5.3.0.
• El bloque Activities se retiró en 5.2. Identificar los cursos y páginas que dependían de ese acceso y comprobar cómo se llega a sus actividades.
• Desde 5.2, las descripciones de subsecciones requieren una decisión. La administración permite migrarlas a actividades de texto y medios o eliminarlas; hay que revisar contenido antes de elegir.
• La navegación superior y secundaria pasa a componentes React del Design System. Revisar plantillas sobrescritas, CSS propio y personalizaciones del menú de usuario. La navegación lineal pasa a controlarse mediante un ajuste de sitio: se ensayan las acciones y los accesos utilizados en cada curso.
• Las notificaciones de nuevo inicio de sesión se activan por defecto. Registrar el ajuste previsto, comunicarlo y comprobar destinatarios y volumen de correo. En la copia de ensayo el correo debe estar aislado antes de iniciar pruebas.

Las retiradas y la migración de subsecciones están documentadas en la guía de actualización de 5.3. Deben formar parte de las pruebas y de la comunicación al profesorado cuando afecten a su trabajo.

La navegación React, el menú de usuario y las notificaciones se identifican en las notas oficiales de 5.3. Son comprobaciones de compatibilidad y operación, no opciones que deban activarse indiscriminadamente.

Extensiones y código propio: la matriz que determina la viabilidad

El inventario incluye actividades, bloques, tipos de pregunta, formatos de curso, tema, autenticación, matriculación, informes, integraciones y extensiones locales. Para cada componente, se conserva versión instalada, versión propuesta, dependencias, fuente del mantenedor y resultado del ensayo.

La compatibilidad declarada permite preparar una combinación; su funcionamiento local necesita pruebas. Un plugin propio requiere revisar sus migraciones de datos, APIs, consultas, permisos, tareas, servicios e interfaz. Las notas de actualización para desarrolladores ayudan a localizar cambios y retiradas. Cambiar únicamente el número de versión requerido no adapta un plugin.

También se comparan las modificaciones del núcleo con la versión original correspondiente. Un parche no registrado puede desaparecer al sustituir el código. Debe decidirse si sigue siendo necesario, si se puede convertir en extensión o si requiere adaptación.

La decisión puede ser actualizar, adaptar, sustituir, conservar una versión comprobada o aplazar. Desinstalar un complemento puede eliminar datos asociados; no debe utilizarse como limpieza automática para forzar la actualización.

5.2 elimina APIs cuya deprecación final corresponde a métodos antiguos, incluidos los de 4.x hasta 4.4. Antes del salto se recogen los avisos de depuración en una copia aislada de 4.5 y se ensaya el código propio en el destino. En 5.3 también cambian módulos AMD utilizados con frecuencia a ESM y se deprecan las clases antiguas de servicios externos; deprecación y eliminación no son el mismo estado. Revisar las retiradas de 5.2 y las notas para desarrolladores de 5.3.

Ensayar sobre una copia que permita comprobar el campus

La copia debe partir de la versión de origen y conservar las características relevantes: plugins, datos representativos, archivos y configuración. Una instalación nueva y vacía de 5.3 no prueba las migraciones de un Moodle 4.5 existente.

Antes de iniciar tareas en la copia, se aíslan sus efectos externos: correo, pagos, matrícula, notificaciones, servicios de identidad y automatizaciones. También se separan las cachés y los espacios de sesión que puedan confundirse con producción. Los accesos y el tratamiento de los datos se acuerdan según el contenido del campus.

El ensayo reproduce el cambio de servidor y aplicación previsto, mide la duración y registra errores y diferencias. Si se va a actualizar la base de datos, esa operación merece un ensayo y un procedimiento de retorno propios. Las otras aplicaciones del servidor pueden depender de ese mismo motor o de PHP.

Se puede estudiar una fase previa para cambiar infraestructura mientras Moodle permanece en 4.5, pero solo si el parche de origen, las extensiones y las demás aplicaciones admiten la combinación propuesta. Otra opción es preparar el destino en un entorno separado. No se presupone que cualquier motor mínimo de 5.3 funcione con 4.5: cada fase y su recuperación se ensayan por separado.

Checklist de preparación, intervención y reapertura

La checklist descargable se puede completar con responsables y evidencias. Marcar una casilla significa haber comprobado el punto, no haber leído este artículo.

Antes de fijar la ventana

1. Registrar versión y parche de origen, método de instalación y versión exacta de destino.
2. Verificar ruta admitida, PHP de web y consola, motor de datos y requisitos del entorno.
3. Completar el inventario de plugins, tema, integraciones y parches del núcleo; resolver las incompatibilidades críticas.
4. Revisar las notas 5.0–5.3 y localizar contenidos o componentes afectados por retiradas.
5. Preparar una copia aislada de la instalación de origen y ejecutar en ella la actualización prevista.
6. Ensayar restauración, medir tiempos y acordar quién decide publicar o volver atrás.
7. Seleccionar recorridos con docentes y operación; conservar el resultado del ensayo y los pendientes.

Durante la intervención

1. Comunicar el cambio, activar mantenimiento y detener entradas externas, cron y trabajadores según el plan. Esperar a que terminen los procesos en curso.
2. Obtener la copia final coherente y comprobar que se puede utilizar para recuperar el entorno.
3. Desplegar el código preparado, extensiones, configuración web y dependencias; ejecutar la actualización con la versión PHP acordada.
4. Resolver los pendientes previstos de tareas y contenido, purgar cachés y realizar las comprobaciones de aceptación antes de reabrir.

Al reabrir y después

1. Reactivar coordinadamente procesos e integraciones y verificar su ejecución; recuperar el acceso de usuarios cuando se acepte el resultado.
2. Observar errores, tiempos, tareas atrasadas e incidencias académicas frente a la referencia anterior.
3. Conservar evidencias, copia y procedimiento de retorno durante el periodo acordado; documentar las diferencias que quedan pendientes.

Si un punto crítico no tiene evidencia, la publicación queda pendiente. El orden exacto de mantenimiento y despliegue debe ajustarse a la arquitectura ensayada.

Código, directorio public y Composer

El despliegue se prepara con un árbol limpio de la versión elegida y las extensiones inventariadas. Superponer todos los archivos nuevos sobre los anteriores puede dejar código obsoleto. Se conserva el árbol previo como parte de la recuperación y se trasladan solo configuración y extensiones identificadas, en sus versiones acordadas.

En una instalación convencional cuyo código está en /srv/moodle, la estructura de destino es:

/srv/moodle/
  config.php
  admin/cli/
  public/
    admin/
    mod/
    local/
    theme/
    r.php
/srv/moodledata/

Los scripts de administración del núcleo permanecen en /srv/moodle/admin/cli; no se trasladan dentro de la raíz web. Las herramientas de cada extensión se revisan en su ubicación efectiva.

La raíz web apunta a /srv/moodle/public. moodledata queda fuera del acceso público. Si la URL del campus se mantiene, no se añade /public a wwwroot solo porque haya cambiado la carpeta física. El servidor debe atender también el enrutamiento de r.php; la configuración concreta depende de Apache, Nginx, IIS o el alojamiento. Reestructura oficial.

Composer requiere distinguir el método de instalación. La guía oficial de 5.3 indica que, si la instalación utiliza Composer o conserva un directorio vendor de una ejecución anterior, hay que actualizar sus dependencias después de cambiar el código y antes de ejecutar la actualización:

# Solo para el caso descrito, desde la raíz de instalación preparada.
composer install --no-dev --classmap-authoritative

Si no se utiliza Composer y no existe ese vendor, la misma guía no exige ejecutar el comando. No se copia un vendor antiguo a ciegas ni se utiliza composer update para sustituir el conjunto fijado por la versión elegida. Condición documentada.

La documentación oficial recomienda valorar una clave de actualización para proteger el inicio de la actualización por la web. Se registra su uso en la preparación sin incluir secretos en el inventario ni en las evidencias compartidas.

La raíz web debe apuntar al directorio public de la instalación preparada; las rutas de consola del núcleo permanecen fuera de él.

Ver a tamaño originalCerrar

Ejemplos de consola: rutas y PHP de la instalación

Estos ejemplos presuponen Linux, instalación convencional, usuario de servicio www-data, ejecutable PHP seleccionado y código en /srv/moodle. Deben adaptarse al ensayo. No crean las copias, no configuran el servidor y no constituyen un despliegue automático.

Sobre el código 4.5 de origen, se activa el mantenimiento antes de cambiar el código:

sudo -u www-data /usr/bin/php /srv/moodle/admin/cli/maintenance.php --enable

Después de preparar el código 5.3 de destino, los scripts del núcleo siguen en admin/cli, fuera de public:

# Consultar opciones en el código de destino antes de la ejecución acordada.
sudo -u www-data /usr/bin/php /srv/moodle/admin/cli/upgrade.php --help

# Ejecutar las migraciones; conservar y revisar la salida completa.
sudo -u www-data /usr/bin/php /srv/moodle/admin/cli/upgrade.php --non-interactive

# Después del upgrade correcto, antes de aceptar el campus.
sudo -u www-data /usr/bin/php /srv/moodle/admin/cli/purge_caches.php

El código publicado confirma la ubicación de upgrade.php en v5.3.0. La administración por consola explica su uso. Se utiliza el usuario y ejecutable del entorno; ejecutar php desde la consola no prueba que sea la misma versión configurada en la web.

Tras aceptar las pruebas y coordinar la reactivación:

sudo -u www-data /usr/bin/php /srv/moodle/admin/cli/maintenance.php --disable

El cron del núcleo debe apuntar a la ruta de la instalación, por ejemplo /srv/moodle/admin/cli/cron.php, con el PHP acordado. Conviene revisar su ejecución y las tareas ad hoc pendientes; iniciar el proceso no garantiza que todo el trabajo haya terminado. Documentación de cron.

Pruebas de aceptación: recorrer acceso, aprendizaje y gestión

El ensayo reúne resultados esperados y observados. La matriz descargable propone escenarios que deben seleccionarse y concretarse con cada campus:

Cada prueba necesita un usuario con el rol correspondiente, datos de referencia y un resultado que permita detectar el fallo. Si el campus concentra actividad en exámenes, se añade una prueba de carga representativa. Una copia reducida no acredita capacidad para una convocatoria completa.

Los recorridos se seleccionan y ensayan sobre el campus; la ilustración no recoge resultados de una ejecución.

Ver a tamaño originalCerrar

Volver atrás: restaurar un conjunto coherente

Moodle no ofrece una operación general de retorno a una versión anterior que revierta las migraciones. La recuperación debe conservar código, base de datos y moodledata del mismo estado, además de las configuraciones necesarias. Una copia de cursos no reemplaza esa copia del sitio. Copias y restauración.

El plan fija quién decide, qué incidencias activan el retorno y hasta qué momento es viable. Si ya hay entregas o matrículas posteriores a la copia, hay que resolver qué ocurrirá con ellas. Restaurar Moodle tampoco deshace un correo, una operación de pago o una matrícula enviada a otro sistema.

Se ensaya la restauración y se comparan el tiempo medido y la pérdida observada con los límites acordados. La versión previa de la base de datos y del servidor debe seguir siendo recuperable: restaurar sus datos sobre un motor distinto puede exigir otro procedimiento. Sin esa comprobación, disponer de un archivo de copia no acredita que el campus pueda volver a su estado anterior.

Incidencias habituales y criterio para detenerse

Un mensaje durante la actualización debe interpretarse con su contexto. La documentación identifica, por ejemplo, un aviso conocido sobre preguntas sin contexto; eso no permite ignorar cualquier error del banco de preguntas. Ante un fallo no explicado se conserva la salida y se decide si corregir dentro de la ventana o aplicar el procedimiento de recuperación. No se improvisa borrando tablas o desinstalando componentes con datos académicos.

Si un plugin obsoleto provoca el fallo, la documentación distingue retirar su código de desinstalarlo: retirar el código puede conservar sus datos, mientras desinstalar puede eliminarlos. Esta posibilidad se estudia y prueba en la copia aislada, con dependencias y función académica identificadas; no es una orden de borrar extensiones de producción para forzar la actualización. Comprobación oficial de plugins.

Plantillas y alcance de la intervención profesional

Los documentos de trabajo de MDL se ofrecen en PDF rellenables, con identificación del proyecto y campos para conservar responsables y evidencias. Descarga el archivo antes de completarlo y guárdalo en un lector compatible.

Están disponibles la lista de comprobaciones (PDF), el inventario de plugins (PDF), la matriz de pruebas (PDF) y el acta de aceptación y recuperación (PDF). La checklist registra 33 comprobaciones; el inventario se completa por componente; la matriz propone 20 recorridos y permite decidir qué bloquea la reapertura. El acta vincula esas evidencias con la aceptación y la recuperación. Los resultados permanecen pendientes hasta completar las comprobaciones del campus.

Si la ejecución se encarga a un proveedor, el alcance debe identificar quién prepara infraestructura, adapta extensiones, valida recorridos y decide publicar o recuperar. La oferta de servicio de actualización de Moodle de MDL Soluciones permite plantear esa intervención. La guía sigue siendo utilizable por el equipo que administra el campus, con independencia de quién ejecute el proyecto.

El siguiente paso práctico es completar el inventario y seleccionar los recorridos con el equipo académico. Esas dos piezas permiten organizar el ensayo y convertir una fecha deseada en una decisión de publicación respaldada por pruebas.

Para valorar el calendario antes de ejecutar este procedimiento, el artículo sobre las decisiones al pasar de Moodle 4.5 a 5.3 desarrolla las dependencias del alojamiento, las extensiones y el trabajo docente.