Falta un inventario de extensiones y responsables
Encuentro el inventario en la cabeza de una persona o descubro que no existe. Sin él no puedo estimar nada.
Moodle · Ingeniería
Actualizar Moodle cuando las extensiones heredadas bloquean la evolución
He visto plataformas quedarse atrás por acumulación: extensiones sin mantenimiento, modificaciones directas sobre el núcleo, integraciones que dependen de comportamientos antiguos y falta de un inventario comprobado. Con esa carga, afronto la actualización como un proyecto con riesgo, no como una tarea de mantenimiento. Compruebo además un límite práctico: Moodle solo admite saltos desde versiones relativamente recientes. Si parto de una instalación muy antigua, encadeno actualizaciones intermedias. Antes de ejecutar la actualización, determino qué puede dejar de funcionar; ahí está el trabajo real.
- La documentación oficial fija desde qué versiones se puede saltar; desde otras más antiguas hay que pasar por etapas intermedias.
- Después de inventariar extensiones, modificaciones, integraciones y recorridos críticos, preparo una copia protegida y representativa de producción, con los datos minimizados necesarios para reproducir los recorridos críticos. Una instalación limpia sirve para comprobar el núcleo y las dependencias de base, pero no reproduce por sí sola los riesgos de los datos, las extensiones y las integraciones reales.
- Para cada extensión reviso la compatibilidad declarada en el directorio oficial y la verifico en un entorno representativo.
- Las extensiones incompatibles, las abandonadas y las modificaciones del núcleo pueden bloquear la actualización; el inventario debe distinguir cada riesgo.
Experiencia en ingeniería
Inventarío extensiones, modificaciones del núcleo, integraciones y responsables antes de actualizar. Compruebo la compatibilidad una por una, reproduzco en un entorno de pruebas las condiciones relevantes de producción, ejecuto cada salto, pruebo los recorridos críticos y preparo la vuelta atrás.
Mi trayectoriaCuándo aparece el bloqueo
Cuatro señales de que la actualización ya no es una tarea rutinaria.
Han modificado el núcleo de Moodle
Alguien modificó ficheros del propio Moodle para resolver algo. Cada actualización puede sobrescribir esos cambios. La organización tiene que reconstruirlos, comprobar su impacto y decidir si los extrae del núcleo o los elimina.
La versión ha quedado tan desfasada que no admite una actualización directa
Encadeno actualizaciones intermedias. Cada etapa añade nuevas comprobaciones de compatibilidad y posibles puntos de fallo, que reviso.
Falta un entorno de pruebas representativo
Doy poco valor a las pruebas previas si el entorno no reproduce las condiciones relevantes de producción, porque aumenta el riesgo de descubrir fallos después del despliegue.
Cómo preparo la actualización
Sigo cinco pasos. El inventario inicial condiciona los demás, aunque el trabajo que exige depende de las extensiones, las integraciones, los datos y los recorridos críticos de cada plataforma.
- 01
Inventariar todo lo que no es núcleo
Inventarío las extensiones instaladas y anoto su versión y su origen. También registro los temas, las modificaciones del núcleo, las integraciones activas y las personalizaciones de configuración. Sin este inventario, basaría cualquier planificación en estimaciones a ciegas.
- 02
Comprobar la compatibilidad una por una
Para cada extensión, reviso si el directorio oficial declara una versión compatible con la versión de destino. Después compruebo esa compatibilidad en el entorno de pruebas. Si no existe una versión compatible, decido entre sustituir la extensión, asumir su desarrollo o retirar la funcionalidad.
- 03
Copiar la plataforma de producción en un entorno de pruebas
Pruebo el salto sobre una copia protegida y representativa de producción. Minimizo los datos cuando corresponde e incluyo las extensiones y los recorridos críticos. Así puedo detectar incompatibilidades que una instalación limpia no reproduce, aunque todavía debo probar las diferencias de configuración, carga y servicios externos.
- 04
Ejecutar el salto y anotarlo todo
Cuando encadeno versiones intermedias, compruebo cada una en un entorno representativo. Los fallos que aparecen allí señalan incompatibilidades que probablemente afectarían a producción, pero reviso también las diferencias de configuración, carga y servicios externos.
- 05
Probar los recorridos críticos y preparar la vuelta atrás
Pruebo los recorridos críticos: entro, veo un curso, hago un cuestionario y califico. Compruebo que la sincronización funcione y que los informes salgan. También decido de antemano cómo volver al estado anterior si algo sale mal.
Lo que suele fallar
Seis problemas que encuentro durante la actualización o después.
Probar sobre una instalación limpia
Compruebo con una instalación limpia que la versión de destino funciona con las dependencias básicas de ese entorno. Esa prueba no cubre el salto sobre la base de datos existente ni la compatibilidad de los datos, las extensiones y las integraciones. Para comprobarlo, ensayo la actualización sobre una copia protegida y representativa de producción.
Modificaciones del núcleo que nadie documentó
Descubro estas modificaciones cuando la actualización las borra y algo deja de funcionar sin que nadie sepa por qué.
Integraciones que dependían de comportamientos antiguos
He visto cómo un cambio interno de la plataforma rompe una integración que llevaba años funcionando. Sin pruebas de integración, aumenta el riesgo de que la rotura no se detecte antes de llegar a producción.
Sin plan de vuelta atrás
Compruebo antes de actualizar que la restauración funciona y cuánto tarda. Si la actualización deja la plataforma en un estado desde el que no se puede continuar con seguridad, necesito una restauración ya probada; en otros fallos puede ser posible corregir la causa y reanudar el proceso.
Olvidar las versiones de las dependencias del servidor
Compruebo las versiones mínimas del lenguaje y de la base de datos que exige cada versión de Moodle. Si actualizo la aplicación sin actualizar esas dependencias del servidor, dejo el proyecto a medias.
No comunicar el cambio de interfaz
Comunico al profesorado los cambios visibles de cada versión nueva. Si encuentra cambios de interfaz sin aviso, puede percibir la actualización como problemática aunque se hayan cumplido los objetivos técnicos.
Cómo planifico la actualización
Respondo cinco preguntas para ordenar el proyecto antes de tocar nada.
- 01
¿Desde qué versión partimos y admite salto directo?
Compruebo en la documentación oficial desde qué versiones puedo actualizar a cada versión de destino. Si la versión actual es anterior, planifico etapas intermedias y multiplico las pruebas.
- 02
¿Cuántas extensiones no tienen versión compatible?
El número orienta, pero no decide por sí solo. Estimo criticidad, complejidad, uso, mantenimiento, dependencias y coste de sustituir cada extensión antes de dimensionar el proyecto.
- 03
¿Hay modificaciones del núcleo?
Trato cada modificación del núcleo como un riesgo que reaparece en cada actualización y puede obligarme a aplicar de nuevo el cambio. Aprovecho la actualización para extraerla del núcleo o eliminarla.
- 04
¿Cuándo hay una ventana real para actualizar?
Busco una fecha fuera de convocatorias, exámenes y matrículas, y dejo margen para volver atrás. No fijo la fecha antes de conocer el alcance: así evito actualizar de madrugada un domingo.
- 05
¿Qué cambio para no volver a esta situación?
Si no cambio el criterio con el que acepto extensiones y personalizaciones, es probable que la misma acumulación reaparezca en próximas actualizaciones. Ese cambio casi nunca figura en la planificación.
Diez comprobaciones antes de actualizar
Las tres primeras comprobaciones ofrecen una señal inicial del alcance. Decido si es mantenimiento o proyecto después de valorar también el salto entre versiones, los datos, las integraciones críticas, las dependencias del servidor, la ventana disponible y la reversión.
- El inventario de extensiones incluye la versión y el origen de cada una.
- Sé si hay modificaciones hechas sobre el núcleo.
- He comprobado si existe versión compatible de cada extensión.
- La prueba se hará sobre una copia protegida y representativa de producción. Anonimizaré los datos siempre que los recorridos lo permitan. Si resulta imprescindible conservar datos personales, limitaré los campos y el volumen, restringiré y registraré los accesos, aislaré y protegeré el entorno y fijaré un plazo de borrado.
- Sé si el salto es directo o necesita versiones intermedias.
- He comprobado que PHP, la base de datos, las extensiones, la arquitectura y los parámetros obligatorios están dentro de las versiones y condiciones admitidas por la versión de destino y por cada etapa intermedia.
- Los recorridos críticos están listados para probarlos después.
- Las integraciones tienen forma de comprobarse tras el salto.
- Existe un plan de vuelta atrás con su tiempo estimado.
- La ventana elegida no coincide con ninguna convocatoria.
Qué cambia según el punto de partida
Estimo esfuerzos muy distintos para el mismo trabajo según la distancia acumulada desde el punto de partida.
- Una versión por detrás
Clasifico la actualización como mantenimiento si no encuentro cambios en el núcleo, extensiones incompatibles ni integraciones críticas. Con un inventario y un entorno de pruebas, calculo varios días de ejecución. En los demás casos, mido el alcance antes de fijar el plazo.
- Dos o tres versiones
Compruebo si hay extensiones sin compatibilidad declarada y decisiones funcionales pendientes. Determino el alcance a partir de las versiones exactas, el inventario y las integraciones. Si encuentro incompatibilidades, preparo un plan y asigno una persona responsable a la actualización.
- Salto largo entre versiones, con etapas intermedias
Lo planteo como un proyecto en toda regla: encadeno varias actualizaciones, pruebo cada una y decido qué elementos no sobreviven al salto.
- Con desarrollos propios importantes
Adapto además el código propio a las interfaces nuevas. Unas pruebas automatizadas relevantes y fiables pueden reducir mucho el esfuerzo y el riesgo de la adaptación; el efecto depende de su cobertura, su calidad y el entorno que reproducen.
Decisiones que no funcionan
Tres decisiones que aplazan la solución y la encarecen.
Aplazar un año más
Analizo el efecto de cada año de aplazamiento: aumenta la distancia respecto de las versiones vigentes, reduce el periodo de soporte que queda y puede dejar más extensiones sin una versión compatible. También valoro el coste, que puede crecer aunque el aplazamiento solo gane tiempo a corto plazo.
Actualizar y arreglar lo que falle
Preparo un inventario antes de actualizar para reducir el riesgo de descubrir los fallos en producción, con usuarios dentro. No recorto esa preparación: hacerlo aumenta el riesgo de encontrar incidencias durante la actualización.
Empezar de cero con una instalación nueva
No considero que empezar de cero sea un atajo. Comparo una actualización por etapas con una migración a una instalación nueva según la versión de origen, las modificaciones, la integridad de los datos, el histórico que debe conservarse y las pruebas disponibles. En muchos casos, elijo actualizar porque reduce el riesgo; en otros, opto por una reconstrucción controlada porque ofrece una salida más segura.
Qué exigir sobre actualizaciones en un pliego
Exijo estas condiciones para evitar heredar una plataforma que no pueda actualizar ni migrar.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Mantenimiento del inventario de extensiones | Listado con versión, origen y responsable de mantenimiento | Inventario actualizado en cada entrega |
| Prohibición de modificar el núcleo | Declaración y comprobación automática de integridad | Ninguna modificación en los archivos del núcleo distribuidos para la versión declarada; las diferencias legítimas de configuración, extensiones y datos quedan fuera de esta comprobación |
| Entorno de pruebas representativo | Versiones de la aplicación, de sus dependencias y de sus extensiones; configuración e integraciones críticas; perfil de recursos; datos representativos y minimizados; y recorridos que se comprobarán | Enumerar las condiciones relevantes de producción y ensayar la actualización completa en el entorno de pruebas antes de aplicarla en producción |
| Compromiso de mantener una versión con soporte | Plan de actualización periódica dentro del periodo de soporte | La versión desplegada permanece dentro de su periodo de soporte; el contrato fija el plazo de actualización y cómo resolver las dependencias que puedan impedir la actualización. |
| Plan de vuelta atrás | Procedimiento y tiempo estimado de reversión | Reversión probada en el entorno de pruebas |
Referencias
Fuentes y límites
- Documentación oficialActualizar Moodle — documentación oficial
Copias previas, prueba sobre una copia del sitio de producción, comprobación de extensiones en el directorio y versiones desde las que se admite el salto. Consultado el 1 de agosto de 2026.
- Documentación oficialDirectorio de extensiones de Moodle
Compatibilidad declarada de cada extensión por versión. Consultado el 1 de agosto de 2026.
- Documentación oficialVersiones y calendario de soporte
Fechas de soporte general y de seguridad de cada versión. Consultado el 1 de agosto de 2026.
En las plataformas derivadas el calendario es otro: Totara mantiene su propio ciclo de versiones desde que se separó de Moodle, y una distribución gestionada como Open LMS decide cuándo aplica cada salto. El inventario de extensiones y las pruebas de regresión siguen siendo necesarios, pero su alcance, sus herramientas y sus criterios deben adaptarse a cada plataforma y versión. Las versiones concretas desde las que se admite el salto cambian con cada publicación, así que la cifra hay que comprobarla siempre en la documentación oficial y no en esta página. La estimación del alcance según la distancia acumulada responde a mi criterio, basado en actualizaciones concretas. La compatibilidad que declara una extensión en el directorio es la del autor y conviene verificarla en el entorno de pruebas, porque no siempre coincide con el comportamiento real.
Blog
Casos, pruebas y fuentes.
En el blog documento actualizaciones concretas, con el inventario, los saltos de versión, las pruebas y los límites de cada decisión.
Ir a blog.albertolarah.comContacto
Versiones sin actualizar que nadie se atreve a tocar
Miro de qué versión se parte, qué extensiones hay instaladas, si hay modificaciones sobre el núcleo y qué integraciones están en marcha. Con eso determino si la actualización exige mantenimiento, un proyecto o una combinación de ambos, y en qué proporción.
hola@albertolarah.comLinkedIn ↗