Actualizar Moodle da miedo, y con razón: un salto mal planificado puede dejar plugins rotos, temas desconfigurados o, en el peor caso, cursos inaccesibles justo antes de una convocatoria. Por eso muchos centros hacen lo contrario a lo prudente: no tocan nada durante años, hasta que la versión que usan queda tan atrás que el salto que había que dar en pequeños pasos se convierte en una migración completa, urgente y con mucho más riesgo.
En esta guía vas a ver cómo funciona realmente el ciclo de versiones de Moodle, qué reglas gobiernan el salto entre versiones LTS, y el proceso paso a paso para actualizar o migrar sin sorpresas. En Avantys llevamos años haciendo este tipo de migraciones para centros de formación, así que esto no es el manual oficial reescrito, es lo que de verdad falla cuando alguien lo intenta sin plan.
Por qué la actualización no es opcional
Moodle publica una versión LTS (Long Term Support) de forma periódica. Solo esas versiones reciben parches de seguridad durante un periodo prolongado; el resto deja de recibirlos en cuanto sale la siguiente. Seguir en una versión fuera de soporte no es “ahorrarte trabajo”: es acumular vulnerabilidades sin parche disponible, con el agravante de que muchos centros ni siquiera saben en qué fecha caducó el soporte de su versión.
| Versión | Estado | Fin de soporte |
|---|---|---|
| Moodle 3.9 LTS | Legacy | Diciembre 2023 |
| Moodle 4.1 LTS | Legacy (última con PHP 7.4) | Diciembre 2025 |
| Moodle 4.5 LTS | LTS actual | Octubre 2027 |
| Moodle 5.3 LTS | Próxima LTS | Prevista para octubre 2026 |
Si tu Moodle sigue en 4.1 o anterior, ya está fuera de la ventana de seguridad activa. El calendario completo, con cada versión y su ciclo de vida, lo mantiene Moodle en su documentación oficial de releases.
La regla que casi nadie conoce: LTS a LTS
Aquí está el punto que genera más confusión en foros de administradores de Moodle: una versión LTS siempre exige, como mínimo, la LTS anterior para poder actualizarse. Es política oficial del proyecto, documentada en su política de compatibilidad PHP y versiones soportadas, pensada precisamente para garantizar que saltar de una LTS a la siguiente sea posible sin tener que actualizar PHP a mitad de camino.
En la práctica, esto significa que no siempre puedes saltar directamente de tu versión actual a la última LTS. Si vienes de una versión anterior a 4.1, es habitual tener que pasar por una o más versiones intermedias antes de llegar a 4.5. Ignorar esta regla y forzar un salto directo es una de las causas más comunes de que una actualización de Moodle termine a medias, con el entorno de instalación bloqueado por incompatibilidades que no aparecen hasta mitad del proceso.
PHP: la pieza que más falla al actualizar
Cada versión de Moodle define un rango mínimo y máximo de versiones de PHP compatibles, y ese rango cambia con cada release. Algunos datos clave que conviene tener siempre presentes:
- Moodle 4.5 LTS requiere como mínimo PHP 8.1.0, con soporte también para PHP 8.3.x.
- Moodle 4.1 LTS fue la última versión compatible con PHP 7.4, si tu servidor sigue en PHP 7.4, tu Moodle no puede ser más reciente que 4.1.
- Desde Moodle 4.2, solo se admiten versiones de PHP de 64 bits, un PHP de 32 bits, aunque técnicamente instalado, impide directamente la actualización.
- Moodle exige también la extensión
sodiumy un valor demax_input_varsigual o superior a 5000 desde varias versiones recientes, un detalle que muchos servidores compartidos no tienen configurado por defecto.
Antes de plantear cualquier actualización, revisa el rango de PHP exacto de la versión destino en las notas de release oficiales, no en foros o guías de terceros que puedan estar desactualizadas, el rango cambia con cada versión y un dato de hace un año puede ya no ser válido.
Actualizar in situ vs migrar a un nuevo servidor
No son lo mismo, y elegir mal añade riesgo innecesario:
| Actualizar in situ | Migrar a nuevo servidor | |
|---|---|---|
| Cuándo tiene sentido | El servidor actual cumple los requisitos de la nueva versión | El servidor actual es antiguo, con recursos insuficientes o software de base obsoleto |
| Riesgo principal | Incompatibilidad de plugins o de configuración heredada | Diferencias de entorno (rutas, permisos, extensiones PHP) entre origen y destino |
| Tiempo de inactividad | Menor si todo va bien | Mayor, pero más controlable con una ventana planificada |
| Reversión si falla | Requiere restaurar backup sobre el mismo servidor | El servidor original sigue intacto como plan B mientras se valida el nuevo |
Cuando la actualización de versión coincide con la necesidad de más recursos de servidor (más alumnos concurrentes, videoconferencia integrada, más cursos) migrar a un servidor nuevo y aprovechar para actualizar a la vez suele ser más eficiente que hacerlo en dos fases separadas.
El proceso paso a paso
- Verifica tu versión actual y la ruta de actualización. Comprueba en las notas de release de la versión destino qué versiones de origen son compatibles directamente, y si necesitas pasar por versiones intermedias.
- Haz una copia de seguridad completa y verificada. No solo de la base de datos: también del código y de la carpeta
moodledata. Una copia que no se ha probado a restaurar no cuenta como copia de seguridad real. - Levanta un entorno de pruebas (staging) con una copia exacta de producción, mismo PHP, misma base de datos, mismos plugins.
- Revisa el informe de entorno de Moodle (Site administration > Server > Environment) en el staging, antes de tocar nada. Te muestra en rojo lo que bloquea la actualización y en amarillo lo que se recomienda revisar.
- Actualiza primero los plugins de terceros a su versión compatible con el Moodle destino, o desactívalos si no hay actualización disponible.
- Ejecuta la actualización en el staging, idealmente desde línea de comandos para poder revisar el log completo:
php admin/cli/upgrade.php --non-interactive- Prueba a fondo en el staging: acceso de alumnos y profesores, entrega de tareas, calificaciones, cualquier integración externa (videoconferencia, plugins de terceros).
- Planifica una ventana de mantenimiento para aplicar el mismo proceso en producción, avisando con antelación si hay alumnos con actividad programada.
- Verifica en producción los mismos puntos críticos que probaste en staging antes de dar el cambio por cerrado.
Plugins: el mayor punto de fallo real
En la práctica, la causa número uno de que una actualización de Moodle salga mal no es el núcleo, son los plugins de terceros. Un plugin que funcionaba perfectamente en la versión anterior puede:
- Dejar de estar mantenido por su desarrollador, sin versión compatible con la nueva release.
- Provocar errores de PHP silenciosos que rompen partes concretas del sitio sin que salte un error visible de inmediato.
- Necesitar una versión de PHP incompatible con la que usa el resto de la instalación.
Antes de cualquier actualización, revisa uno por uno los plugins instalados en el directorio de plugins de Moodle (moodle.org/plugins) para confirmar que existe versión compatible con la release destino. Si no la hay, la decisión es clara: o desactivas el plugin durante la actualización, o buscas una alternativa mantenida.
Checklist antes de dar el salto
| Punto | Verificado |
|---|---|
| Versión de PHP compatible con la versión destino (mínimo y máximo) | ☐ |
| PHP de 64 bits (obligatorio desde Moodle 4.2) | ☐ |
Extensión sodium instalada y max_input_vars ≥ 5000 | ☐ |
| Ruta de actualización correcta (LTS a LTS, sin saltos no soportados) | ☐ |
| Backup completo (base de datos + código + moodledata) verificado con restauración de prueba | ☐ |
| Todos los plugins de terceros con versión compatible confirmada | ☐ |
| Entorno de pruebas (staging) validado antes de tocar producción | ☐ |
| Ventana de mantenimiento comunicada a profesores y alumnos | ☐ |
Errores comunes al actualizar o migrar Moodle
- Saltar directamente varias versiones LTS sin pasar por las intermedias que exige la política de compatibilidad.
- Actualizar plugins después del núcleo, en vez de antes, el orden importa, y hacerlo al revés multiplica el riesgo de incompatibilidad.
- No probar la restauración del backup antes de empezar, confiando en que “seguro que funciona”.
- Ignorar los avisos amarillos del informe de entorno de Moodle, asumiendo que solo los rojos son bloqueantes, muchos amarillos se convierten en problemas reales tras la actualización.
- Hacerlo directamente en producción sin staging, por falta de tiempo, es la forma más rápida de convertir una actualización de una tarde en una incidencia de varios días.
Preguntas frecuentes
¿Puedo saltar directamente de Moodle 3.9 a 4.5? No de forma directa en la mayoría de los casos: la política de versiones exige pasar por la LTS anterior, así que probablemente necesites una o más versiones intermedias antes de llegar a 4.5.
¿Qué pasa si mi servidor tiene PHP 7.4? No podrás actualizar más allá de Moodle 4.1, que fue la última versión compatible con esa versión de PHP. Necesitarás actualizar PHP antes de poder avanzar de versión de Moodle.
¿Cuánto dura una ventana de mantenimiento típica para actualizar Moodle? Depende del volumen de cursos y plugins, pero conviene planificarla fuera de horario lectivo y con margen suficiente para revertir si algo falla, no ajustada al mínimo.
¿Necesito staging obligatoriamente? No es obligatorio técnicamente, pero es la diferencia entre detectar un problema de plugin antes de que afecte a un alumno real, o después.
¿Qué es el informe de entorno de Moodle? Una pantalla (Site administration > Server > Environment) que compara tu servidor actual contra los requisitos de la versión que quieres instalar, marcando en rojo lo que bloquea la actualización y en amarillo lo recomendado.
¿Puedo actualizar los plugins automáticamente? Moodle permite actualizar plugins compatibles desde el propio panel de administración, pero conviene hacerlo primero en staging para detectar incompatibilidades antes de tocar producción.
¿Perderé las calificaciones o los cursos al actualizar? No, si el proceso se hace correctamente y con backup verificado. Las pérdidas de datos suelen venir de saltos de versión no soportados o de fallos a mitad de proceso sin plan de reversión.
¿Migrar a un nuevo servidor es más arriesgado que actualizar en el mismo? Tiene un tipo de riesgo distinto: diferencias de entorno entre origen y destino, pero con la ventaja de que el servidor original queda intacto como plan de contingencia mientras validas el nuevo.
¿Con qué frecuencia debería revisar si mi versión sigue soportada? Al menos una vez al año, y siempre antes de instalar plugins nuevos, instalar sobre una versión ya fuera de soporte solo añade más deuda técnica a lo que tarde o temprano habrá que migrar.
¿Qué pasa si un plugin crítico no tiene versión compatible con la nueva release? Tienes que decidir entre mantenerte en la versión actual (asumiendo el riesgo de seguridad), buscar una alternativa mantenida, o encargar el desarrollo de una versión compatible si el plugin es imprescindible para tu operación.
Conclusión
Actualizar Moodle no es complicado si se hace en el orden correcto, la mayoría de los desastres que vemos vienen de saltarse pasos, no de la dificultad técnica en sí. Backup verificado, staging real, plugins revisados uno a uno, y respetar la ruta LTS a LTS: con eso resuelto, el salto de versión deja de ser un riesgo y se convierte en un procedimiento más.
Si prefieres no estar pendiente de calendarios de soporte, compatibilidad de PHP y plugins cada vez que toca actualizar, en Avantys planificamos y ejecutamos estas migraciones de forma recurrente para centros de formación. Puedes pedir una auditoría gratuita de tu versión actual en Moodle Gestionado.
Artículos relacionados
- Cómo actualizar Moodle 3.x a 4.5 LTS paso a paso
- Qué es Moodle LTS y cuándo debes actualizar
- Migrar Moodle a un nuevo servidor sin perder cursos
- Actualizar PHP en Moodle sin romper plugins
- Cómo crear un entorno de pruebas (staging) de Moodle
- Plugins de Moodle incompatibles: cómo detectarlos antes de actualizar
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
