Twee heel verschillende projecten die "Moodle migratie" heten
Wanneer een organisatie over een Moodle migratie praat, bedoelt ze een van twee dingen. Of ze stappen over naar Moodle vanaf een ander leerplatform (aNewSpring, Studytube, Totara, Canvas of een zelfgebouwd LMS), of ze brengen een bestaande Moodle-installatie vooruit, van een legacy 2.x- of 3.x-versie naar een actuele 5.x-release. Beide zijn migraties. Beide mislukken op voorspelbare manieren wanneer ze worden behandeld als een ICT-vinkje in plaats van een gepland project.
Bij Ldesign Media voeren we beide scenario's al uit sinds 2010: LMS-migraties voor organisaties die commerciële platforms vervangen, en Moodle-upgrades voor omgevingen die al draaien sinds het Moodle 1.8- en 2.x-tijdperk. We ondersteunen elke Moodle-versie van 2.0 tot en met de nieuwste 5.2, wat betekent dat geen omgeving te oud is om veilig naar voren te halen. Deze gids behandelt beide scenario's en het stappenplan dat ze tot een succes maakt.
Scenario A: overstappen naar Moodle vanaf een ander LMS
Een leerplatform vervangen ("lms overstappen") is vooral een dataproject, geen software-installatie. Moodle zelf is in een dag ingericht. Het werk zit in het zonder verlies overbrengen van je gebruikers, cursussen, content en historie.
Wat wel en niet te migreren is
- Gebruikersaccounts. Namen, e-mailadressen en organisatiestructuur (afdelingen, cohorten) migreren goed via CSV of directe database-mapping. Wachtwoorden meestal niet: de meeste platforms slaan hashes op die Moodle niet kan verifiëren, dus plan een wachtwoord-resetflow of schakel tegelijk over naar SSO.
- Cursuscontent. SCORM-pakketten zijn per ontwerp overdraagbaar en importeren direct in de SCORM-activiteit van Moodle. Native content (pagina's, quizzen en opdrachten die in het oude platform zijn gebouwd) is niet overdraagbaar; die moet worden herbouwd of geconverteerd. Reserveer hiervoor tijd: het is consequent het meest onderschatte deel van een LMS-migratie.
- Voltooiingshistorie en certificaten. Bij verplichte trainingen hebben voltooiingsregistraties vaak juridisch gewicht. Exporteer ze uit het bronplatform, map ze naar de voltooiings- en cijferstructuren van Moodle, of archiveer ze in een rapportagelaag als live import niet zinvol is.
- SSO en integraties. Een platformwissel is het ideale moment om authenticatie naar je centrale identity provider te verplaatsen (Entra ID/Azure AD, SAML, OAuth2) en de HR-koppeling opnieuw te verbinden, zodat gebruikersvoorziening vanaf dag een automatisch verloopt.
Evalueer je specifiek de overstap weg van aNewSpring? Onze vergelijking van aNewSpring en Moodle behandelt de functionele en licentieverschillen in detail, en hoe een migratietraject eruitziet.
Praktisch advies voor de overstap
Draai waar mogelijk één inschrijvingsperiode beide platforms parallel. Migreer eerst een pilotgroep, valideer hun ervaring en hun voltooiingsdata, en verplaats pas daarna de hele organisatie. En bevries contentwijzigingen op het oude platform vanaf het moment dat de data-export is gemaakt, anders migreer je dezelfde cursussen twee keer.
Scenario B: een legacy Moodle-installatie upgraden
Het tweede scenario is een bestaande Moodle die is achtergebleven. We komen regelmatig Moodle 2.7, 3.1 of 3.5 in productie tegen: versies die al jaren geen beveiligingspatches meer ontvangen. Upgraden ("moodle upgraden") van deze versies naar 5.x is goed te doen, maar het is geen enkele knopdruk.
Waarom legacy-upgrades planning vereisen
- Stapsgewijs upgraden. Moodle ondersteunt geen sprong van 2.x direct naar 5.x in een stap. Afhankelijk van de beginversie loopt het upgradepad via tussenreleases, elk met eigen databasemigraties. Een Moodle 2.7-site upgrade bijvoorbeeld doorgaans via 3.x-mijlpalen voordat actuele versies bereikt worden.
- Plugincompatibiliteit. Elke geïnstalleerde plugin moet worden getoetst aan de doelversie. Community-plugins kunnen verlaten zijn; maatwerkplugins kunnen API's gebruiken die niet meer bestaan. Deze audit bepaalt de echte doorlooptijd van het project.
- Theme-rebuild. Themes uit het 2.x- en vroege 3.x-tijdperk overleven de overstap naar modern Moodle niet, dat is overgegaan op Bootstrap-gebaseerde theming. Een legacy-upgrade omvat bijna altijd een theme-rebuild of een overstap naar een onderhouden theme met jouw huisstijl toegepast.
- PHP- en databaseversies. Elke Moodle-versie vereist een passende PHP-versie. De stap van Moodle 2.x naar 5.x betekent meestal dat de serverstack zelf (PHP 5.x of 7.x naar PHP 8.2+) gelijk op moet met Moodle.
Organisaties vragen soms of ze Moodle niet beter schoon kunnen herinstalleren en content naar een nieuwe site kunnen migreren. Bij sterk aangepaste legacy-installaties kan dat oprecht de betere route zijn. De auditfase beantwoordt die vraag met feiten in plaats van onderbuikgevoel.
Het migratieplan, stap voor stap
Of je nu van platform wisselt of Moodle upgrade: de vorm van een succesvol project is dezelfde.
Stap 1: Inventarisatie en audit
Catalogiseer alles voordat je iets aanraakt: Moodle- of platformversie, geïnstalleerde plugins en hun doel, maatwerkcode, integraties (SSO, HR-systemen, betaalproviders), contentvolume, gebruikersaantallen en de rapportages waar de organisatie op leunt. Bij legacy Moodle-upgrades bepaalt deze audit het upgradepad en signaleert hij blokkerende plugins. Bij een LMS-wissel bepaalt hij wat gemigreerd, herbouwd of uitgefaseerd wordt.
Stap 2: Data-mapping
Bepaal waar elke datacategorie in de nieuwe omgeving landt: gebruikers naar accounts en cohorten, cursussen naar cursussen en categorieën, voltooiingen naar voltooiingsregistraties of een archief. Leg de mapping vast en laat de business owner er akkoord op geven. Halverwege de migratie ontdekken dat de voltooiingshistorie-mapping verkeerd is, is duur; hetzelfde ontdekken in een mappingdocument is gratis.
Stap 3: Testmigratie op een kopie
Oefen nooit op productie. Maak een volledige kopie van de bronomgeving, voer de complete migratie of upgrade uit op een stagingserver en meet alles: hoe lang duurt het, wat breekt, welke data overleeft het niet. Bij legacy Moodle-upgrades betekent dit ook de plugincompatibiliteitscontrole en de echte upgradescripts draaien, niet alleen de release notes lezen.
Stap 4: Validatie met echte gebruikers
Laat cursuseigenaren en een groep eindgebruikers de gemigreerde omgeving valideren. Controleer cursuscontent, cijferboeken, voltooiingsregistraties, certificaten en rapportages tegen de bron. Validatie door de mensen die eigenaar zijn van de data vangt de randgevallen die technische controles missen, zoals aggregatie-instellingen van het cijferboek die andere totalen opleveren dan het oude systeem.
Stap 5: Plan de cutover en downtime
Plan de productiemigratie in een rustig venster, communiceer de downtime vooraf, maak een laatste verse back-up of export en bevries contentwijzigingen. Een goed geoefende migratie betekent uren downtime in plaats van dagen, omdat elke stap al op staging is uitgevoerd.
Stap 6: Livegang, verificatie en een terugvaloptie
Verifieer na de cutover direct de kritieke flows: login en SSO, cursustoegang, een quizpoging, een voltooiingsregistratie, cron-uitvoering. Houd de oude omgeving voor een afgesproken periode alleen-lezen beschikbaar. Je zult hem zelden nodig hebben, maar die ene keer dat het wel zo is, is hij van onschatbare waarde.
Onze gratis Moodle upgrade checklist structureert deze stappen specifiek voor een legacy Moodle-upgrade: download hem als je een 3.x- of 4.x- naar 5.x-upgrade voorbereidt.
Valkuilen die we in de praktijk zien
Na vijftien jaar migraties herhalen de faalmodi zichzelf:
- Corrupte of incomplete back-ups. De bronback-up blijkt niet te restoren en het project staat op dag een stil. Test elke back-up door hem daadwerkelijk terug te zetten voordat de migratie begint.
- Maatwerkplugins die de upgrade blokkeren. Een organisatie is afhankelijk van een maatwerkplugin gebouwd voor Moodle 2.5, en niemand weet wie hem geschreven heeft. De plugin moet worden bijgewerkt, vervangen of uitgefaseerd voordat de upgrade verder kan. Als team dat meer dan 300 maatwerk Moodle-plugins heeft opgeleverd, is het bijwerken of herbouwen van verlaten maatwerkplugins een groot deel van ons migratiewerk.
- Randgevallen in cijferboek en voltooiing. Cijferhistorie, handmatige cijferoverschrijvingen en voltooiingsstatussen die door inmiddels verwijderde plugins zijn gezet, gedragen zich onverwacht na migratie. Die vragen expliciete validatie, geen aannames.
- Onderschatte content-rebuild. Native content uit het oude LMS is niet automatisch te converteren. Teams die dit halverwege ontdekken, hebben hun budget al aan de technische migratie besteed.
- Geen terugvalplan. De oude omgeving wordt de dag na livegang afgebouwd, en twee weken later heeft iemand een voltooiingsregistratie nodig die alleen daar bestaat.
Wanneer schakel je een Moodle-migratiespecialist in?
Kleine, standaard omgevingen migreren prima met een ervaren beheerder in huis. Schakel een Moodle migratie specialist in wanneer een van deze situaties geldt: de omgeving is sterk aangepast, de voltooiingshistorie heeft complianceswaarde, er zijn meerdere integraties (SSO, HR, e-commerce) in het spel, het versieverschil beslaat meerdere major releases, of het platform kan simpelweg geen mislukte eerste poging veroorloven. De kosten van specialistische hulp zijn voorspelbaar; de kosten van een mislukte migratie tijdens de inschrijfweek niet.
Ben je een LMS-overstap of een legacy Moodle-upgrade aan het plannen? Lees meer over onze diensten voor Moodle upgrade en migratie, download de upgrade checklist, of neem contact op om jouw omgeving te bespreken. Wij migreren en upgraden elke Moodle-versie van 2.0 tot en met 5.2.
