Una migración a Moodle no falla por razones técnicas: falla porque nadie decidió a tiempo qué se migraba, quién validaba y cuándo se apagaba la plataforma anterior. Este checklist ordena el proyecto en el orden en que realmente ocurre. Somos el Moodle Certified Partner del Perú.
Antes del checklist: la decisión y el patrocinio
El primer requisito no aparece en ningún manual técnico: alguien con autoridad debe firmar la decisión y sostenerla. Una migración toca al área académica, a tecnología, a administración y a los docentes; sin patrocinio, cada área prioriza lo suyo y el proyecto se estanca.
El segundo requisito es un responsable operativo por parte de la institución, con tiempo asignado. No es un rol simbólico: valida entregables, resuelve dudas de negocio y destraba decisiones.
Inventario de lo que existe hoy
El inventario responde cuatro preguntas: cuántos cursos hay, cuáles se usaron en el último año, qué tipos de contenido contienen y qué sistemas están conectados a la plataforma actual.
Casi siempre el resultado sorprende: una parte importante de los cursos no tiene actividad reciente. Ese hallazgo es útil porque reduce el alcance real del trabajo y permite conversar con datos en lugar de con impresiones.
Inventaría también los usuarios activos, los roles personalizados y los plugins instalados con su propósito. Un plugin sin dueño es una decisión pendiente.
Qué migra y qué no
Esta es la decisión que más tiempo ahorra. Una regla que funciona: migra lo que se dictará en el próximo periodo, reconstruye lo que está desactualizado y archiva el resto.
Migrar todo por precaución es la opción más cara: aumenta el trabajo de validación, arrastra errores antiguos y llena la plataforma nueva de cursos que nadie abrirá. Archivar no es perder; es conservar de forma consultable fuera del entorno de producción.
Documenta la decisión con nombres y responsables. Sin ese documento, la conversación se repite cada semana.
Usuarios, matrículas y limpieza de datos
Los datos de personas son la fuente habitual de retrasos. Antes de cargar nada conviene depurar duplicados, unificar el formato del identificador (correo institucional o documento), dar de baja a quienes ya no pertenecen y confirmar qué sistema será la fuente de verdad en adelante.
Si vas a usar inicio de sesión único, esta limpieza es obligatoria: una cuenta duplicada se convierte en dos usuarios distintos el día uno. Nuestro artículo sobre SSO en Moodle detalla ese riesgo.
Define también el proceso de altas y bajas después del corte. Una migración impecable se degrada en tres meses si las matrículas siguen cargándose a mano.
Cursos, contenidos y actividades
Los contenidos estáticos (documentos, enlaces, páginas) suelen migrar sin fricción. Los que exigen atención son los paquetes SCORM, los contenidos interactivos y las actividades con configuración fina, porque su comportamiento puede cambiar entre plataformas.
La recomendación práctica es migrar un curso piloto de cada tipo, validarlo con su docente y recién entonces procesar el lote. Ese piloto revela en un día problemas que de otro modo aparecerían al final.
Si tu contenido incluye estándares de interoperabilidad, revisa SCORM y xAPI en Moodle.
Calificaciones e historial académico
Las calificaciones históricas plantean una pregunta normativa antes que técnica: ¿la institución está obligada a conservarlas y por cuánto tiempo? La respuesta define si se migran al libro de calificaciones, si se archivan como exportación o si el sistema académico es el custodio oficial.
Lo que no debe ocurrir es migrar calificaciones "por si acaso" sin definir su valor oficial: se genera una segunda fuente de verdad que después nadie sabe cuál manda.
Integraciones y accesos
Lista cada conexión activa: sistema académico o de recursos humanos, videoconferencia, correo, herramientas externas por LTI, antiplagio y reportes. Para cada una define responsable, credenciales, ambiente de prueba y fecha de habilitación.
Las integraciones son la parte del proyecto que más depende de terceros, así que se arrancan temprano. Detalle en integraciones LTI y en Microsoft 365 y Google Workspace.
Pruebas y validación con usuarios reales
Las pruebas técnicas confirman que el sistema funciona; las pruebas con usuarios confirman que sirve. Necesitas ambas.
Un plan mínimo incluye: recorrido completo de un estudiante (entrar, ver el curso, entregar, ver nota), recorrido de un docente (crear actividad, calificar, exportar), recorrido de administración (alta, baja, reporte) y una prueba de carga si esperas evaluaciones masivas.
Cada recorrido debe tener un validador con nombre y una fecha de aceptación. Una prueba sin firma no cierra nada.
Plan de corte y convivencia
El corte se planifica al detalle: fecha y hora, congelamiento de cambios en la plataforma anterior, migración final de datos incrementales, verificación posterior y comunicación a la comunidad.
Define además el periodo de convivencia: cuánto tiempo la plataforma anterior queda disponible solo para consulta y en qué fecha se apaga. Sin fecha de apagado, el costo doble se vuelve permanente.
Ten listo un criterio de reversión: qué tendría que ocurrir para volver atrás y quién lo decide. Casi nunca se usa, y por eso mismo vale tenerlo escrito.
Las primeras semanas después
Los primeros quince días concentran la mayoría de los tickets. Conviene reforzar la atención, publicar una guía breve por rol y hacer seguimiento diario de los problemas reportados, agrupándolos para detectar causas comunes.
Al cierre del primer mes, una reunión de balance con datos (tickets por tipo, cursos activos, accesos) permite ajustar antes de que los hábitos se consoliden. Para la parte operativa continua, revisa soporte y mantenimiento y la checklist de migración descargable.