Una actualización de Moodle no debería sentirse como un salto al vacío. Con la preparación correcta, el tiempo de inactividad real se reduce a una ventana corta y controlada, en vez de convertirse en una tarde entera con la plataforma caída y profesores preguntando qué está pasando.
Esta guía reúne, en una sola checklist ordenada, todo lo que hay que tener resuelto antes, durante y después de una actualización, la referencia rápida para no dejarte nada en el camino. Es el resumen operativo del proceso completo que explicamos en migración y actualización de Moodle; aquí lo condensamos en acciones que puedes ir tachando.
Antes de la actualización
| Punto | Verificado |
|---|---|
| Versión actual confirmada con precisión (Site administration > Server > Environment) | ☐ |
| Ruta de versiones intermedias identificada, si aplica | ☐ |
Backup completo: código, moodledata y volcado de base de datos | ☐ |
| Backup verificado con una restauración de prueba real | ☐ |
| Entorno de staging montado con copia real de datos | ☐ |
Correo bloqueado en staging ($CFG->noemailever = true) | ☐ |
| Inventario completo de plugins de terceros | ☐ |
| Cada plugin revisado contra la versión destino en el directorio oficial | ☐ |
| Versión de PHP y extensiones necesarias confirmadas para la versión destino | ☐ |
| Informe de entorno de Moodle revisado en staging (rojos y amarillos) | ☐ |
| Ventana de mantenimiento definida y comunicada con antelación | ☐ |
Este bloque es el que de verdad decide cuánto durará el downtime, así que merece la mitad del esfuerzo total. Dos puntos concentran casi todos los sustos.
Un backup solo cuenta si lo has restaurado. Hacer el volcado de la base de datos, comprimir moodledata y copiar el código está bien, pero un backup que nunca se ha restaurado es una hipótesis, no una red de seguridad. Antes de tocar producción, levanta ese backup en otra máquina o en tu entorno de staging y comprueba que el sitio arranca y que puedes entrar. Es el único momento en que descubrir que el volcado estaba corrupto no te cuesta un disgusto.
El staging tiene que ser una copia real, no una instalación limpia. Un Moodle vacío no reproduce los plugins de terceros, los formatos de curso raros ni el volumen de datos que hace que un upgrade tarde veinte minutos en vez de dos. Clona código, base de datos y moodledata del sitio en producción, y acuérdate de cortar el correo saliente con $CFG->noemailever = true para que las pruebas no disparen notificaciones a alumnos reales.
Con la copia lista, ejecuta el informe de entorno en staging (Administración del sitio > Servidor > Comprobaciones del entorno) y revisa cada línea en rojo o ámbar: versión de PHP, extensiones obligatorias, límites de configuración. Resolver un requisito de PHP aquí es cuestión de minutos; descubrirlo a mitad de la ventana de mantenimiento es un downtime que no habías contado. En paralelo, coteja cada plugin de terceros contra la versión destino en el directorio oficial de Moodle: un plugin sin versión compatible es una decisión que quieres tomar antes de empezar, no un bloqueo con el sitio ya cerrado.
Durante la actualización
| Punto | Verificado |
|---|---|
| Modo mantenimiento activado antes de empezar | ☐ |
| Confirmación de que no hay procesos de cron en ejecución | ☐ |
| Actualización ejecutada preferiblemente por línea de comandos | ☐ |
| Log de la actualización guardado para revisión posterior | ☐ |
| Cada versión intermedia verificada antes de continuar con la siguiente | ☐ |
El objetivo de esta fase es que sea aburrida: ejecutar un proceso ya ensayado en staging, no investigar sobre la marcha. Lo primero, antes de nada, es poner el sitio en modo mantenimiento para que nadie escriba datos mientras se actualiza el esquema de la base de datos. Puedes hacerlo desde la interfaz (Administración del sitio > Servidor > Modo de mantenimiento) o, mejor, por línea de comandos, que es también como conviene lanzar el propio upgrade en cualquier sitio con volumen:
# 1. Cerrar el sitio a los usuarios
php admin/cli/maintenance.php --enable
# 2. Ejecutar la actualización sin prompts interactivos
php admin/cli/upgrade.php --non-interactive
# 3. Purgar todas las cachés tras el upgrade
php admin/cli/purge_caches.phpNo desactives todavía el modo mantenimiento: eso es lo último, y solo cuando hayas verificado que todo funciona. Ejecutar por CLI evita el riesgo de timeout del navegador en sitios grandes y deja un log limpio que puedes guardar para revisión posterior. Si vienes de una versión antigua y hay varios saltos intermedios en la ruta, aplica y verifica cada uno antes de encadenar el siguiente: mezclar dos upgrades sin comprobar el primero convierte cualquier fallo en una investigación a ciegas.
| Aspecto | Línea de comandos | Interfaz web |
|---|---|---|
| Riesgo de timeout en sitios grandes | Bajo, sin el límite de tiempo de PHP web | Alto: puede cortarse a mitad del proceso |
| Repetible igual en staging y producción | Sí, el mismo script ensayado | Manual, clic a clic cada vez |
| Registro del proceso | Log completo, fácil de guardar | Difícil de capturar entero |
| Requiere acceso SSH al servidor | Sí | No, basta el navegador |
| Encaja mejor en | Sitios con volumen y muchos plugins | Instalaciones pequeñas sin acceso SSH |
Después de la actualización
| Punto | Verificado |
|---|---|
| Acceso de alumnos y profesores probado activamente | ☐ |
| Entrega de tareas y calificaciones comprobada | ☐ |
| Integraciones externas (videoconferencia, pagos, webservices) verificadas | ☐ |
| Plugins de terceros probados uno a uno, no solo la navegación general | ☐ |
| Cron reactivado y confirmado en ejecución | ☐ |
| Modo mantenimiento desactivado | ☐ |
| Monitorización activa durante las primeras 24-48 horas tras el cambio | ☐ |
Con el upgrade aplicado y las cachés limpias, el sitio sigue cerrado, y ese es exactamente el momento de verificar sobre el propio Moodle actualizado (aún en mantenimiento, entrando como administrador) antes de abrir la puerta. Haz login, entra en un par de cursos reales, comprueba que una entrega de tarea y su calificación se ven bien, y prueba las integraciones críticas: videoconferencia, pasarela de pago, webservices. Repasa los plugins de terceros uno a uno; la navegación general puede ir fina y aun así haber un plugin roto que nadie note hasta que un profesor lo use en clase.
Solo cuando todo eso está en verde, reabres el sitio:
php admin/cli/maintenance.php --disableConfirma también que el cron vuelve a ejecutarse (puedes lanzar php admin/cli/cron.php como prueba puntual y verificar que la tarea programada del sistema sigue activa). Un cron parado no se nota en el momento: se nota días después, cuando dejan de salir los correos de notificación y las colas de tareas se quedan sin procesar. Por eso la monitorización de las primeras 24-48 horas no es paranoia, sino la forma de cazar los fallos silenciosos que no aparecen en la primera comprobación.
Estrategias concretas para minimizar el tiempo de inactividad real
Planifica fuera de horario lectivo
Parece obvio, pero es el punto que más se salta cuando hay presión de tiempo. Una actualización ejecutada un domingo por la madrugada, incluso si algo sale mal y hay que dedicar horas extra a resolverlo, tiene un impacto real en los usuarios mucho menor que la misma incidencia en horario de clase.
Separa la validación de la ejecución
El tiempo que de verdad importa minimizar es el de producción con el sitio en mantenimiento, no el tiempo total del proyecto. Si la validación completa (plugins, integraciones, rendimiento) se hace en staging con tiempo suficiente, la ventana en producción se reduce a ejecutar un proceso ya probado, no a descubrir problemas sobre la marcha.
Comunica la ventana con antelación, no el mismo día
Avisar a profesores y alumnos con varios días de margen reduce las consultas de soporte durante la ventana de mantenimiento y evita que alguien programe un examen o entrega justo en ese periodo sin saberlo.
Ten un plan de reversión definido antes de empezar
Si algo falla a mitad de la actualización, ¿cuánto tiempo tienes antes de que sea más rápido restaurar el backup que seguir intentando resolver el problema en caliente? Definir ese límite antes de empezar evita decisiones de pánico durante la ventana de mantenimiento. Y “revertir” tiene que ser un procedimiento escrito, no una improvisación: restaurar el código, el volcado de base de datos y moodledata del backup (los tres a la vez, del mismo momento) y purgar cachés al terminar. Restaurar solo la base de datos y dejar el código nuevo, o al revés, deja el sitio en un estado incoherente que cuesta más de arreglar que la propia incidencia.
Errores que alargan el downtime más de lo necesario
- Empezar la actualización sin haber definido un límite de tiempo para decidir revertir.
- Descubrir un problema de plugin durante la ventana de producción que se podría haber detectado antes en staging.
- No tener a mano el backup ya listo para restaurar, perdiendo tiempo en generarlo a mitad de la incidencia.
- Ejecutar la actualización desde el navegador en un sitio grande, con mayor riesgo de timeout que por línea de comandos.
- No comunicar la ventana con antelación, generando un volumen de consultas de soporte que consume tiempo que debería dedicarse a la actualización en sí.
Preguntas frecuentes
¿Es posible actualizar Moodle con cero tiempo de inactividad? En la práctica, siempre hay una ventana mínima (aunque sea de minutos) en la que el sitio está en modo mantenimiento durante la ejecución. Lo que sí es posible es reducirla al mínimo con una preparación completa previa en staging.
¿Cuánto debería durar la ventana de mantenimiento? Depende del volumen de cursos y de si hay varias versiones intermedias que aplicar, pero conviene calcularla con margen respecto al tiempo que tardó la misma actualización en staging, no ajustarla al mínimo posible.
¿Qué pasa si la actualización falla a mitad de proceso?
Si tienes definido de antemano el punto en el que decides revertir, restauras el backup completo (código, base de datos y moodledata) y vuelves al estado anterior, en vez de intentar resolver el problema sobre la marcha sin límite de tiempo.
¿Debo avisar a los alumnos de la ventana de mantenimiento? Sí, con antelación suficiente para que nadie programe una entrega, examen o sesión de videoconferencia durante ese periodo.
¿Puedo hacer la actualización en varias ventanas separadas si tengo varias versiones intermedias? Es una opción válida si el tiempo total es difícil de concentrar en una sola ventana, aunque conlleva coordinar varias comunicaciones a los usuarios en vez de una sola.
¿Qué debo monitorizar justo después de la actualización? Acceso general, entrega de tareas, integraciones externas y, muy especialmente, el correcto funcionamiento del cron, un fallo silencioso en el cron no se nota hasta días después.
¿Puedo actualizar por la interfaz web o tengo que usar la línea de comandos? Ambas actualizan igual el esquema de la base de datos. La diferencia es el riesgo: en un sitio grande, el navegador puede alcanzar el límite de tiempo de PHP y cortarse a mitad del proceso, mientras que la CLI no tiene ese techo y deja un log limpio. Para instalaciones pequeñas sin acceso SSH, la interfaz web es perfectamente válida; en cuanto hay volumen y plugins, la línea de comandos es la opción segura.
¿Hace falta activar el modo mantenimiento si la actualización tarda solo unos minutos? Sí, siempre. El modo mantenimiento no está por la duración, sino para impedir que un usuario escriba datos mientras el esquema de la base de datos se está modificando. Una entrega de tarea a medio guardar durante el upgrade puede dejar registros inconsistentes, y eso no depende de que la ventana dure dos minutos o veinte.
¿Por qué hay que purgar las cachés después de actualizar?
Moodle cachea definiciones de idioma, plugins, temas y estructura de la base de datos. Tras un upgrade, esas cachés apuntan a la versión anterior y provocan errores raros (bloques que no cargan, cadenas de idioma desaparecidas) que se confunden con un fallo de la actualización cuando en realidad es caché vieja. Purgarlas con admin/cli/purge_caches.php antes de verificar te ahorra perseguir fantasmas.
¿La checklist cambia si combino actualización con migración de servidor? Sí, se añaden puntos específicos de migración (DNS, permisos de archivo, configuración de servidor nuevo) que no aplican a una actualización en el mismo servidor. Lo cubrimos en migrar Moodle a un nuevo servidor sin perder cursos.
Conclusión
El tiempo de inactividad real de una actualización de Moodle depende casi por completo de cuánto trabajo se hizo antes de tocar producción. Con staging validado, plugins revisados y un plan de reversión claro, la ventana en vivo se convierte en la ejecución de un proceso ya probado, no en una investigación en tiempo real con profesores esperando.
Si prefieres que alguien lleve esta checklist por ti en cada actualización, en Avantys la aplicamos de forma sistemática en cada migración que gestionamos para centros de formación. Puedes pedir una auditoría gratuita de tu Moodle actual en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Cómo actualizar Moodle 3.x a 4.5 LTS paso a paso
- Cómo crear un entorno de pruebas (staging) de Moodle
- Backup y restauración completa de un curso de Moodle
- Migrar Moodle a un nuevo servidor sin perder cursos
¿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.
