MAQ Módulo 3 – Fin de año: qué hacer con los cursos cuando termina el ciclo

Cada final de curso académico trae la misma pregunta: ¿qué hacemos con todo esto? Con los cursos del año anterior, con los estudiantes que ya terminaron su programa, con los profesores que van a repetir la misma asignatura pero con alumnos nuevos. Es una de esas decisiones que no parecen urgentes hasta que de repente lo son — generalmente a mediados de septiembre cuando alguien pregunta por qué los nuevos estudiantes todavía ven las notas del año pasado.

La competencia 2.3 Fin de año / Renovación del MAQ aborda exactamente esto: cómo incorporar copias de seguridad y reinicios periódicos de acuerdo con los requisitos institucionales.

¿A quién afecta esto?

El MAQ hace una distinción importante al inicio de este módulo. Si administras un Moodle académico — escuela, universidad, formación profesional — con cohortes de estudiantes que rotan cada semestre o año, este proceso es crítico. Si tu Moodle es principalmente formación continua a ritmo propio sin ciclos académicos definidos, las estrategias son menos urgentes, aunque las prácticas de backup siguen siendo relevantes.

En mi caso, gestionando entornos con cientos de miles de usuarios, la renovación anual no es un evento puntual sino un proceso que requiere planificación con meses de antelación. ¿Quién da de baja a quién? ¿Cuándo? ¿Quién lo comunica?

Las preguntas que hay que responder antes de actuar

El MAQ propone un conjunto de preguntas que deberían acordarse con las partes implicadas antes de tocar nada:

¿Los estudiantes que terminan un ciclo se dan de baja de sus cursos o simplemente se matriculan en los nuevos? ¿Quién gestiona las matrículas — el administrador o los docentes? ¿Qué ocurre con los estudiantes que completan un programa entero y ya no van a usar el sitio? ¿Cómo se les retira el acceso preservando sus datos y durante cuánto tiempo?

Esta última pregunta conecta directamente con el RGPD: los datos de un estudiante que terminó hace tres años no pueden conservarse indefinidamente sin base legal. La política de fin de año es también, en parte, una política de retención de datos.

Y la pregunta práctica que más se suele ignorar: ¿quién hace todo esto si tú, el administrador, estás de vacaciones?

Tres estrategias, cada una con su contexto

El MAQ describe tres enfoques. Ninguno es universalmente el mejor — el adecuado depende del tamaño del sitio, la autonomía de los docentes y los recursos disponibles.

Estrategia 1: Copia de seguridad y reinicio

La más clásica. Al final del ciclo, se hace una copia de seguridad del curso con los datos de los usuarios — calificaciones, entregas, participación — y se almacena en un disco externo o en una categoría oculta de “Archivo” dentro del propio Moodle. Luego el curso se reinicia para el nuevo grupo.

La ventaja es que el curso ya existe y está listo, con toda su estructura. El docente puede modificarlo sin partir de cero. El inconveniente es que si tienes cientos de cursos, hacerlo uno a uno es inasumible sin automatización. Y la categoría de archivo crece con el tiempo: múltiples copias del mismo curso de años sucesivos ocupan espacio y generan confusión.

Estrategia 2: Nuevos cursos cada ciclo

En lugar de reiniciar el existente, se crea un curso nuevo vacío — o copiado del anterior sin datos de usuarios — y se asignan los docentes. Los cursos anteriores se mantienen accesibles, lo que los estudiantes suelen agradecer porque pueden seguir consultando materiales de años pasados.

Es el enfoque que Gideon, el administrador del caso de estudio del MAQ, utiliza en su instituto. Crea copias de los cursos con una nomenclatura acordada, mantiene las matrículas antiguas para que los estudiantes puedan seguir accediendo, y ha configurado la congelación de contexto para que los docentes puedan marcar sus cursos anteriores como de solo lectura. Los nuevos estudiantes se matriculan mediante CSV unos días antes del inicio del nuevo año.

La congelación de contexto es una funcionalidad que vale la pena conocer para el MAQ: permite que un curso pase a modo de solo lectura sin eliminarlo ni ocultarlo. Los estudiantes pueden seguir consultando su historial, pero nadie puede modificar el contenido ni añadir entregas nuevas.

Estrategia 3: Nuevo sitio

La más drástica. Cada ciclo académico genera una nueva instancia de Moodle. El sitio anterior se archiva — idealmente en modo solo lectura — y el nuevo parte limpio.

Tiene su lógica en contextos muy específicos: organizaciones donde la separación de cohortes es un requisito legal o de privacidad, o donde la deuda técnica del sitio antiguo es tan grande que renovarlo es más costoso que empezar de cero.

Los inconvenientes son evidentes: como administrador pasas a gestionar varios sitios en paralelo, cada uno con sus propias actualizaciones de seguridad, sus propias solicitudes de datos RGPD y sus propios backups. La carga administrativa se multiplica. Y los docentes tienen que migrar sus cursos manualmente entre instancias cada año, a menos que se automatice el proceso.

Lo que suele fallar en la práctica

En mi experiencia, el problema no suele ser técnico. Las herramientas de Moodle para gestionar el fin de año son maduras y están bien documentadas. El problema es de coordinación.

¿Quién decide cuándo empieza el proceso? ¿El administrador actúa solo o espera instrucciones de Secretaría? ¿Los docentes saben que sus cursos van a reiniciarse y han descargado lo que necesitan conservar? ¿Se ha comunicado a los estudiantes que perderán acceso a sus entregas del año anterior?

La documentación de Moodle tiene páginas específicas sobre procedimientos de fin de año que el MAQ referencia directamente. No están ahí por casualidad — son el resultado de que muchos administradores hayan aprendido estas lecciones de la forma difícil.

Mi reflexión personal

Lo que más me ha enseñado gestionar ciclos de renovación en entornos grandes es que la decisión técnica sobre qué estrategia usar es secundaria respecto a la decisión organizativa sobre quién es responsable de qué.

Un proceso de fin de año bien definido — con fechas, responsables, comunicaciones planificadas y un checklist que no dependa de que yo esté disponible — vale más que cualquier automatización técnica. La automatización ayuda cuando ya sabes exactamente qué tienes que automatizar. Antes de llegar ahí, necesitas el proceso.

El siguiente post del módulo cierra el bloque de Mantenimiento y Soporte con las estructuras de apoyo a usuarios — la parte del trabajo que más se nota cuando falla y menos cuando funciona bien.

---

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 – Actualización | MAQ Módulo 3 – Estructuras de soporte →

Diario: gestión de Moodle a largo plazo

El MAQ propone como actividad complementaria leer un hilo del foro de Moodle.org titulado Long-term Moodle management, iniciado por un administrador de universidad checa con más de 15 años gestionando la misma instalación. Es una lectura que recomendaría a cualquier administrador de Moodle en entorno académico grande.

Resumen del hilo

Ondřej describe una realidad que reconocerá cualquiera que haya gestionado Moodle durante años: la instalación crece, la base de datos se hincha, los cursos similares de años distintos se acumulan sin criterio, y llega un momento en que el sistema se vuelve tan lento e inmanejable que la única solución parece ser empezar de nuevo. En su universidad lo han hecho aproximadamente cinco veces en quince años.

Su solución actual — una instalación de producción por año académico, con las anteriores en modo archivo de solo lectura y un módulo personalizado que permite a los docentes transferir sus cursos al nuevo sitio — funcionó durante un tiempo, pero la tasa de éxito en las transferencias ronda el 85%, el resto requiere intervención manual, y el mantenimiento del módulo personalizado consume cada vez más recursos. Reconocen que algo tiene que cambiar.

La respuesta más destacada del hilo viene de Gregor, administrador de un centro con 6.000 cursos y 14.000 usuarios al año. Su enfoque es diferente: una sola instalación de producción, un snapshot completo en enero que se convierte en el sitio de auditoría (solo accesible al personal, en red interna), y un proceso de fin de año en el que cada responsable indica para cada curso si quiere archivarlo, reiniciarlo o mantenerlo activo. Un script automatizado ejecuta las acciones después del 1 de enero. Cada año eliminan aproximadamente la mitad de los cursos.

Lo que aprendo de este hilo

Lo primero que me llama la atención es que no hay una solución universalmente correcta, y el hilo lo confirma: universidades con enfoques muy distintos, todas con sus propios problemas irresueltos.

Lo segundo es la trampa de la solución elegante que se vuelve costosa con el tiempo. El sistema de instalaciones anuales con módulo de transferencia de Ondřej es conceptualmente limpio, pero el coste de mantenimiento ha ido creciendo hasta hacerse insostenible. Una solución que requiere un módulo personalizado es una deuda técnica que alguien tiene que pagar cada vez que Moodle cambia su API interna.

Lo que más me resuena del enfoque de Gregor es la simplicidad operativa: una sola instalación, un proceso anual claro, decisiones descentralizadas en manos de los responsables de cada curso. El administrador no tiene que saber qué quiere hacer cada docente con sus cursos — el docente lo indica él mismo, y el sistema lo ejecuta. Eso escala bien.

En nuestro contexto, con cientos de miles de usuarios, la pregunta no es tanto qué estrategia técnica usar sino quién toma las decisiones y cómo se automatizan. Un proceso que depende de que el administrador gestione manualmente cada curso es un proceso que no sobrevive al crecimiento. La automatización y la delegación de decisiones a los propios docentes — como hace Gregor con su bloque personalizado — es el camino que tiene más sentido a largo plazo.