- Content-Portabilität und historische Lernrecords sind getrennte Migrationsprobleme.
- Vor dem Import muss klar sein, welche fachliche Aussage im Ziel erhalten bleiben soll.
- Migrieren, Archivieren und Neuaufbauen sind unterschiedliche Optionen.
- Ein grüner Importstatus ersetzt keine fachliche Abnahme.
Ein Kurs lässt sich exportieren. Eine PDF sowieso. Selbst standardisierte Lerninhalte können sich zwischen Plattformen bewegen. Damit ist ein LMS-Wechsel aber noch lange nicht erledigt.
Denn das alte System enthält nicht nur Inhalte. Es enthält Zustände: Wer war welchem Kurs zugewiesen? Wer hat wann abgeschlossen? Welcher Status galt dabei? Welche Zertifizierung läuft noch? Welche Historie hängt an welchem Nutzer und welcher Kursversion? Genau diese Beziehungen entscheiden nach dem Wechsel darüber, ob das neue LMS nur gefüllt aussieht oder ob es den bisherigen Lernbetrieb tatsächlich fortsetzen kann.
Eine LMS-Migration ist deshalb weniger ein Dateiumzug als eine Übersetzung zwischen zwei Datenmodellen. Wer das früh versteht, kann den Aufwand deutlich besser planen.
Der Kurs ist nicht die Lernhistorie
Die sichtbaren Objekte wirken zunächst einfach. Kurse, Videos, Dokumente oder Lernpakete lassen sich inventarisieren und auf technische Portabilität prüfen. Für bestimmte Arten von Lernmaterial gibt es dafür etablierte Standards. 1EdTech beschreibt Common Cartridge ausdrücklich als Format, mit dem digitale Lernmaterialien zwischen Lernplattformen importiert und exportiert werden können.
Die Lernhistorie liegt auf einer anderen Ebene.
SAP trennt in seiner Dokumentation für SuccessFactors Learning etwa zwischen Lernobjekten, Klassen, Registrierungen und Learning History. Adobe beschreibt für Learning Manager ebenfalls verschiedene Migrationsobjekte mit Abhängigkeiten zwischen Kursen, Modulen, Einschreibungen, Bewertungen und Zertifizierungen. Ein historischer Abschluss ist eben nicht nur eine Zeile mit dem Wert „erledigt“. Er verweist auf eine Person, ein Lernobjekt, einen Zeitpunkt und häufig weitere Regeln.
Kurse, Module, Dateien und Lernpakete beantworten vor allem die Frage, was bereitgestellt wird.
Identitäten, Zuweisungen, Abschlüsse, Ergebnisse, Zeitpunkte und Nachweise beantworten, was für wen tatsächlich passiert ist.
Was bei einer Migration tatsächlich zusammenhängt
Vor dem ersten Import lohnt sich eine Bestandsaufnahme nach Datenklassen. Nicht jede Organisation braucht dieselben Details. Die Trennung hilft aber, Abhängigkeiten sichtbar zu machen.
| Datenklasse | Typische Objekte | Kritische Frage |
|---|---|---|
| Inhalte | Kurse, Module, Dateien, Tests | Kann das Zielsystem Format und Struktur übernehmen? |
| Personen | Nutzer, IDs, Rollen, Gruppen | Bleiben Identitäten eindeutig zuordenbar? |
| Teilnahme | Einschreibungen, Zuweisungen, Programme | Lassen sich Beziehungen im Zielmodell abbilden? |
| Historie | Abschlüsse, Status, Ergebnisse, Zeitpunkte | Bleibt die fachliche Aussage des Datensatzes erhalten? |
| Nachweise | Zertifikate, Gültigkeiten, Wiederholungen | Kann das Ziel die relevante Historie weiterführen oder muss sie archiviert werden? |
| Betrieb | SSO, Schnittstellen, Automatiken, Regeln | Was muss neu konfiguriert statt migriert werden? |
Gerade bei historischen Daten wird die Semantik wichtig. Ein Feld im alten System und ein ähnlich benanntes Feld im neuen müssen nicht dasselbe bedeuten. SAP weist beispielsweise darauf hin, dass Abschlussdaten Einfluss darauf haben können, ob Lernobjekte in Lernplänen erneut erscheinen. Adobe verlangt für seine Migration, Quelldaten in vorgegebene Zielstrukturen zu überführen und dokumentiert Abhängigkeiten zwischen einzelnen Importobjekten.
Standards helfen, aber sie lösen nicht dasselbe Problem
Bei LMS-Migrationen fallen schnell Begriffe wie SCORM, xAPI oder andere Interoperabilitätsstandards. Sie sind wichtig. Man sollte ihnen nur nicht mehr zutrauen, als sie tatsächlich leisten.
Common Cartridge standardisiert beispielsweise die Verpackung und den Austausch digitaler Lernmaterialien. xAPI adressiert eine andere Ebene: Lernaktivitäten können als standardisierte Statements an einen Learning Record Store gesendet und dort wieder abgerufen werden. Das macht Lernereignisse technisch unabhängiger von einer einzelnen LMS-Oberfläche.
Daraus folgt aber keine universelle Migrationsautomatik. Ein Zielsystem muss die übernommenen Informationen weiterhin fachlich sinnvoll verwenden können. Ein vorhandenes xAPI-Statement ist nicht automatisch dasselbe wie ein nativer Abschlussstatus, eine gültige Zertifizierung oder eine Zuweisungsregel im neuen LMS. Umgekehrt kann ein portables Kurspaket sauber starten, während die historische Teilnahme dazu separat übertragen werden muss.
Die technischen Unterschiede zwischen SCORM, xAPI und cmi5 sind ein eigenes Thema. Für die Migration reicht als Arbeitsregel: Content-Portabilität und Record-Portabilität getrennt prüfen.
Erst Bedeutung mappen, dann Daten bewegen
Ein belastbarer Migrationsplan beginnt nicht mit dem Exportknopf. Er beginnt mit einer Entscheidung pro Datenklasse.
Aktive und historische Objekte inventarisieren: Inhalte, Nutzer, Zuweisungen, Abschlüsse, Nachweise, Programme, IDs und relevante Betriebslogik.
Festlegen, welche fachliche Information nach dem Wechsel noch erkennbar oder ausführbar sein muss.
Nur dort migrieren, wo das Ziel die benötigte Aussage sinnvoll darstellen kann. Historie kann archiviert, Prozesslogik bewusst neu konfiguriert werden.
Nicht nur den einfachsten Kurs prüfen, sondern repräsentative Nutzer mit historischen Abschlüssen, offenen Programmen, Wiederholungen oder alten IDs.
Diese drei Dispositionsoptionen verhindern eine typische Fehlannahme: dass eine vollständige Migration zwangsläufig bedeutet, jedes alte Detail im neuen System nachzubauen.
Import erfolgreich ist nicht Migration erfolgreich
Migrationswerkzeuge melden technische Zustände: verarbeitet, fehlgeschlagen, erneut ausführbar. Adobe stellt dafür beispielsweise Statusinformationen und Fehlerprotokolle für Migrationsläufe bereit. Das ist notwendig, beantwortet aber noch nicht die fachliche Abnahme.
Dafür braucht es mindestens zwei Ebenen. Zuerst die Reconciliation: Stimmen erwartete und übernommene Mengen für die relevanten Objekte? Gibt es unerwartete Ausfälle, Dubletten oder Datensätze ohne Zielzuordnung?
Danach die fachliche Stichprobe: Zeigt das neue System bei repräsentativen Nutzern tatsächlich den erwarteten Zustand? Stimmen Abschlussdaten? Bleiben Beziehungen zu Kursen erhalten? Werden offene Zuweisungen korrekt behandelt? Funktionieren Berichte mit den übernommenen Datensätzen so, wie sie künftig gebraucht werden?
Je wichtiger historische Nachweise sind, desto weniger sollte sich die Abnahme auf einen grünen Importstatus verlassen.
Das bedeutet nicht, dass jede LMS-Migration kompliziert sein muss. Wenn Quelle und Ziel gut zusammenpassen, Daten sauber gepflegt sind und das Ziel passende Importwege bietet, kann vieles geradlinig laufen. Die eigentliche Arbeit besteht dann darin, diese Voraussetzungen früh zu beweisen statt sie stillschweigend anzunehmen.
Der sinnvollste Migrationsscope beginnt mit einer Frage
Welche Aussage muss nach dem Abschalten des alten LMS noch stimmen?
Von dort lässt sich rückwärts planen. Welche Daten braucht diese Aussage? Welche Beziehungen hängen daran? Kann das neue System sie fachlich abbilden? Was muss stattdessen archiviert oder neu konfiguriert werden? Und wie lässt sich nach dem Import nachweisen, dass das Ergebnis stimmt?
So wird aus einem unübersichtlichen „Wir müssen alles rüberziehen“ ein kontrollierbares Migrationsprojekt. Kurse sind dabei nur ein Teil. Die Lernhistorie ist der Teil, bei dem sich zeigt, ob der Wechsel wirklich gelungen ist.