Une migration suppose :

• La construction d'une base de code intégrée.
• Une opération de transfert des données initialise et “évaluation” de la migration (on la fait une première fois pour évaluer les problèmes potentiels)
• On résout les points de blocage et on conduit des tests globaux de stabilité (parcours des cours, des interfaces, entrée dans les activités, vérification que toutes les ressources sont là et jouent correctement (par échantillonnage)
• La planification de la migration effective, avec un arrêt de service pendant le transfert.

Concernant l'effort de migration, il dépend de :

• La maturité de la version “standard” de moodle
• L'avancée de la disponibilité des plugins tiers sur la version cible

Chez APL :

Tous les plugins que nos utilisons sont testés, validés et exploités en moodle 3.6 Nous sommes en train de préparer les versions 3.7 , et les modifications ou “disruptions” sont mineures, voire nulles. Les prochaines versions de nos plugins sont amorcées avec un délai minimum de 6 mois après la publication d'une version Moodle Core, pour être sûr de pouvoir travailler sur une version suffisamment testée et stabilisée de la partie Standard.

Nous travaillons dans une optique de mutualisation forte de cet effort d'entretien général du parc de plugins. Tous les contributeurs à moodle sont dans la même logique. Nous distribuons sur l'ensemble de nos exploitations l'effort de mise à jour des fonctionnalités afin que personne ne soit en situation de devoir supporter le budget d'entretien que cela représente.

Les opérations d'assemblage et de mise à jour sont l'occasion donc de participer à cet entretien continu qui est la contrepartie logique du modèle open-source où le coût d'acquisition est “nul”.

Guide de démarrage/FAQ sur Moodle - Voir le Catalogue des services - Aller à l'index des plugins