Al elegir plataforma
Una organización recibe y compara tres opciones que parecen iguales salvo por el nombre. No busco la diferencia en la lista de funciones, sino en quién controla el ritmo de evolución.
Moodle · Ecosistema
Moodle™, Totara y Open LMS comparten parte de su origen técnico. El margen para desarrollar, actualizar, operar y preparar la salida cambia con la plataforma, la forma de alojarla y gestionarla y el contrato.
He trabajado con Moodle y con plataformas construidas sobre su base. El origen compartido me ayuda a orientarme, pero no doy por hecho que una extensión o una actualización funcionen igual, ni que un contrato o una estrategia de salida sean equivalentes. Explico las diferencias que he tenido que considerar al desarrollar, integrar, operar o evolucionar cada entorno.
- He trabajado con instalaciones propias de la organización, con distribuciones gestionadas por un proveedor y con plataformas derivadas del mismo código.
- La relación con Moodle ayuda a formular preguntas sobre datos, roles, banco de preguntas, copias y carga, pero cada mecanismo debe comprobarse en el producto y la versión concretos.
- Lo que cambia es el margen de decisión: quién actualiza, qué se puede instalar y con cuánta libertad se puede desarrollar sobre la plataforma.
- Aquí cuento qué he visto en cada una, no comparo catálogos comerciales.
Experiencia en ecosistema
Comparo Moodle™, Totara y Open LMS por su arquitectura, ciclo de actualización, compatibilidad de extensiones, margen de desarrollo y modelo de operación. Identifico la divergencia acumulada entre plataformas, compruebo quién controla cada ciclo y preparo la salida sin tratar una migración entre productos de la misma familia como una actualización ordinaria.
Mi trayectoriaCuándo he necesitado identificar la edición con la que trabajaba
Rara vez me plantean la pregunta así. La reconozco detrás de una decisión atascada: nadie ha expresado con claridad el margen real.
Al querer desarrollar algo propio
Distingo ambas situaciones por el margen de decisión. En una instalación bajo vuestro control, podéis decidir y programar la incorporación de una extensión tras comprobar su compatibilidad, seguridad, mantenimiento y procedimiento de reversión. En una plataforma gestionada, las condiciones fijan qué podéis instalar y cuándo.
Al heredar una plataforma
Identifico la base técnica de un campus que me llega años después de que alguien lo montara. De ella depende el margen de maniobra, así que no prometo nada antes.
Al plantearse un cambio
Determino de antemano qué se conserva y qué se rehace al salir de una distribución gestionada o al moverse entre plataformas del mismo tronco.
Cómo decido, o cómo entiendo lo que ya tenéis
Planteo cinco preguntas. No respondo ninguna mirando una tabla de funcionalidades.
- 01
¿Quién quiere decidir cuándo se actualiza?
Compruebo que el contrato reserve a la organización el margen para decidir la ventana de actualización: algunas modalidades gestionadas fijan el calendario y otras acuerdan las ventanas con la propia organización. Si prefiere delegar la operación, comparo responsabilidades, niveles pactados de disponibilidad y atención, y opciones de salida antes de tomar una decisión.
- 02
¿Vais a desarrollar algo propio?
Si la respuesta es sí, miro antes qué margen deja cada opción para instalar y mantener ese desarrollo, y qué le pasa en cada actualización.
- 03
¿La formación es corporativa, con jerarquías y requisitos de cumplimiento?
En las versiones que he revisado, Totara incorporaba funciones corporativas que en Moodle LMS estándar resolví con extensiones y trabajo adicional. Compruebo el alcance en cada producto y versión, y comparo Moodle Workplace por separado.
- 04
¿Qué pasa si queréis salir dentro de tres años?
Planteo la pregunta al firmar, no al preparar la salida. Compruebo que queden por escrito los formatos de exportación, la propiedad de los desarrollos y el procedimiento de salida.
- 05
¿Cuánta gente hay para operar?
He comprobado que la capacidad operativa disponible es uno de los factores que más veces determina la decisión. He visto instalaciones propias acabar desatendidas por falta de equipo; una plataforma desatendida supone un riesgo de seguridad.
Qué aplico igual en todas y qué compruebo cada vez
Divido el análisis en cuatro planos. En los dos primeros explico qué razonamiento se transfiere entre plataformas; en los dos últimos, qué debe comprobarse en cada combinación de producto, modelo de operación y contrato.
- 01
Los conceptos heredados
Reviso el modelo de datos, los cursos y categorías, los roles y contextos, el banco de preguntas, las actividades, las copias y restauraciones y las tareas en segundo plano. Aplico parte del mismo razonamiento a distintas plataformas porque comparten conceptos, pero compruebo cada solución, edición y versión: cómo implementa esos conceptos, qué límites impone y qué herramientas de administración ofrece.
- 02
La distancia acumulada
La evolución independiente puede acumular divergencias respecto al tronco común. Mido esa distancia en la versión concreta, sus API, formatos y herramientas, no solo por el tiempo transcurrido. En la práctica, doy por bueno el razonamiento, pero no la ruta de la interfaz ni el nombre del ajuste.
- 03
Quién controla el ciclo
Distingo el control del ciclo por el modelo de operación y el contrato, no por el linaje de la solución. En una instalación gestionada por la organización, esta programa y aplica las actualizaciones durante el periodo de soporte. En una plataforma gestionada o SaaS, el proveedor o el fabricante fija las versiones admitidas; el contrato concreta quién decide la fecha y quién ejecuta el cambio. Compruebo estas condiciones en cada modalidad concreta de Moodle, Totara u Open LMS.
- 04
El margen para construir
Compruebo qué extensiones admite la plataforma, si permite modificar el tema, si da acceso a la base de datos y en qué condiciones. Una comparación por funcionalidades engaña especialmente en este punto: dos plataformas pueden hacer lo mismo hoy y dejaros un margen muy distinto para lo que necesitéis mañana.
Lo que he visto salir mal
Seis errores que he encontrado al heredar plataformas que parten de este tronco o al compararlas.
Comparar versiones que no son equivalentes
He visto comparar una versión reciente de una plataforma con una antigua de otra. Esa comparación no permite atribuir las diferencias a la plataforma, porque también pueden deberse a la antigüedad de las versiones comparadas.
Dar por hecho que las extensiones son intercambiables
Comparten interfaces, pero cada plataforma ha evolucionado por su cuenta. Compruebo la compatibilidad en un entorno de pruebas.
No aclarar quién decide la actualización
Quién decide la actualización suele ser una de las diferencias prácticas más importantes entre modalidades y contratos. Casi nunca encuentro ese dato en las comparativas comerciales.
Dejar la salida para después de contratar
Con una distribución gestionada, acuerdo las condiciones de reversibilidad antes de firmar; negociarlas de nuevo después suele resultar más difícil.
Dar por hecho que el conocimiento de una plataforma no sirve para otra
El error contrario también existe: conocer Moodle me ayuda a formular hipótesis sobre datos, roles, carga y copias. Después las confirmo en la plataforma y la versión concretas. Si trato las plataformas como mundos sin relación, también desaprovecho conocimiento transferible.
Comparar solo el precio de la licencia o del alojamiento
Considero determinante el coste de operar y mantener lo que construyo sobre la plataforma.
Tres suposiciones que he visto salir caras
En las tres vi el mismo error: dar por hecho que compartir origen significa ser intercambiables.
Dar por hecho que una extensión funciona en las tres
Comparten origen y parte de los conceptos técnicos, pero compruebo las API, las extensiones y las herramientas de cada solución y cada versión, porque han evolucionado por separado. También reviso qué instala cada distribución gestionada. Compruebo la compatibilidad; no la doy por supuesta.
No comparo las plataformas solo por su lista de funcionalidades
Sobre el papel, las veo parecidas porque comparten la misma base. Para decidir entre ellas, reviso la operativa: quién actualiza, con qué margen y qué pasa si queréis salir.
No trato una migración entre productos como una actualización ordinaria
Utilizo los conceptos y formatos compartidos como punto de partida para planificar la transferencia de cursos y usuarios. Valido qué puede importarse, qué pierde información y qué debe rehacerse.
Qué cambia según el contexto
Ajusto la respuesta al tamaño de la organización y al tipo de formación.
- Organización pequeña sin equipo técnico
Para una organización sin equipo técnico, elijo una distribución gestionada o una solución en la nube para evitar que gestione directamente la infraestructura. Dejo por contrato el calendario de cambios, los compromisos operativos, el acceso a los datos, las responsabilidades de seguridad y el procedimiento de salida.
- Universidad o centro con equipo propio
En una universidad o centro con capacidad operativa comprobada, valoro que la organización controle la instalación si dispone de personal, procedimientos y cobertura suficientes para conciliar el soporte, la seguridad y el calendario académico.
- Formación corporativa con requisitos de cumplimiento
En las versiones de Totara que he revisado, varias funciones corporativas venían integradas. En mis proyectos con Moodle LMS estándar exigieron extensiones y mantenimiento adicional. Antes de decidir, comparo también Moodle Workplace y las versiones actuales de cada producto.
- Varias organizaciones sobre la misma plataforma
Valoro esta decisión junto con la arquitectura multitenant o multiinstancia, que suele pesar más que la elección de plataforma.
Qué exijo en un pliego al comparar plataformas
Fijo estos criterios antes de comparar plataformas. Así evito comparar peras con manzanas y descubrir el margen real después de firmar.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Plataforma y versión declaradas | Nombre de la plataforma, versión y calendario de soporte | Comparar todas las ofertas a partir de versiones vigentes |
| Quién decide la actualización | Procedimiento y plazos para aplicar las versiones | Versión desplegada dentro de su periodo de soporte. Plazo de actualización y forma de tratar las dependencias, por escrito |
| Margen para desarrollar | Qué extensiones se pueden instalar y con qué procedimiento | Instalación de prueba de una extensión propia en el entorno ofertado |
| Derechos, entrega y continuidad | Licencias identificadas, código fuente, documentación y procedimientos de construcción y despliegue | La organización dispone de los derechos de uso, modificación y continuidad acordados. La titularidad de los desarrollos a medida solo pasa a la organización cuando procede y el contrato lo recoge. |
| Plan de salida | Procedimiento de exportación en formatos reutilizables | Prueba real de exportación durante la vigencia del contrato |
Diez preguntas antes de elegir una plataforma o de heredarla
Uso estas preguntas tanto para comparar ofertas como para entender la plataforma que habéis heredado.
- Sé sobre qué plataforma y qué versión exacta está construido el campus.
- Sé quién decide cuándo se actualiza y con cuánto preaviso.
- Sé qué extensiones puedo instalar y cuáles no.
- Sé si puedo tocar el tema y la interfaz, y hasta dónde.
- Sé qué licencias, derechos de uso, modificación y continuidad se aplican a cada componente y qué titularidad se ha acordado para los desarrollos a medida.
- Sé cómo se exportan los datos y en qué formato.
- Sé qué parte de las copias y la seguridad es responsabilidad mía.
- He comparado versiones equivalentes, no una nueva contra una antigua.
- He comprobado la compatibilidad de las extensiones que necesito.
- He sumado el coste de operar, no solo el de licencia o alojamiento.
Referencias
Fuentes y límites
- Documentación oficialTotara — «Focusing on our mission: an open source fork of Moodle»
La propia Totara declara la separación como fork y explica su motivo. Consultado el 2 de agosto de 2026.
- Documentación oficialOpen LMS — Quiénes somos
Se describe como plataforma basada en Moodle y detalla su recorrido: Moodlerooms en 2005, adquisición por Blackboard en 2012 y por Learning Technologies Group en 2020. Consultado el 2 de agosto de 2026.
- Documentación oficialMoodle — Productos y proveedores certificados
Familia de productos de Moodle y red oficial de proveedores. Consultado el 2 de agosto de 2026.
Esta página compara cómo se comportan estas plataformas ante decisiones técnicas, no sus catálogos de funcionalidades: eso cambia con cada versión y lo publica cada fabricante. La proporción de código que compartían al separarse la declararon en su momento las partes implicadas y no la he verificado sobre el código, así que no la cito como dato. Mi experiencia directa es mucho mayor con Moodle que con las otras dos, y conviene tenerlo en cuenta al leer lo que aquí se afirma.
Blog
Casos, pruebas y fuentes.
En el blog comparo decisiones de Moodle, Totara y Open LMS a partir de versiones, contratos y condiciones operativas concretas.
Ir a blog.albertolarah.comContacto
Elegir plataforma, o entender la que se ha heredado
Empiezo por cuatro datos: qué tipo de formación se imparte, si hay equipo que opere la plataforma, si va a haber desarrollo propio y, cuando ya hay contrato, qué margen deja.
hola@albertolarah.comLinkedIn ↗