Overstappen van LMS kan zonder dataverlies, maar niet vanzelf. Een LMS-migratie gaat goed als je vooraf weet wat per datatype meeneembaar is, de export uit het oude systeem regelt vóór je het contract opzegt, en een overgangsperiode inbouwt waarin beide systemen naast elkaar bestaan. De beslissing om te vertrekken is meestal al genomen; wat overblijft is de angst dat jaren aan certificaathistorie, behaalde diploma's en lopende voortgang vastzitten in het oude systeem. Die angst is deels terecht: niet alles kan mee, en wat wel mee kan, gaat zelden automatisch. Dit artikel zet op een rij wat je kunt meenemen, in welke volgorde je de migratie aanpakt en wat je bij je nieuwe leverancier regelt voordat je tekent.

Wat is een LMS-migratie?

Een LMS-migratie is het overzetten van gebruikers, leercontent, certificaten en voortgangsdata van het ene leerplatform naar het andere. De migratie omvat naast de data zelf ook het opnieuw inrichten van koppelingen met bijvoorbeeld het HR-systeem, en het opnieuw opbouwen van leerpaden en inschrijvingen in het nieuwe platform.

Vier datatypen verdienen een toelichting.

Certificaathistorie. Behaalde certificaten kunnen vrijwel altijd mee, maar de vorm maakt het verschil. Een PDF-dossier per medewerker is een archief: het bewijst wat er is behaald, maar het nieuwe systeem kan er niets mee. Voor organisaties die met VCA of BHV werken is dat een probleem, want bij een audit moet aantoonbaar zijn wie wanneer welk certificaat heeft behaald én wanneer hercertificering nodig is. Eis daarom dat certificaathistorie als levende data wordt geïmporteerd, met behaaldatum en vervaldatum per certificaat, zodat het nieuwe systeem er direct op kan signaleren.

Voortgang in lopende cursussen. Dit is het meest onderschatte datatype. Wie halverwege een e-learning zit, is die voortgang bij de overstap vrijwel altijd kwijt: voortgangsdata is opgeslagen in het formaat van het oude platform en laat zich zelden vertalen. De werkbare strategie is plannen: laat medewerkers lopende cursussen afronden vóór de overgangsdatum, en laat trajecten die dan nog niet af zijn bewust opnieuw beginnen in het nieuwe systeem.

Eigen content. E-learnings die als SCORM- of xAPI-pakket zijn gebouwd, verhuizen doorgaans probleemloos. SCORM en xAPI zijn standaarden waarmee e-learningcontent onafhankelijk van het platform verpakt wordt, vergelijkbaar met een PDF die in elke lezer opent. Content die in de auteursomgeving van de oude leverancier is gebouwd, in een eigen formaat, kan vaak niet mee en moet opnieuw worden gebouwd of vervangen.

Koppelingen. Een SSO-koppeling of een koppeling met het HR-systeem, zoals AFAS, verhuist nooit mee. Het zijn geen data maar configuraties, en die worden in het nieuwe platform opnieuw gebouwd en getest. Plan daar tijd voor in: de HR-koppeling bepaalt of nieuwe medewerkers automatisch in het leerplatform komen, en is daarmee een van de eerste dingen die moeten werken.

Het migratie-stappenplan in 8 stappen

Stap 1: Inventariseer je data en content

Een LMS-migratie begint met een volledige inventarisatie van wat er in het oude systeem staat: gebruikers, certificaten, e-learnings, leerpaden, rapportages en koppelingen. Leg per onderdeel vast wat de bron is: staat de waarheid in het LMS zelf, in het HR-systeem of in een los bestand? Het toetsbare eindpunt van deze stap is één lijst met alle datatypen, aantallen en bronnen. Zonder die lijst is elke volgende stap giswerk.

Stap 2: Bepaal wat mee moet, wat gearchiveerd wordt en wat weg kan

Niet alles verhuizen is een voordeel, geen tekortkoming. Gebruik de tabel hierboven om per datatype te besluiten: mee als levende data, mee als archief, of bewust achterlaten. Verouderde cursussen, oud-medewerkers en rapportages van jaren geleden hoeven het nieuwe systeem niet in; certificaathistorie van actieve medewerkers wel. Het resultaat van deze stap is een migratielijst met drie kolommen: mee, archief, weg.

Stap 3: Regel de export uit je oude LMS vóór je opzegt

Zeg het oude contract pas op als de export geregeld en getest is. Vraag je huidige leverancier schriftelijk naar het exportformaat, de kosten van een volledige export en de termijn waarop die geleverd wordt. Na een opzegging verandert de verhouding: je bent geen klant meer maar een vertrekkende partij, en dan is elke exportvraag afhankelijk van goodwill. Toetsbaar punt: er staat een complete proefexport op je eigen server voordat de opzegbrief de deur uitgaat.

Stap 4: Maak een datamapping met je nieuwe leverancier

Een datamapping legt vast welk veld uit het oude systeem naar welk veld in het nieuwe systeem gaat, en wie de conversie uitvoert. Certificaatnamen, functieprofielen en afdelingsstructuren heten in elk platform anders; zonder mapping belandt data op de verkeerde plek of valt ze stilletjes weg. Spreek ook af wie verantwoordelijk is voor datakwaliteit: schoont de leverancier dubbele accounts op, of lever jij een geschoonde export aan?

Stap 5: Richt het nieuwe platform in, maar bouw het oude niet 1-op-1 na

De grootste ontwerpfout bij een migratie is het nieuwe systeem inrichten als kopie van het oude. De reden voor de overstap was juist dat het oude niet voldeed; wie elke map, elk leerpad en elke rapportage exact nabouwt, neemt de problemen mee. Ontwerp de nieuwe inrichting vanuit de vraag hoe het zou moeten werken, niet vanuit hoe het was. Toets elk onderdeel van de oude inrichting: houden we dit omdat het goed werkt, of omdat het er altijd al was?

Stap 6: Test met een proefgroep en echte scenario's

Laat een proefgroep van bijvoorbeeld één afdeling het nieuwe platform gebruiken vóór de livegang, en test niet alleen of inloggen werkt, maar de scenario's die er echt toe doen: een nieuwe medewerker komt in dienst, een medewerker gaat uit dienst, een certificaat nadert de vervaldatum, een manager draait een rapportage-export voor een audit. Elk scenario dat hier faalt, faalt anders na livegang bij honderden medewerkers tegelijk.

Stap 7: Draai parallel en bevries het oude systeem

Plan een overgangsperiode waarin het oude systeem bevroren is: niemand voert er nog iets in, het dient alleen als naslag. Alle nieuwe registraties gebeuren vanaf de bevriezingsdatum in het nieuwe platform. Zo ontstaat er geen periode waarin data in twee systemen tegelijk wordt bijgehouden, want dat is de snelste route naar een administratie die nergens meer klopt. De afweging tussen parallel draaien en een harde overstap staat in de volgende sectie.

Stap 8: Communiceer, ga live en houd het oude archief toegankelijk

Kondig de livegang ruim vooraf aan, met datum en reden, en zorg dat medewerkers weten wat er van hen verwacht wordt. Houd na livegang het gearchiveerde oude systeem of de export ervan nog toegankelijk voor het geval een auditor of medewerker iets uit de historie nodig heeft dat niet is gemigreerd. Spreek een vast evaluatiemoment af, bijvoorbeeld zes weken na livegang, om te controleren of alle data compleet is overgekomen.

Zo neem je je medewerkers mee in de overstap

Vier dingen die het verschil maken. Kondig de overstap ruim van tevoren aan, en benoem de reden: het oude systeem werkte ook voor medewerkers zelf niet prettig, en dat lost de overstap op. Laat medewerkers lopende cursussen afronden vóór de overgangsdatum, en wees eerlijk dat voortgang die dan nog openstaat niet meegaat; niets ondermijnt het vertrouwen sneller dan verdwenen voortgang waar niemand voor gewaarschuwd had. Geef per vestiging een korte instructie in het nieuwe platform, gericht op de twee of drie handelingen die medewerkers echt doen: inloggen, een cursus starten, een certificaat terugvinden. En wijs voor de eerste weken een vast aanspreekpunt aan per vestiging, zodat vragen niet blijven liggen tot iemand van HR langskomt.

Regel data-eigenaarschap vóór je tekent

Wie nu vastzit in een oud LMS, zit vaak vast omdat dit bij de vorige aanschaf niet geregeld is. Dit is dus de les van deze migratie: leg bij je nieuwe leverancier contractueel vast hoe je er ooit weer uit komt, vóórdat je klant wordt. Het hoort bij dezelfde leveranciersvragen die je stelt bij het kiezen van een nieuw LMS. Vijf punten voor het contract:

1. De data blijft van jou, ook na beëindiging. Laat expliciet in het contract opnemen dat alle gebruikersdata, certificaathistorie en eigen content eigendom blijven van jouw organisatie, en dat beëindiging van het contract daar niets aan verandert. Een leverancier die hier moeilijk over doet, vertelt je iets over hoe het vertrek later verloopt.

1. Exportformaat en -frequentie. Leg vast dat je op elk moment zelf een volledige export kunt draaien, zonder tussenkomst van de leverancier, en in welk formaat: gebruikersdata en certificaathistorie als CSV, eigen content als SCORM- of xAPI-pakketten. Een export die alleen de leverancier kan maken, is geen eigenaarschap maar een verzoek.

1. Kosten en termijn van een export bij vertrek. Vraag wat een volledige eindexport kost en binnen welke termijn die geleverd wordt, en laat beide vastleggen. Het antwoord "op aanvraag" of "in overleg" is een rode vlag: dat betekent onderhandelen op het moment dat je onderhandelingspositie het zwakst is.

1. Bewaartermijn na opzegging. Spreek af hoe lang de data na het einde van het contract beschikbaar blijft, zodat er tijd is om de migratie af te ronden en de eindexport te controleren voordat de omgeving verdwijnt.

1. Wat er met de data gebeurt na verwijdering. Leg in de AVG-verwerkersovereenkomst vast wanneer en hoe de leverancier de data definitief verwijdert na afloop van de bewaartermijn, inclusief back-ups, en dat je daar een bevestiging van ontvangt.

Veelgestelde vragen over overstappen van LMS

Wat is LMS-migratie?

LMS-migratie is het overzetten van gebruikers, leercontent, certificaten en voortgangsdata van het ene leerplatform naar het andere, inclusief het opnieuw inrichten van koppelingen en leerpaden in het nieuwe systeem. Het omvat zowel de technische dataoverdracht als de organisatorische overgang naar het nieuwe platform.

Hoelang duurt een LMS-migratie?

Dat verschilt per organisatie, van enkele weken tot enkele maanden. De doorlooptijd wordt vooral bepaald door de omvang van het personeelsbestand, de kwaliteit van de data in het oude systeem, het aantal koppelingen dat opnieuw gebouwd moet worden en de hoeveelheid eigen content die overgezet of herbouwd wordt.

Verliezen we data bij een overstap naar een nieuw LMS?

Niet als de migratie goed wordt voorbereid, maar niet elk datatype gaat automatisch of volledig mee. Gebruikersdata en SCORM-content verhuizen doorgaans goed, certificaathistorie gaat mee als de import goed wordt afgesproken, en voortgang in lopende cursussen gaat meestal verloren. De tabel eerder in dit artikel geeft het overzicht per datatype.

Kunnen we onze certificaathistorie meenemen naar een nieuw LMS?

Meestal wel, maar de vorm bepaalt de waarde. Als archief of PDF-dossier kan certificaathistorie vrijwel altijd mee; als levende data met behaaldatums en vervaldatums alleen als het nieuwe platform een archief-import ondersteunt. Voor organisaties die op hercertificering moeten sturen, is die levende variant de enige die volstaat.

Kunnen medewerkers hun voortgang in lopende cursussen behouden?

Meestal niet. Voortgangsdata is opgeslagen in het formaat van het oude platform en laat zich zelden overzetten. De praktische oplossing is lopende cursussen laten afronden vóór de overgangsdatum, en trajecten die dan nog openstaan opnieuw laten starten in het nieuwe systeem.

Moet het oude LMS blijven draaien tijdens de migratie?

Het oude LMS blijft tijdens de migratie beschikbaar, maar in bevroren toestand: er wordt niets meer in geregistreerd en het dient alleen als naslag. Of het daarna nog een periode als archief blijft draaien of direct wordt afgesloten, hangt af van de compliance-druk en het aantal lopende trajecten in de organisatie.

De volgorde is uiteindelijk belangrijker dan de snelheid: eerst weten wat per datatype meeneembaar is, dan de export uit het oude systeem regelen en testen, en pas daarna opzeggen. Wie die volgorde aanhoudt en bij de nieuwe leverancier het data-eigenaarschap vooraf vastlegt, stapt niet alleen zonder dataverlies over, maar voorkomt ook dat de volgende migratie net zo spannend wordt als deze.