MAQ Módulo 3 – Actualización: la deuda técnica que nadie quiere pagar
Hay una conversación que todo administrador de Moodle ha tenido al menos una vez. Alguien del equipo directivo pregunta: “¿Es necesario actualizar si todo funciona bien?”. La respuesta correcta es sí, pero la respuesta real — la que da lugar a una política de actualizaciones sostenible — es mucho más matizada.
Este post cubre la competencia 2.2 Actualización del módulo de Mantenimiento y Soporte del MAQ: cómo implementar una política acordada de actualizaciones periódicas.
Por qué actualizar (aunque todo “funcione”)
El escepticismo ante las actualizaciones es comprensible. Actualizar implica tiempo de inactividad, riesgo de incompatibilidades y el esfuerzo de comunicar cambios a los usuarios. Si el sitio responde, los cursos funcionan y nadie se queja, ¿para qué tocar algo que no está roto?
El MAQ da dos razones fundamentales:
Las actualizaciones incluyen correcciones de seguridad. No son opcionales desde el punto de vista de la responsabilidad del administrador. Un sitio desactualizado es un sitio con vulnerabilidades conocidas y públicamente documentadas. Los atacantes leen los changelogs igual que nosotros.
PHP y los navegadores también se deprecan. Moodle no existe en el vacío. Cuando una versión de PHP llega al fin de su soporte oficial, las vulnerabilidades que se descubran a partir de ese momento no se parchearán. Seguir con PHP 7.4 en 2025 no es “estabilidad” — es exposición.
El caso de estudio del MAQ lo ilustra bien: Amir llega a una empresa y encuentra Moodle 3.9, una versión que dejó de recibir soporte de seguridad hace años. La empresa creía que era una LTS intocable. No lo era, o al menos no de la forma en que lo entendían.
El calendario de versiones de Moodle
Entender el ciclo de versiones es imprescindible para diseñar una política de actualizaciones.
Versiones menores — se publican cada dos meses (febrero, abril, junio, agosto, octubre, diciembre). Son las versiones “de punto”: 4.5.1, 4.5.2, 4.5.3. No introducen nuevas funcionalidades significativas, pero incluyen correcciones de errores y parches de seguridad. La recomendación del MAQ es aplicarlas siempre, especialmente si algún error conocido afecta a tu sitio o si hay un aviso de seguridad activo.
Versiones principales — cada seis meses, en abril y octubre. Son las que introducen nuevas funcionalidades. Muchas organizaciones académicas aprovechan los periodos vacacionales (verano o invierno) para realizar estas actualizaciones.
Versiones LTS — con Soporte a Largo Plazo. Reciben correcciones de seguridad durante más tiempo que las versiones normales. La versión LTS actual es Moodle 4.5. Para organizaciones que prefieren actualizar con menor frecuencia, las LTS son el mínimo recomendado.
El nuevo esquema de versiones desde Moodle 4.5
A partir de Moodle 4.5, Moodle HQ clarificó el sistema de versionado y obsolescencia. Vale la pena entenderlo bien porque tiene implicaciones directas en la planificación:
Series de versiones: la última versión de cada serie es siempre una LTS. La serie 4.x termina en 4.5 LTS. La serie 5.x terminará en 5.3 LTS. Después vendrá la serie 6.x.
Obsolescencia alineada con LTS: las funcionalidades declaradas obsoletas antes de una versión LTS se eliminarán en la versión siguiente. El período mínimo de obsolescencia es de 12 meses. Esto significa que si tienes código personalizado o integraciones que dependen de APIs de Moodle, tienes al menos un ciclo LTS para adaptarlos antes de que desaparezcan.
En la práctica: las funciones deprecadas en 4.3 o 4.4 desaparecieron en 5.0. Si tienes desarrollos propios, revisar las notas de deprecación antes de cada actualización mayor es obligatorio.
Antes de actualizar: la lista que no debes saltar
El MAQ es explícito en este punto. Antes de tocar el sitio de producción:
Verifica los requisitos del servidor en Administración del sitio > Servidor > Entorno. Cada versión mayor de Moodle puede requerir una versión más nueva de PHP, una versión mínima de PostgreSQL o MySQL, o librerías adicionales. Aprenderlo en producción el día de la actualización no es una opción.
Ten un sitio de pruebas. El MAQ lo dice con contundencia: realmente deberías tener uno. Y no cualquier entorno vacío — debe ser un clon del sitio de producción con datos reales anonimizados. Una actualización que funciona en un Moodle vacío puede fallar en uno con 800.000 usuarios, plugins personalizados y años de datos acumulados.
Revisa la compatibilidad de plugins. Un plugin que no especifica compatibilidad con la versión destino no es automáticamente incompatible, pero sí es una incógnita que hay que resolver en el entorno de pruebas antes de arriesgarse en producción.
Considera el tema visual. Si usas un tema personalizado, pruébalo en el sitio actualizado iniciando sesión como estudiante y como docente. Los cambios en el HTML de Moodle entre versiones mayores pueden romper selectores CSS de temas no mantenidos.
Prepara la comunicación. ¿El equipo docente sabe qué va a cambiar? Una actualización que mejora el LMS pero que nadie esperaba genera resistencia innecesaria.
La política de actualización: no es solo un calendario
El MAQ distingue entre tener un calendario de actualizaciones y tener una política. La diferencia es importante.
Una política implica acordar con las partes interesadas — equipo directivo, docentes, estudiantes, TI — no solo cuándo se actualiza, sino cómo:
- ¿Con cuánta antelación se avisa del tiempo de inactividad?
- ¿Quién redacta el mensaje de mantenimiento en Administración del sitio > Servidor > Modo de mantenimiento?
- ¿Hay un canal específico para reportar problemas tras la actualización?
- ¿El equipo docente tiene acceso previo al entorno de pruebas para familiarizarse con las novedades?
En mi experiencia, la parte técnica de una actualización es la más fácil. Lo complicado es la gestión del cambio: que la Directora de formación sepa explicar las nuevas funcionalidades, que los docentes no lleguen el lunes siguiente sin haber sido informados, que haya alguien disponible para responder incidencias las primeras 48 horas post-actualización.
Git + CLI: el método que escala
Para el MAQ no hace falta describir el proceso paso a paso — es un programa de certificación, no de formación. Pero sí menciona que para organizaciones grandes, la combinación de Git checkout con la CLI de Moodle es el método preferido.
Tiene sentido. Con Git, el proceso de actualización se reduce a cambiar de rama o etiqueta, lo que hace que el historial de cambios sea rastreable y el rollback sea limpio. La CLI permite ejecutar la actualización sin pasar por la interfaz web, evitando timeouts y permitiendo automatización. En un entorno con varios servidores web detrás de un balanceador, ejecutar el upgrade desde CLI en un nodo controlado es mucho más predecible que hacerlo desde el navegador.
Mi reflexión personal
Amir, el administrador del caso de estudio del MAQ, hizo algo que me parece modélico: antes de tocar nada técnico, sentó a la Directora de formación con los cursos “¿Qué hay de nuevo en…?” de Moodle Academy. La actualización no es solo un evento de infraestructura — es un evento organizacional.
En sitios grandes, con cientos de docentes y miles de estudiantes, el impacto de una actualización va mucho más allá del tiempo de inactividad. La resistencia al cambio, la confusión ante una interfaz nueva, las preguntas al equipo de soporte — todo eso tiene un coste real que no aparece en el downtime pero que sí afecta a la percepción del servicio.
Una buena política de actualizaciones hace que ese coste sea predecible y gestionable. Y eso, al final, es de lo que trata esta competencia del MAQ.
Este post forma parte de mi serie de apuntes para el examen de certificación MAQ. Si también estás preparándote, espero que te sea útil.
← MAQ Módulo 3 – Rendimiento | MAQ Módulo 3 – Fin de año y transferencia →
