“¿Cuánto cuesta migrar mi Moodle?” es la pregunta que más rápido llega a soporte cuando un centro empieza a plantearse el cambio, y también la que menos se puede responder con un número único, porque el coste real depende de variables muy distintas entre una instalación y otra. Un Moodle con cinco cursos y sin plugins personalizados no tiene nada que ver, en esfuerzo real, con uno de una academia con quince años de historial, cuarenta plugins y una integración a medida con su ERP.
En esta guía vas a ver qué factores mueven de verdad el coste de una migración o actualización de Moodle, para que sepas qué preguntar y qué esperar antes de pedir un presupuesto. Si aún no tienes claro en qué se diferencia migrar de actualizar (y por qué a veces conviene tratarlos como dos proyectos distintos), te lo explicamos en migración y actualización de Moodle; aquí damos por hecho ese contexto y vamos directos al dinero.
Los factores que realmente determinan el coste
Volumen de cursos y usuarios
No es solo el número de cursos, sino su antigüedad y complejidad: un curso con contenido SCORM, cuestionarios extensos, foros activos y años de calificaciones acumuladas exige más tiempo de verificación tras la migración que uno simple con unos pocos documentos.
Plugins de terceros y personalizaciones
Este es, en la práctica, el factor que más dispara el esfuerzo y, a la vez, el más subestimado: casi todo el mundo cuenta los cursos y olvida los plugins. Cada plugin de terceros tiene que revisarse individualmente para confirmar compatibilidad con la versión destino, y cualquier desarrollo a medida (integraciones con sistemas externos, temas personalizados) necesita adaptarse específicamente, no solo “migrarse” automáticamente.
El matiz que encarece esta parte no es el número de plugins, sino cuántos de ellos no tienen versión compatible con el Moodle destino. Un plugin abandonado por su autor obliga a elegir entre buscar un sustituto (y migrar los datos que dependían de él), pagar una adaptación a medida o renunciar a esa funcionalidad. Detectar esto antes de empezar es lo que separa un presupuesto realista de una sorpresa a mitad de proyecto; lo tratamos paso a paso en cómo detectar plugins de Moodle incompatibles antes de actualizar.
Salto de versión (cuántas versiones intermedias)
No es lo mismo pasar de una versión reciente a la siguiente LTS que venir de una instalación de hace varios años que necesita pasar por dos o tres versiones intermedias antes de llegar al destino. Moodle no siempre permite saltar directo desde una versión muy antigua a la última: hay que subir por escalones, y cada escalón intermedio ejecuta sus propias migraciones de base de datos y añade su propia ronda de verificación.
Aquí conviene pensar la ruta en términos de versiones LTS (las de soporte largo). Una actualización que va de una LTS a la siguiente LTS es la ruta más limpia y la mejor documentada. Cuando el origen es una versión intermedia antigua y descontinuada, el camino hasta la LTS destino se alarga: más escalones, más migraciones de esquema, más superficie donde algo puede romperse. El número de saltos es, junto con los plugins, uno de los dos motores reales del coste.
Actualización de PHP en paralelo
Las versiones nuevas de Moodle exigen versiones más recientes de PHP, y las instalaciones que llevan años sin tocarse suelen correr sobre un PHP igual de antiguo. Eso significa que actualizar Moodle a menudo obliga a actualizar PHP a la vez, y ese cambio no es neutro: código a medida y plugins que funcionaban bien en PHP 7.x pueden fallar en PHP 8.x por funciones eliminadas o cambios de comportamiento del lenguaje. Es un factor que casi nadie contempla al pedir presupuesto y que, en instalaciones viejas, puede convertir una actualización aparentemente sencilla en una revisión de compatibilidad más amplia.
Cambio de servidor simultáneo
Migrar a un nuevo servidor a la vez que se actualiza de versión implica más puntos de verificación que hacer solo una de las dos cosas, aunque, como vimos en migrar Moodle a un nuevo servidor sin perder cursos, lo recomendable es no combinar ambos procesos en el mismo paso precisamente para mantener el esfuerzo (y el riesgo) bajo control.
Tolerancia al tiempo de inactividad
Una migración que puede ejecutarse con margen, fuera de temporada lectiva y sin urgencia, es más económica de planificar que una que necesita hacerse en un fin de semana concreto porque coincide con el inicio de curso.
Formación bonificada (FUNDAE)
Si tu centro imparte formación bonificada, la migración tiene un requisito adicional que no aplica a un Moodle genérico: verificar que la trazabilidad y los registros exigidos por FUNDAE se mantienen intactos durante todo el proceso, sin lagunas en los logs de acceso ni en los tiempos registrados. Lo tratamos en detalle en requisitos técnicos de FUNDAE para plataformas Moodle.
Tabla resumen de factores y su impacto en el coste
| Factor | Impacto en el coste | Por qué |
|---|---|---|
| Pocos cursos, sin plugins de terceros | Bajo | Es el caso base: poco que verificar, migración casi mecánica. |
| Muchos cursos con contenido complejo (SCORM, foros extensos, años de calificaciones) | Medio | Más volumen que verificar tras la migración, pero sin riesgo estructural. |
| Salto de una LTS a la siguiente | Bajo-medio | Ruta corta, bien documentada y con una sola ronda de verificación. |
| Varias versiones intermedias en la ruta de actualización | Alto | Cada escalón ejecuta sus propias migraciones de esquema y su verificación. |
| Varios plugins de terceros con versión compatible disponible | Medio | Hay que revisarlos uno a uno, pero la ruta existe. |
| Plugins sin versión compatible o desarrollo a medida | Alto | Obligan a sustituir, adaptar código o renunciar a la funcionalidad. |
| Actualización de PHP en paralelo | Medio-alto | Puede romper plugins y código a medida que funcionaban en la versión vieja. |
| Migración de servidor + actualización de versión combinadas | Alto | Duplica los puntos de fallo; recomendamos separarlas en dos pasos. |
| Formación bonificada FUNDAE activa | Medio | Verificación adicional de trazabilidad que un Moodle genérico no necesita. |
| Ventana de downtime rígida (inicio de curso, exámenes) | Medio | Obliga a comprimir la planificación y a tener plan de reversión listo. |
Por qué un presupuesto genérico no sirve
Cualquier cifra que veas publicada como “migración de Moodle desde X” en cualquier proveedor (incluido el nuestro) es un punto de partida para el caso más sencillo posible: pocos cursos, sin plugins personalizados, sin cambio de servidor. En cuanto entra en juego cualquiera de los factores de la tabla anterior, el presupuesto real se ajusta a tu caso concreto, no al genérico.
Es lo mismo que pasa con cualquier proyecto de migración de software: el número de partida sirve para orientarte sobre el orden de magnitud, pero el presupuesto ajustado solo se puede dar después de conocer el estado real de tu instalación, cuántos plugins, qué versión de origen, qué volumen de datos.
El coste oculto de un salto mal planificado
El presupuesto que ves al principio no es el único coste posible: hay un coste oculto que solo aparece cuando la migración se hace deprisa y sin auditoría previa. Es el más caro de todos, precisamente porque no estaba en el número inicial.
El patrón que más entra por soporte es siempre el mismo. Alguien actualiza varias versiones de golpe, sin inventariar los plugins ni probar en una copia. La plataforma “arranca”, así que se da por buena. Días después, con los alumnos dentro, aparece lo que no se probó: un plugin de examen que ya no carga, un tema que descuadra en móvil, un informe FUNDAE que dejó de generarse. Y entonces hay que hacer dos cosas que cuestan dinero de verdad: diagnosticar en producción, con presión y usuarios afectados, y a menudo repetir parte del trabajo porque no había copia de seguridad limpia a la que volver.
Ese “repetir el trabajo” es el corazón del coste oculto. Una migración bien planificada se hace una vez sobre una copia, se verifica con calma y solo entonces se pasa a producción. Una mal planificada se puede acabar pagando dos veces: la primera para hacerla, la segunda para arreglar lo que rompió. Por eso una auditoría previa (inventario de plugins, versión de origen exacta, prueba en entorno espejo) no es un gasto extra, sino lo que evita el gasto grande.
Migrar y actualizar a la vez o por separado
Una de las decisiones que más mueve el coste es si combinas la migración de servidor con la actualización de versión, o si las haces en dos pasos. No hay una respuesta única, pero sí una regla práctica.
Por separado es lo recomendable en el caso general, y por una razón concreta: si algo falla, sabes exactamente qué lo causó. Primero mueves Moodle al servidor nuevo tal cual, en la misma versión, y compruebas que todo funciona igual que antes. Luego, ya en el servidor definitivo, actualizas de versión. Si tras la actualización aparece un fallo, no tienes que preguntarte si es del cambio de servidor o del cambio de versión: solo cambió una cosa. Ese aislamiento de variables es lo que abarata la resolución de problemas.
A la vez solo compensa en un escenario claro: cuando la versión actual es tan antigua que ni siquiera arranca bien en un servidor moderno con PHP reciente, de modo que “moverla tal cual” no es realista. En ese caso, mantener dos entornos intermedios cuesta más que hacer el salto combinado de una vez, con verificación reforzada. Fuera de ese supuesto, combinar los dos cambios suele añadir riesgo sin ahorrar esfuerzo real.
Conviene también no confundir el coste de la migración con el coste de mantenerla después. La migración es un gasto puntual; mantener el Moodle al día (parches de seguridad, actualizaciones menores, copias) es un coste recurrente que se presupuesta aparte y con otra lógica, como explicamos en cuánto cuesta el mantenimiento de Moodle. Una migración limpia abarata el mantenimiento posterior; una hecha a lo bruto lo encarece durante meses.
Qué preguntar antes de pedir presupuesto
Para llegar a una conversación de presupuesto útil, ten a mano:
- Tu versión actual exacta de Moodle (no solo “una versión antigua”).
- Un listado de plugins de terceros instalados, aunque sea aproximado.
- El volumen aproximado de cursos y usuarios activos.
- Si hay integraciones externas (pagos, videoconferencia, sistemas de gestión académica).
- Si impartes formación bonificada FUNDAE.
- Cualquier ventana de tiempo con la que cuentes (por ejemplo, evitar tocar nada durante un periodo de exámenes).
Con esos datos, cualquier proveedor serio (nosotros incluidos) puede darte un presupuesto ajustado a tu caso real, en vez de una cifra genérica que probablemente no se sostenga una vez se empieza a trabajar.
Preguntas frecuentes
¿Por qué el presupuesto de mi migración es más alto que el “desde” que vi publicado? Porque ese “desde” corresponde al caso más simple posible. Plugins de terceros, integraciones a medida o un salto de varias versiones son los factores que más suelen elevar el presupuesto sobre esa cifra de partida.
¿Es más barato actualizar de versión que migrar de servidor? Depende del caso, pero en general actualizar de versión sin cambiar de servidor suele requerir menos esfuerzo que hacer ambas cosas, sobre todo si el servidor actual ya cumple los requisitos de la nueva versión.
¿La formación bonificada FUNDAE encarece la migración? Puede añadir esfuerzo adicional, porque hay que verificar que la trazabilidad exigida se mantiene sin lagunas durante todo el proceso, una verificación que un Moodle sin formación bonificada no necesita.
¿Puedo reducir el coste haciendo yo mismo parte del trabajo? Sí, por ejemplo preparando el inventario de plugins o la documentación de integraciones externas puede reducir el tiempo de descubrimiento inicial, aunque la ejecución técnica de la migración en sí no suele delegarse parcialmente sin riesgo.
¿Cuánto tiempo antes debería empezar a presupuestar una migración? Con margen suficiente para no depender de una fecha límite ajustada, una migración planificada con antelación suele costar menos esfuerzo (y por tanto menos presupuesto) que una urgente.
¿Un plugin gratuito es más barato de migrar que uno de pago? No necesariamente: el coste de migración de un plugin depende de su complejidad y de si tiene versión compatible disponible, no de si es gratuito o de pago.
¿Qué pasa si no sé cuántos plugins tengo instalados? Es habitual, y forma parte de la primera fase de cualquier migración seria: un inventario y auditoría inicial antes de dar cualquier cifra de presupuesto ajustada.
¿Actualizar PHP a la vez que Moodle sube mucho el coste? Depende de cuánto código a medida y cuántos plugins dependan de la versión vieja de PHP. Si son pocos y están bien mantenidos, el impacto es pequeño. Si tienes desarrollos antiguos que nunca se tocaron, el salto de PHP 7 a PHP 8 puede sacar a la luz incompatibilidades que hay que resolver una a una, y eso sí se nota en el presupuesto.
¿Sale más caro migrar desde una versión muy antigua que desde una reciente? Sí, y es uno de los factores más predecibles. Cuanto más atrás esté tu versión de origen, más escalones intermedios hay que subir, cada uno con su migración de base de datos y su verificación. Venir de una versión de hace años casi siempre cuesta más que actualizar una LTS a la siguiente.
¿Cuánto se ahorra separando la migración de servidor de la actualización de versión? El ahorro no está tanto en la ejecución como en la resolución de problemas: al cambiar una sola variable por paso, si algo falla sabes de inmediato qué lo causó. Eso reduce el tiempo de diagnóstico, que es donde se dispara el coste cuando algo se tuerce.
Conclusión
No existe un precio único para migrar Moodle, porque no existen dos instalaciones iguales. Lo que sí existe es un conjunto de factores predecibles (plugins, volumen, saltos de versión, FUNDAE) que determinan si tu caso se acerca al escenario simple o al complejo, y que cualquier proveedor serio debería revisar contigo antes de dar una cifra concreta.
Si quieres un presupuesto ajustado a tu instalación real, en Avantys empezamos siempre con una auditoría gratuita para conocer el estado exacto de tu Moodle antes de proponer nada. Puedes pedirla en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Migrar Moodle a un nuevo servidor sin perder cursos
- Checklist de actualización de Moodle sin downtime
- Requisitos técnicos de FUNDAE para plataformas Moodle
- Plugins de Moodle incompatibles: cómo detectarlos antes de actualizar
¿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.
