Cambiar de servidor da más respeto que actualizar de versión, y con razón: además de la propia plataforma, entran en juego DNS, configuración de PHP distinta, rutas de archivos y un margen de downtime que hay que gestionar bien. La buena noticia es que, a diferencia de una actualización de versión, migrar a un servidor nuevo es un proceso mucho más mecánico si se sigue en el orden correcto.
En esta guía vas a ver qué archivos y datos hay que mover exactamente, cómo probarlo todo antes de hacer el cambio real, y por qué combinar la migración con una actualización de versión al mismo tiempo es, casi siempre, mala idea.
Qué necesitas mover exactamente
Una instalación de Moodle vive en tres sitios distintos, y los tres tienen que llegar al servidor nuevo:
- El código de Moodle: la carpeta de instalación completa.
moodledata: la carpeta con archivos subidos por profesores y alumnos, backups de curso, caché y sesiones. Suele estar fuera del directorio web por seguridad, y es la que más veces se olvida en una migración precipitada.- La base de datos: un volcado completo de MySQL/MariaDB o PostgreSQL con todas las tablas de Moodle.
Si falta cualquiera de los tres, el resultado no es un error visible inmediato: puede ser una plataforma que arranca pero con archivos rotos, o con datos inconsistentes que aparecen días después. La documentación oficial de migración de Moodle detalla el proceso completo y merece revisarse antes de empezar, sobre todo si es tu primera migración.
Por qué no conviene migrar y actualizar versión a la vez
Es tentador aprovechar el cambio de servidor para también saltar a una versión más reciente de Moodle. La recomendación general de la propia comunidad de Moodle es evitarlo: si algo falla, no sabrás si el problema viene de la migración o de la actualización de versión, lo que complica mucho el diagnóstico y el rollback.
El orden correcto es:
- Migra primero el servidor, con la misma versión de Moodle que tenías en origen.
- Verifica que todo funciona igual que antes en el servidor nuevo.
- Solo entonces, si toca, ejecuta la actualización de versión como un paso separado, con su propio backup y su propio entorno de pruebas.
Cubrimos ese segundo paso en detalle en cómo actualizar Moodle 3.x a 4.5 LTS paso a paso y en migración y actualización de Moodle.
El proceso paso a paso
1. Prepara el servidor nuevo antes de mover nada
Instala en el servidor destino exactamente la misma versión de PHP, extensiones y motor de base de datos que usa el servidor de origen, no una versión “parecida”. Migrar y encontrarte con una versión de PHP distinta añade una segunda variable de riesgo justo cuando menos la necesitas.
2. Copia el código de Moodle
rsync -avz --progress usuario@servidor-origen:/ruta/moodle/ /ruta/moodle/rsync conserva permisos y es reanudable si la conexión se corta a mitad de una transferencia grande, preferible a una copia simple para instalaciones con muchos años de archivos acumulados.
3. Copia moodledata con el mismo cuidado
rsync -avz --progress usuario@servidor-origen:/ruta/moodledata/ /ruta/moodledata/Verifica después los permisos: el usuario del servidor web en el destino necesita permisos de lectura y escritura sobre esta carpeta, igual que en origen, un fallo de permisos aquí es de las causas más comunes de errores extraños tras una migración aparentemente correcta.
4. Exporta e importa la base de datos
mysqldump -u usuario -p nombre_bd > backup_moodle.sqlY en el servidor destino:
mysql -u usuario -p nombre_bd_nueva < backup_moodle.sqlPara bases de datos grandes, comprime el volcado antes de transferirlo para no depender de la velocidad de red durante horas.
5. Ajusta config.php
El archivo config.php del servidor nuevo necesita reflejar las credenciales de la base de datos del destino, y (muy importante) la variable $CFG->wwwroot debe apuntar a la URL final donde va a vivir el sitio, no a la del servidor de origen. Si el dominio no cambia, esto es sencillo; si migras también de dominio, revisa además cualquier ruta absoluta que puedas tener guardada en configuraciones de plugins.
6. Verifica el cron
El cron de Moodle no se migra automáticamente: hay que volver a configurarlo en el servidor nuevo apuntando a la ruta correcta del código migrado. Un cron que deja de ejecutarse tras una migración es un fallo silencioso, la plataforma sigue funcionando de cara al usuario, pero notificaciones, sincronizaciones y tareas programadas dejan de correr sin que nadie lo note hasta días después.
7. Prueba en el servidor nuevo antes del cambio de DNS
Antes de apuntar el dominio al nuevo servidor, accede a él directamente por IP o mediante una entrada temporal en el archivo hosts de tu propio equipo, y comprueba: acceso de alumnos y profesores, entrega de tareas, calificaciones, envío de correo, y cualquier integración externa (videoconferencia, plugins).
8. Cambia el DNS y monitoriza
Una vez confirmado que todo funciona en el servidor nuevo, actualiza el registro DNS del dominio. Ten en cuenta la propagación: durante ese periodo, una parte de los usuarios puede seguir llegando al servidor antiguo. Mantén el servidor de origen intacto, sin apagarlo, durante al menos 48-72 horas tras el cambio, como red de seguridad.
Diferencias entre migrar y solo actualizar en el mismo servidor
| Migrar a nuevo servidor | Actualizar en el mismo servidor | |
|---|---|---|
| Motivo típico | Servidor antiguo, recursos insuficientes, cambio de proveedor | Solo se busca la última versión de Moodle |
| Riesgo principal | Diferencias de entorno entre origen y destino | Incompatibilidad de plugins o configuración heredada |
| Plan de contingencia | El servidor original queda intacto como respaldo | Requiere restaurar backup sobre el mismo servidor |
| Complejidad de DNS | Sí, hay que gestionar propagación | No aplica |
| Recomendable combinar con actualización de versión | No en el mismo paso: hazlo después, por separado | No aplica |
Errores comunes al migrar
- Olvidar
moodledatay mover solo el código y la base de datos, dejando atrás archivos de alumnos y profesores. - No verificar permisos de archivo en el servidor nuevo, causando errores de subida o visualización de archivos que parecen aleatorios.
- Dejar el cron sin reconfigurar, con tareas programadas que dejan de ejecutarse sin ningún aviso visible.
- Cambiar de versión de Moodle en el mismo paso que la migración, complicando el diagnóstico si algo falla.
- Apagar el servidor antiguo inmediatamente tras el cambio de DNS, sin margen para la propagación ni para revertir si aparece un problema.
Preguntas frecuentes
¿Puedo migrar Moodle sin downtime? Es posible minimizarlo mucho (preparando y probando todo en el servidor nuevo antes del cambio de DNS), pero un breve periodo de solo lectura o mantenimiento durante la sincronización final de datos es lo más prudente para evitar inconsistencias.
¿Necesito la misma versión de PHP en el servidor nuevo? Sí, al menos durante la migración. Cambiar de versión de PHP y de servidor a la vez multiplica las variables de riesgo si algo falla.
¿Qué pasa si olvido migrar moodledata?
El sitio puede arrancar aparentemente bien, pero los archivos subidos por usuarios, backups de curso y caché no estarán disponibles, un fallo que puede tardar días en notarse si nadie revisa esos archivos de inmediato.
¿Debo actualizar la versión de Moodle durante la misma migración? No es lo recomendable. Migra primero manteniendo la misma versión, verifica que todo funciona, y trata la actualización de versión como un proyecto separado y posterior.
¿Cómo pruebo el servidor nuevo antes de cambiar el DNS? Accediendo por IP directa o mediante una entrada temporal en el archivo hosts de tu propio equipo, sin necesidad de exponer el cambio a todos los usuarios todavía.
¿Cuánto tarda en propagarse el cambio de DNS? Depende del TTL configurado previamente en el registro, pero puede tardar desde minutos hasta 24-48 horas en completarse globalmente.
¿Puedo apagar el servidor antiguo justo después del cambio de DNS? No es recomendable. Mantenlo activo unos días como red de seguridad mientras se completa la propagación y confirmas que no hay ningún problema en el nuevo.
¿Qué pasa si cambio también de dominio en la migración?
Además de actualizar $CFG->wwwroot, revisa cualquier ruta absoluta guardada en configuraciones de plugins o en contenido embebido de cursos que pueda referenciar el dominio antiguo directamente.
Conclusión
Migrar Moodle a un nuevo servidor es, sobre todo, una cuestión de orden: mover los tres componentes completos, probar en el destino antes de tocar el DNS, y no mezclar la migración con una actualización de versión en el mismo paso. Seguido así, el riesgo real es mucho menor de lo que parece antes de empezar.
Si prefieres que alguien planifique y ejecute esta migración sin que tus alumnos noten el cambio, en Avantys lo hacemos de forma recurrente para centros que cambian de infraestructura. 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
- Cuánto cuesta migrar Moodle: factores reales
- Checklist de actualización de Moodle sin downtime
- Backup y restauración completa de un curso de Moodle
- Requisitos de servidor para Moodle (CPU, RAM, disco)
¿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.
