De Moodle 4.5 a 5.3: las decisiones antes de actualizar

Moodle 5.3 LTS se publicó el 5 de octubre de 2026. Para quien mantiene un campus en 4.5, la nueva versión plantea una decisión que va más allá de estrenar interfaz: hay que preparar el servidor, revisar extensiones y entender qué va a cambiar para docentes y estudiantes.

Las notas oficiales de 5.3 permiten actualizar desde 4.4 o posterior. Por tanto, el salto desde 4.5 está admitido sin instalar sucesivamente 5.0, 5.1 y 5.2. Al leer esa condición conviene detenerse: aunque se omitan esas instalaciones, el campus recibirá sus cambios.

Ese es el punto que considero más relevante para preparar la actualización. En una instalación nueva se eligen componentes para la versión de destino. En un campus que lleva tiempo funcionando hay cursos, permisos, integraciones y decisiones anteriores que deben seguir teniendo sentido después del cambio.

El servidor también entra en la decisión

Una instalación de 4.5 puede tener un entorno perfectamente válido para esa rama y necesitar cambios para ejecutar 5.3. Los nuevos mínimos incluyen PHP 8.3 de 64 bits, PostgreSQL 17 o MariaDB 11.4, según el motor utilizado. Si varias aplicaciones comparten servidor, actualizar PHP o la base de datos exige comprobar qué necesitan las demás.

A esto se suma la reorganización introducida en Moodle 5.1: el servidor web debe apuntar al directorio public, donde quedan también las extensiones y los scripts de consola. El archivo config.php permanece fuera de esa raíz pública. Un despliegue que cambia el código y conserva las rutas anteriores puede dejar mal configurado el acceso web o las tareas programadas.

Por eso, estimar la intervención únicamente por el tiempo que tarda Moodle en transformar sus tablas deja parte del trabajo fuera. Puede ser necesario preparar otro entorno, coordinar el cambio con quien administra el alojamiento y comprobar las automatizaciones que seguirán ejecutándose después. La duración de ese trabajo depende de cómo se haya construido y mantenido la instalación.

Lo que cambia para quien prepara un examen

Las novedades de evaluación merecen una lectura más detenida que una lista de funcionalidades. Moodle 5.0 incorporó bancos de preguntas compartidos y cambios en los cuestionarios. Al llegar desde 4.5, interesa comprobar quién puede acceder a las preguntas, qué ocurre con los tipos aportados por plugins y cómo se consultan los intentos y sus calificaciones.

Pensemos en un cuestionario que utiliza un tipo de pregunta de terceros. Que el docente abra el curso después de actualizar apenas comprueba el acceso. Para aceptar ese recorrido hace falta que pueda preparar el examen, que el estudiante complete el intento y que ambos consulten el resultado con los permisos esperados. Si además se exportan notas a otro sistema, el recorrido continúa fuera de Moodle. Es un ejemplo para elegir pruebas, no el relato de una incidencia concreta.

Los cambios de interfaz también afectan a usos anteriores. En 5.3, Classic sale del núcleo y se retira el bloque Activities. Las descripciones de subsecciones quedan ocultas hasta decidir si se migran a actividades de texto y medios o se eliminan. La documentación de actualización explica la retirada del bloque y el tratamiento de las subsecciones. Un curso puede conservar sus actividades y, aun así, requerir cambios para que el alumnado encuentre instrucciones o accesos que utilizaba antes.

La decisión sobre ese contenido debe contar con quienes lo preparan. La administración técnica puede ejecutar una migración, pero necesita saber qué función cumplía el texto antes de elegir su destino o eliminarlo. Incluir al profesorado en el ensayo permite identificar esos usos y preparar la comunicación del cambio.

Aplazar puede ser razonable si se utiliza el tiempo para preparar

El calendario de Moodle mantiene las correcciones de seguridad de 4.5 hasta el 4 de octubre de 2027. Su soporte general ya terminó, pero eso no significa que la rama haya dejado de recibir parches de seguridad. Hay margen para organizar el salto sin convertir la fecha de lanzamiento en una urgencia universal.

Ese margen sirve para resolver dependencias. Si una extensión imprescindible carece de versión compatible, esperar por sí solo no permite saber cuándo estará disponible. Hace falta revisar su mantenimiento y decidir si se adapta, se sustituye o se conserva temporalmente la instalación actual. Desinstalarla para superar una comprobación técnica puede comprometer datos y actividades que el campus necesita.

También puede ser razonable esperar a un parche concreto por una incidencia conocida. Lo que no permite ese calendario es dar por probada una combinación de plugins o un tema propio. La versión exacta de producción debe elegirse con las incidencias relevantes y los resultados del ensayo, manteniendo mientras tanto los parches de la rama instalada.

Un ensayo que permita decidir cuándo detenerse

Para comprobar una actualización desde 4.5 hace falta una copia de esa instalación con los datos, extensiones y configuraciones relevantes. Un Moodle 5.3 recién instalado permite conocer la versión; no reproduce lo que ocurrirá al transformar un campus existente.

La copia requiere además aislar sus efectos externos. Si envía correos, comunica matrículas o activa pagos contra servicios reales, el ensayo puede producir operaciones que después habrá que resolver. La selección de datos, accesos e integraciones forma parte de su preparación.

En el artículo sobre compatibilidad, pruebas y vuelta atrás propongo relacionar cada requisito con un recorrido y con la evidencia que permite aceptarlo. Para el salto a 5.3, esa relación debe incorporar los cambios acumulados de las ramas intermedias. Así se puede distinguir entre un detalle que admite seguimiento posterior y una incidencia que impide reabrir el campus.

La recuperación condiciona esa decisión. Si el alumnado ha realizado entregas después de hacer la copia que se conserva, restaurarla puede recuperar el servicio y dejar fuera ese trabajo. Además, volver al estado anterior de Moodle no deshace una matrícula enviada a otro sistema. La documentación de restauración permite preparar la recuperación del sitio; el tratamiento de operaciones posteriores debe acordarse para cada instalación.

Mi criterio para fijar la ventana es que las dependencias críticas estén resueltas y que quienes deben aceptar el cambio puedan comprobar qué se ha probado y con qué resultado. Con ello se puede estimar la interrupción, explicar las diferencias al profesorado y decidir cómo responder ante un fallo. Si esas comprobaciones están pendientes, todavía falta información para comprometer una fecha.

He reunido el procedimiento, los requisitos completos, los ejemplos de consola y las plantillas en la guía de Moodle 4.5 a 5.3 de MDL Soluciones. Aquí me interesa la decisión previa: aprovechar la nueva LTS exige preparar la continuidad del campus que ya existe. Elegir Moodle 5.3 como destino es el comienzo; la versión concreta y la fecha de producción deben sostenerse con el ensayo.

Fuentes consultadas el 13 de octubre de 2026. Este análisis se refiere a Moodle LMS y no documenta una actualización ejecutada en un campus de cliente. La portada es una representación conceptual de revisiones pendientes.