Cómo Migrar Moodle de Servidor sin Pérdida de Datos ni Interrupciones

Migrar Moodle de servidor parece la tarea más sencilla del mundo hasta el primer intento: copiar tres cosas, apuntar el DNS y listo. En la práctica, es exactamente ahí donde se pierden entregas de alumnos, calificaciones de un semestre completo y una mañana de clase. Trabajo con Moodle desde 2008 y esta es la hoja de ruta que utilizo para mover un EVA de un servidor a otro sin perder datos y sin interrumpir la operación.

TL;DR — lo esencial

• Una migración mueve tres componentes independientes: el código de Moodle, la carpeta moodledata y la base de datos. Olvidar uno de ellos es el error nº 1.
• La ventana de inactividad no tiene por qué ser de horas. Con copia incremental y TTL de DNS reducido, el corte real se reduce a minutos.
• No migre y actualice la versión en el mismo proceso. La documentación oficial es explícita: una variable a la vez, o no sabrá qué ha fallado.
• En septiembre de 2026 el calendario influye en la decisión: Moodle 5.0 pierde incluso el soporte de seguridad el 5 de octubre de 2026, y la versión 5.3 LTS llega el mismo día, con soporte de seguridad hasta el 1 de octubre de 2029.
• Migrar Moodle de servidor sin ensayo previo es una apuesta. El ensayo cuesta unas horas; el rollback improvisado cuesta el semestre.

Qué cambia realmente al migrar Moodle de servidor

Moodle no es un sitio web. Es un sistema con estado distribuido en tres lugares que deben llegar íntegros y coherentes entre sí al destino. Quien va a migrar Moodle de servidor necesita llevar los tres componentes en la misma instantánea temporal — entender esto ya evita la mitad de los accidentes.

1. El código

La carpeta de la aplicación: núcleo de Moodle, plugins, tema y personalizaciones. Es la parte más fácil de mover y la más fácil de subestimar — los plugins de terceros instalados hace años a menudo no tienen registro en ningún sitio. Genere la lista real en Administración del sitio → Plugins → Vista general de plugins y guárdela fuera del servidor.

2. La carpeta moodledata

Es donde viven los archivos enviados por profesores y alumnos, las copias de seguridad del curso y las cachés. Se encuentra fuera de la carpeta pública del sitio y su ruta está en el $CFG->dataroot del config.php. Es el componente más pesado: en un EVA con algunos años de operación, suele ser decenas de veces mayor que el código.

La documentación oficial recomienda no copiar los subdirectorios cache, localcache, sessions, temp y trashdir. Son efímeros, Moodle los recrea, e ignorarlos reduce horas de transferencia.

3. La base de datos

Todo lo demás: usuarios, matriculaciones, calificaciones, registros, configuraciones, contenido de los cursos. Es el componente que exige congelación — si alguien envía una tarea después del volcado, ese archivo estará en el moodledata nuevo y su registro no estará en la base de datos nueva. Resultado: archivo huérfano, entrega invisible en la corrección.

Cuándo migrar Moodle de servidor — y cuándo posponer

Migrar por migrar no resuelve nada. Las razones que respaldan la decisión de migrar Moodle de servidor son cuatro:

• El servidor no soporta el pico. El cuello de botella de EAD es estacional: la semana de exámenes y la primera semana del semestre concentran el acceso. Si el sistema falla precisamente en ese momento, el problema es el dimensionamiento.
• La pila se ha quedado demasiado obsoleta para la próxima versión. Moodle 5.0 ya exige PHP 8.2 como mínimo, la extensión sodium y max_input_vars mayor o igual a 5000. Un servidor anclado en PHP 7.4 no puede recibir una nueva versión — punto final.
• Nadie se encarga de la infraestructura. Un servidor sin responsable definido no tiene copia de seguridad probada, ni actualización de seguridad, ni monitorización. No es un riesgo técnico, es un riesgo institucional.
• El coste no cuadra. Un VPS grande y ocioso 10 meses al año, o un plan de nube gestionada que no permite instalar el plugin del que depende la institución.

¿Y cuándo no migrar? Tres situaciones en las que la respuesta correcta es esperar:

1. En mitad del semestre, con actividades abiertas y plazos en curso. El momento ideal es el receso, el cambio de semestre o la madrugada de fin de semana.
2. Junto con una actualización de versión. La documentación oficial de migración pide un cambio a la vez: si algo falla, necesita saber qué lo causó. Migre, estabilice y solo después actualice.
3. Sin una copia de seguridad restaurada con éxito al menos una vez. Una copia de seguridad que nunca ha sido probada es una hipótesis, no una garantía — el mismo razonamiento que ya detallé en el caso de la eliminación de contenidos en el Moodle de la UFOP.

A qué versión migrar en septiembre de 2026

Esta es la decisión que más influye en el resultado, porque define los requisitos del destino. Quien va a migrar Moodle de servidor ahora necesita consultar el calendario oficial antes de elegir la versión:

Versión	Lanzamiento	Fin del soporte general	Fin del soporte de seguridad	LTS
4.5	07/10/2024	06/10/2025	04/10/2027	Sí
5.0	14/04/2025	20/04/2026	05/10/2026	No
5.1	06/10/2025	05/10/2026	19/04/2027	No
5.2	20/04/2026	19/04/2027	04/10/2027	No
5.3	05/10/2026	04/10/2027	01/10/2029	Sí

Fuente: tabla de lanzamientos de Moodle Developer Resources.

De esto se desprenden dos lecturas prácticas. La primera: quien aún utiliza la versión 5.0 tiene un plazo corto — el 5 de octubre de 2026 ni siquiera se publicarán más correcciones de seguridad. La segunda: la versión 5.3 es la próxima LTS, con soporte de seguridad hasta octubre de 2029. Si la migración es ahora, el destino inteligente es un servidor que ya cumpla con los requisitos de la versión 5.3, incluso si instala la versión 5.1 o 5.2 hoy y realiza la actualización más tarde, en otra ventana.

Y los requisitos han aumentado considerablemente:

Requisito	Moodle 5.0	Moodle 5.3 (LTS)
PHP mínimo	8.2 (8.3 y 8.4 soportados)	8.3 (8.4 soportado)
MariaDB	10.11	10.11
MySQL	8.4	8.4
PostgreSQL	14	16
SQL Server	—	2019
Oracle	No soportado	No soportado

La interrupción del soporte de Oracle a partir de la versión 5.0 y el salto de PostgreSQL a la versión 16 en la 5.3 son los detalles que suelen frustrar los planes de migración realizados "a ojo". Compruebe también la longitud del prefijo de las tablas: el límite ha pasado a ser de 10 caracteres. Ya he escrito sobre este tipo de trampas al analizar las versiones y el ciclo LTS de un EVA institucional grande.

El paso a paso que reduce el riesgo a casi cero

Pre-vuelo (días antes)

Antes de migrar Moodle de servidor, determine la versión exacta de Moodle, la versión de PHP y de la base de datos, la lista de plugins, el tamaño de moodledata, el tamaño del volcado de la base de datos y quiénes son los integradores externos (SSO, matriculación automática, pasarela de pago, aplicación). Provisone el destino ya con la pila correcta y pruebe una instalación limpia de Moodle en él: si la instalación limpia falla, la migración también fallaría — pero más tarde y con datos dentro.

Ensayo (la etapa que casi nadie realiza)

Ensayar la migración de Moodle de servidor una vez completa, sin cambio de servicio, con el nuevo sitio respondiendo en una dirección temporal y en modo de mantenimiento. Es en el ensayo donde aparecen el plugin incompatible, el permiso erróneo y el cron que no se ejecuta. Cronometre cada etapa: ese número se convierte en la ventana real que anunciará a la institución.

Ejecución

Ha llegado el día. Esta es la orden que sigo para migrar Moodle de servidor en producción — cada elemento de la lista existe porque un día faltó en algún lugar.

1. Active el modo de mantenimiento en el sitio antiguo. Sin esto no existe consistencia entre la base de datos y los archivos.
2. Genere el volcado de la base de datos con la herramienta nativa (mysqldump, pg_dump) y compruebe el tamaño del archivo — un volcado truncado es silencioso.
3. Copie el moodledata con rsync, saltándose cache, localcache, sessions, temp y trashdir.
4. Copie el código con los plugins y el tema.
5. Cree la base de datos vacía en el destino con la collation correcta (normalmente utf8mb4_unicode_ci) y restaure el volcado.
6. Ajuste el config.php: $CFG->wwwroot, $CFG->dataroot y las credenciales de la base de datos.
7. Corrija propietario y permisos del código y del moodledata — el servidor web necesita permisos de lectura y escritura en el moodledata.
8. Ejecute el cron manualmente una vez y supervise la salida; luego prográmelo.
9. Pruebe con el sitio aún en mantenimiento: inicio de sesión de administrador, un curso con actividad, subida, envío de correo electrónico, informe de calificaciones.
10. Realice el cambio de DNS, salga del modo de mantenimiento y monitorice los registros durante 48 horas.

La guía completa se encuentra en la documentación oficial de migración de Moodle — conviene leerla antes, no durante.

Cómo reducir la ventana de inactividad de horas a minutos

La parte que consume más tiempo al migrar Moodle de servidor es copiar archivos, y los archivos antiguos no cambian. Utilice esto a su favor.

Copia en dos pasadas. Días antes, ejecute un rsync con el sitio en línea — transfiere el volumen completo sin prisas. El día D, con el sitio en mantenimiento, ejecute el mismo rsync de nuevo: copia solo el delta, y lo que antes llevaba horas, ahora lleva minutos.

TTL de DNS reducido. Reduzca el TTL del registro para 300 segundos con 24 a 48 horas de antelación. Sin esto, parte de los alumnos sigue accediendo al servidor antiguo durante horas después del cambio de servicio — y, lo que es peor, enviando archivos que quedarán huérfanos allí.

Servidor antiguo en modo de mantenimiento, no apagado. Quien acceda por caché de DNS verá "en mantenimiento" en lugar de un error, y no grabará nada.

Validación con el nuevo sitio aún en mantenimiento. Si necesita rehacer la restauración, nadie habrá perdido trabajo.

En la práctica, con esta secuencia, la ventana anunciada suele ser de 30 a 60 minutos, de los cuales gran parte es prueba — y no transferencia.

Nuevo dominio: la herramienta search and replace que salva (o destruye) el sitio

Quien va a migrar Moodle de servidor y cambiar de dominio en el mismo proceso tiene una tarea extra. Si la dirección cambia, el contenido de la base de datos sigue apuntando al antiguo: enlaces dentro de etiquetas, páginas, preguntas y recursos. Moodle incluye la herramienta en /admin/tool/replace/index.php, con versión de línea de comandos:

php admin/tool/replace/cli/replace.php --search=//antigo.exemplo.br --replace=//novo.exemplo.br --shorten --non-interactive

Tres precauciones que la propia documentación señala — y una cuarta que aprendí a base de golpes:

• Copia de seguridad de la base de datos antes. La herramienta reescribe texto en masa y no tiene "deshacer".
• Sin barra final y sin esquema fijo. Buscar por //antigo.exemplo.br cubre http y https de una vez.
• Ejecute una sola vez, con el sitio en mantenimiento. Dos ejecuciones con patrones diferentes se convierten en un desorden difícil de auditar.
• reCAPTCHA e integraciones necesitan una nueva clave. Un nuevo dominio invalida las claves de Google utilizadas en el registro por correo electrónico; lo mismo ocurre con los callbacks de SSO y de la pasarela de pago, que apuntan a la URL antigua.

Siete trampas que arruinan una migración de Moodle

Las siete ya han aparecido en entornos que recibí para arreglar después de alguien migrar Moodle de servidor a toda prisa.

1. Copiar el moodledata con el sitio en línea y sin segunda pasada. Todo lo que se añadió después de la copia desapareció.
2. Permisos erróneos. El sitio se abre, pero ninguna subida funciona. Casi siempre es propietario de moodledata diferente del usuario del servidor web.
3. Collation diferente entre origen y destino. Acentuación corrupta en miles de registros — y la corrección posterior es costosa.
4. Cron no configurado en el destino. Sin cron, Moodle deja de notificar, de procesar colas y de indexar — sin error visible, silenciosamente.
5. Plugins ausentes. Moodle se inicia quejándose de tablas de plugins que ya no existen, y actividades enteras desaparecen de los cursos.
6. Migrar y actualizar a la vez. Cuando falla, tiene dos sospechosos y ninguna forma rápida de revertir.
7. No conservar el servidor antiguo durante una semana. Apagarlo al día siguiente es apostar a que no se ha olvidado nada.

Cuánto cuesta migrar Moodle de servidor — y cuánto cuesta no migrar

Hay tres caminos, con costes muy diferentes.

Nube oficial (MoodleCloud). Los planes estándar van de 230 AUD al año (50 usuarios, 1 GB de almacenamiento) a 3.000 AUD al año (750 usuarios, 50 GB), conforme a la tabla oficial de planes. Es predecible, pero con un límite estricto: no se pueden instalar plugins ni integraciones, y el dominio propio solo está incluido en el plan más alto. Para una institución que depende de un plugin de matriculación, un emisor de certificados o una integración con el sistema académico, la conversación termina ahí.

VPS por cuenta propia. El alquiler es barato; el coste real es el tiempo de quien lo administra. Actualización de PHP, certificado, ajuste de la base de datos, copia de seguridad probada, monitorización y respuesta a incidentes en la semana de exámenes — esto es una función, no una tarea.

Alojamiento gestionado especializado. El servidor viene optimizado para Moodle y alguien responde por su funcionamiento. Es el modelo que ofrecemos en alojamiento gestionado de Moodle, y el que tiene sentido para quienes tienen alumnos que dependen del entorno y no disponen de un administrador de sistemas dedicado.

El coste de no migrar es el más fácil de subestimar: un EVA fuera del soporte de seguridad es una superficie de ataque conocida. Con 146.693 sitios Moodle registrados en el mundo, según el panel oficial de estadísticas, una vulnerabilidad divulgada se explota a escala — y no elige objetivo.

Cómo Agathas Web lo resuelve

Migrar Moodle de servidor es un servicio, no un producto de estantería. Lo que hacemos, en orden:

• Diagnóstico del entorno actual. Versión, plugins, tamaño de moodledata y base de datos, integraciones y lo que está fuera de soporte. De ahí surge la estimación honesta de la ventana de tiempo.
• Aprovisionamiento del destino. Servidor ya con la pila compatible con Moodle 5.x — PHP 8.2 o superior con sodium, base de datos en la versión mínima exigida, Redis para caché y sesiones, certificado, firewall y cron.
• Ensayo completo antes del día D. Nuevo sitio en línea en una dirección temporal, para validar plugins, tema, SSO, envío de correo electrónico y rendimiento antes de cualquier cambio de servicio.
• Cambio de servicio con copia incremental y TTL bajo, con el servidor antiguo preservado en modo de mantenimiento durante una semana como rollback real.
• Operación posterior. Copia de seguridad diaria automatizada con restauración probada, monitorización, actualización de punto de versión y soporte técnico en español. Es lo que está incluido en el alojamiento gestionado de Moodle — la migración inicial se incluye en el proceso de contratación, sin coste adicional para entornos dentro del tamaño del plan.

Somos certificados en Moodle, administramos entornos críticos de EAD desde 2008 y desarrollamos las integraciones cuando el plugin listo no existe — desde la sincronización con el sistema académico hasta la notificación al alumno a través de la API oficial de WhatsApp, para avisar plazos y calificaciones sin depender del correo electrónico que nadie abre.

Para empezar, el camino es sencillo: a través de la página de alojamiento gestionado de Moodle puede solicitar el diagnóstico, recibe el análisis del entorno actual y una ventana de migración propuesta en una fecha que no interfiera con el calendario académico.

Conclusión: planifique el cambio, no la prisa

Migrar Moodle de servidor con seguridad es menos sobre comandos y más sobre secuencia: congelar, copiar en dos pasadas, validar en mantenimiento, cambiar el DNS con TTL bajo y guardar el servidor antiguo como red de protección. Los tres componentes — código, moodledata y base de datos — deben llegar juntos y coherentes, y la actualización de versión se deja para otro día.

Si su entorno está atrapado en una pila que no soporta Moodle 5.x, o si el servidor ya ha dado lo que tenía que dar, el siguiente paso es analizar lo que existe hoy antes de elegir el destino. Solicite el diagnóstico a través de la página de alojamiento gestionado de Moodle y realice el cambio en el momento adecuado — no en mitad de la semana de exámenes.