So bereiten Sie Ihre Online-Schule auf eine LMS-Migration vor

In einer Präsentation wirkt der Wechsel der Lernplattform oft ganz einfach: Man klickt im alten System auf „Exportieren“ und im neuen auf „Importieren“ – schon sind alle Kurse in ihrer neuen Umgebung verfügbar. In der Realität ist eine solche Migration jedoch fast nie so unkompliziert. Im Laufe der Zeit sammelt sich in einer Online-Schule weit mehr an als nur Videos und Texte: Es entstehen Zugriffsrechte, Zahlungshistorien, Zertifikate, Testergebnisse, Domain-Einstellungen, E-Mail-Verläufe, Integrationen und spezifische Gewohnheiten der Lernenden.

Der wohl schwerwiegendste Fehler besteht darin, eine Migration lediglich als einmaliges Kopieren von Inhalten zu betrachten. Selbst wenn alle Lektionen erfolgreich übertragen wurden, kann es passieren, dass Lernende den Zugriff auf bereits gekaufte Programme verlieren, Mentoren keinen Einblick mehr in die Historie von Aufgaben haben oder die Finanzabteilung die Verknüpfung zwischen einer Zahlung und der zugehörigen Bestellung verliert.

Betrachten Sie die Migration als ein kleines IT-Projekt – mit einer verantwortlichen Person, einer Bestandsaufnahme, einer Pilotphase, einem Plan für den Fall eines Rollbacks (Rückgängigmachen der Änderung) sowie einem Kommunikationsplan. Die gute Nachricht: Die meisten Risiken lassen sich bereits identifizieren, bevor die Hauptdomain tatsächlich auf das neue System umgestellt wird.

Analysieren Sie zunächst genau, was am alten LMS problematisch ist.

Eine neue Plattform mag zwar moderner aussehen, doch das allein reicht als Lösung nicht aus. Formulieren Sie die bestehenden Probleme anhand konkreter Szenarien. Beispiele: Ein neuer Lernender erhält erst Stunden nach der Zahlung manuell Zugriff; Kursautoren können Lektionen nicht schnell genug anpassen; Mentoren verbringen einen ganzen Tag mit der manuellen Erstellung von Berichten; die mobile Benutzeroberfläche ist unpraktisch; oder die Kosten für die Plattform steigen schneller als die Anzahl der aktiven Lernenden.

Unterteilen Sie die Probleme anschließend in drei Kategorien: technische Einschränkungen des Produkts, Konfigurationsfehler oder Schwachstellen in Ihren eigenen internen Prozessen. Manchmal ist tatsächlich ein neues LMS erforderlich; in anderen Fällen werden die Möglichkeiten des bestehenden Systems nicht voll ausgeschöpft oder die interne Organisation ist schlichtweg unübersichtlich. Eine Migration löst keine Probleme mit unübersichtlichen Zugriffsregeln, indem man sie einfach nur kopiert.

Erstellen Sie eine kurze Entscheidungstabelle: Was ist das Problem? Welche Kosten entstehen? Lässt es sich ohne Migration lösen? Wie werden Sie das neue System testen? Dies hilft zu verhindern, dass die Migration zu einer endlosen Wunschliste ausartet, die das Budget immer weiter in die Höhe treibt.

Bestandsaufnahme: Was muss tatsächlich übertragen werden?

Beginnen Sie mit dem Kursverzeichnis. Erfassen Sie für jeden Kurs: Titel, Eigentümer, Veröffentlichungsstatus, Anzahl der Lektionen, Format der Materialien, zugehörige Tests, Hausaufgaben, Zertifikate, aktive Teilnehmer, Zahlungsmethode sowie spezielle Zugriffsregeln.

Erstellen Sie separat ein Nutzerverzeichnis: Wer hat auf welche Programme Zugriff, auf welcher Grundlage, bis zu welchem ​​Datum? Wie ist der aktuelle Fortschritt, und gibt es noch offene Aufgaben? Oft stellt sich heraus, dass Zugriffsregeln nicht nur im LMS (Lernmanagementsystem) existieren, sondern auch im CRM, im Zahlungssystem oder in einer Tabelle der Verantwortlichen.

Die Marketing-Infrastruktur bildet eine weitere Ebene. Landingpages, Analysetools, Tracking-Pixel, E-Mail-Automatisierungen, UTM-Tags, Zahlungsseiten und Domains können von der aktuellen Plattform abhängen. Wenn Sie diese erst nach der Übertragung der Kursinhalte berücksichtigen, riskieren Sie den Verlust von Leads und die Nachvollziehbarkeit von Verkäufen.

Vergessen Sie nicht Inhalte, die zunächst zweitrangig erscheinen: Kommentare zu Hausaufgaben, Notizen von Mentoren, Webinar-Aufzeichnungen, zusätzliche Dateien oder Fragen von Teilnehmenden. Entscheiden Sie, was migriert, was archiviert und was bewusst nicht in das neue System übernommen werden soll.

Drei verschiedene Aufgabenbereiche: Inhalte, Nutzer und Lernhistorie.

Es kann vorkommen, dass Materialien erfolgreich übertragen werden, während die Lernhistorie (der Fortschritt) verloren geht. So lässt sich beispielsweise ein Kurs, der in einem externen Autorentool erstellt wurde, unter Umständen als SCORM-Paket übertragen – sofern die neue Plattform die entsprechende Version unterstützt. Das bedeutet jedoch nicht, dass auch frühere Noten oder Kommentare von Mentoren mit importiert werden.

Benutzerdatensätze enthalten nicht automatisch Zugriffsrechte. Ein CSV-Export kann zwar Namen und E-Mail-Adressen umfassen, lässt jedoch möglicherweise Abonnementregeln, Zugriffszeiträume und Gruppenzugehörigkeiten aus. Klären Sie vor dem Import, wie diese Felder im neuen System abgebildet werden sollen.

Die Übertragung der Lernhistorie ist oft der schwierigste Teil. Entscheiden Sie, ob jeder Testversuch beibehalten werden muss oder ob das Endergebnis und das Abschlussdatum ausreichen. Bei Zertifizierungsprogrammen kann diese Entscheidung rechtliche und vertragliche Auswirkungen haben; treffen Sie sie daher nicht allein im Hinblick auf eine Vereinfachung des Imports.

So erstellen Sie eine Datenzuordnungstabelle (Mapping-Tabelle)

Erstellen Sie vor jedem Massenimport eine Zuordnungstabelle – eine Übersicht, die zeigt, wie Daten aus dem alten System in das neue System überführt werden. So könnte beispielsweise die „course_id“ (Kurs-ID) in einem alten LMS einer neuen Kurs-ID entsprechen, während der „completion_status“ (Abschlussstatus) einem bestimmten Satz von Statuswerten zugeordnet wird.

Legen Sie für jedes Feld die Quelle, das Ziel, die Konvertierungsregel, den Verantwortlichen sowie die Validierungsmethode fest. Wenn ein System einen Abschluss beispielsweise als das Durcharbeiten aller Lektionen definiert, während ein anderes das Bestehen einer Abschlussprüfung voraussetzt, können die Statuswerte nicht einfach als gleichwertig betrachtet werden. Stimmen Sie sich darüber ab, was die jeweiligen Daten bedeuten.

Eine gute Zuordnungstabelle berücksichtigt auch Ausnahmefälle: Benutzer mit mehreren Konten, im Laufe der Zeit umbenannte Kurse, abgelaufene Zugriffsrechte sowie Lernende, die ihre E-Mail-Adresse geändert haben. Identifizieren Sie solche Fälle bereits in der Testphase, anstatt sie erst in der Nacht vor der endgültigen Umstellung manuell lösen zu müssen.

Pilotphase: Ein komplexer Kurs ist aussagekräftiger als zehn einfache Kurse

Für eine Pilotphase wird oft der einfachste Kurs gewählt, um schnell Erfolge vorweisen zu können. Das Problem dabei ist, dass so keine tieferliegenden Risiken aufgedeckt werden. Es ist sinnvoller, ein Programm zu wählen, das Videos, Tests, Hausaufgaben, aktive Lernende, Zahlungsabwicklungen und spezielle Zugriffsrechte umfasst.

Stellen Sie eine Testgruppe zusammen, die Lernende, Mentoren, Autoren und Administratoren umfasst. Bitten Sie sie, den gesamten Prozess zu durchlaufen: Zugang erhalten, anmelden, eine Lektion ansehen, eine Aufgabe einreichen, diese bewerten lassen, den Kurs abschließen und ein Zertifikat oder Ergebnis erhalten.

Testen Sie auch Fehlerszenarien. Was passiert, wenn ein Kursteilnehmer doppelt bezahlt, seine E-Mail-Adresse ändert oder einen unvollständigen Test hat? Was ist, wenn ein Mentor nicht mehr an der Schule tätig ist? Solche Fälle tauchen in Demos selten auf, führen aber nach dem Start häufig zu Support-Anfragen.

Zahlungen: Kursteilnehmer lassen sich nicht einfach „übertragen“.

Das Zahlungssystem ist ein separater Teil der Migration. Es speichert Informationen zu Bestellungen, Rückerstattungen, Abonnements, Karten-Tokens und Transaktionsstatus. Nicht alle diese Daten können automatisch zwischen Plattformen übertragen werden – manchmal ist dies rechtlich oder technisch gar nicht möglich.

Falls die Schule aktive Abonnements hat, klären Sie vorab, ob diese übernommen werden können, ohne dass der Kunde eine erneute Autorisierung vornehmen muss. Andernfalls sind eine gezielte Kommunikation mit den Kunden sowie eine neue Zahlungsvereinbarung erforderlich. Gehen Sie nicht davon aus, dass das neue LMS die bestehenden wiederkehrenden Zahlungen automatisch fortsetzt.

Überprüfen Sie auch die Zahlungs-Webhooks: für erfolgreiche Zahlungen, Stornierungen, Rückerstattungen und ausstehende Zahlungen. Wenn diese Ereignisse mit dem falschen Preisplan verknüpft sind, kann der Zugang fälschlicherweise gewährt oder entzogen werden. Testen Sie den Zahlungsprozess anhand von Testbestellungen und verifizieren Sie jeden Status.

Domain, SEO und Analytik nach dem Wechsel

Eine Online-Schule verfügt möglicherweise über Kursseiten, die über Jahre hinweg Such-Traffic generiert haben. Wenn sich die URLs auf der neuen Plattform ändern, müssen Sie die alten und neuen Adressen einander zuordnen und gegebenenfalls entsprechende dauerhafte Weiterleitungen (Redirects) einrichten.

Leiten Sie nicht einfach alle alten Seiten auf die Startseite weiter. Wenn eine Kursseite ein direktes Pendant auf der neuen Plattform hat, führen Sie Nutzer und Suchmaschinen dorthin. Falls kein direktes Pendant existiert, treffen Sie für den Inhalt und den HTTP-Status dieser Seite eine jeweils individuelle Entscheidung.

Überprüfen Sie vor der Umstellung Metadaten, strukturierte Daten, die Sitemap, Canonical-Tags, die robots.txt-Datei, Analytics-Konfigurationen sowie Zahlungsereignisse. Vergleichen Sie die Berichte vor und nach dem Start. Andernfalls könnten Sie fälschlicherweise annehmen, dass die Nachfrage zurückgegangen ist – dabei wurde lediglich das Ereignis für den Kaufabschluss nicht mehr korrekt übermittelt.

Kommunikation mit Studierenden: Weniger Überraschungen

Kündigen Sie die Migration nicht erst eine Stunde vor dem Start mit einem rein technischen Hinweis an. Studierende benötigen konkrete Antworten: Bleibt bereits gekaufter Zugang erhalten? Ändern sich die Passwörter? Was passiert mit dem Lernfortschritt? Wo sind die Zertifikate zu finden? An wen können sie sich wenden, wenn die Anmeldung nicht funktioniert?

Eine Abfolge mehrerer Nachrichten ist meist sinnvoll: eine Vorabinformation, eine kurze Anleitung unmittelbar vor der Umstellung und eine Bestätigung nach dem Start. Überfrachten Sie die Nutzer nicht mit technischen Details aus dem Backend; verlinken Sie stattdessen auf eine übersichtliche Hilfeseite.

Das Support-Team muss vorab instruiert werden. Erstellen Sie eine Liste häufiger Fragen, legen Sie Kriterien für die Eskalation fest und definieren Sie schnelle Wege zur Wiederherstellung des Zugangs. Wenn ein Studierender vor einer Prüfung nicht auf seine Lektion zugreifen kann, ist es für ihn unerheblich, ob die Migration „insgesamt erfolgreich“ verlaufen ist.

Der Umstellungsplan und die Rollback-Option

Die riskanteste Vorgehensweise besteht darin, die alte Umgebung unmittelbar nach dem Start der neuen zu entfernen. Es ist eine Kontrollphase erforderlich, in der das Team Daten vergleichen und Probleme beheben kann, ohne dass die ursprüngliche Umgebung bereits verloren gegangen ist.

Erstellen und verifizieren Sie vor dem Tag der Umstellung ein Backup, setzen Sie kritische Änderungen aus, dokumentieren Sie Importvorgänge und weisen Sie Verantwortlichkeiten zu. Definieren Sie klare Erfolgskriterien: die Verfügbarkeit der Kurse, korrekte Zahlungsabwicklung, funktionierende Anmelde- und Supportprozesse sowie den Erhalt kritischer Daten.

Erstellen Sie einen separaten Rollback-Plan. Unter welchen Bedingungen ist eine Rückkehr zum vorherigen System erforderlich? Wer trifft diese Entscheidung? Welche Änderungen, die nach dem Start vorgenommen wurden, müssten gegebenenfalls synchronisiert werden? Ein Rollback-Plan ist nützlich – selbst wenn er nie zum Einsatz kommt.

So bewerten Sie ein neues LMS – am Beispiel von WeStudy

Achten Sie bei der Evaluierung eines neuen Systems nicht nur auf das Design des Dashboards für Lernende. Lassen Sie sich einen echten Arbeitsablauf zeigen: Materialien importieren, einen Kurs erstellen, Zugriffsrechte vergeben, Zahlungen abwickeln, Tests durchführen, Aufgaben bewerten und Berichte erstellen. Jeder dieser Schritte sollte Ihre tatsächlichen Prozesse widerspiegeln.

Die LMS-Plattform WeStudy kommt möglicherweise für eine engere Auswahl infrage; ob sich jedoch spezifische Formate, Lernfortschritte, Zertifikate und Abonnements übertragen lassen, muss im Einzelfall geprüft werden. Nicht alle Funktionen der alten Plattform haben zwangsläufig ein direktes Pendant im neuen System.

Falls eine individuelle Integration erforderlich ist, fordern Sie einen Kostenvoranschlag sowohl für die Ersteinrichtung als auch für den laufenden Support an. Eine Online-Schule muss die Gesamtkosten (Total Cost of Ownership) kennen – nicht nur den reinen Abonnementpreis.

Abgleich der Daten für den Migrationsbericht

Der Abschlussbericht sollte mehr enthalten als nur die Anzahl der übertragenen Dateien. Vergleichen Sie die Anzahl der aktiven Nutzer mit der Anzahl der Nutzer, die tatsächlich den korrekten Zugriff erhalten haben; prüfen Sie, ob Kurse mit aktiven Teilnehmenden korrekt übernommen wurden; und stellen Sie sicher, dass alle zu erhaltenden Zertifikate und Ergebnisse tatsächlich verifiziert wurden.

Erfassen Sie Fehler, die nach dem Start auftreten, separat. Gruppieren Sie Support-Anfragen nach ihrer Ursache – etwa Anmeldeprobleme, Kursmaterialien, Zugriffsrechte, Zahlungen, Lernfortschritte oder Zertifikate. Ein plötzlicher Anstieg in einer bestimmten Kategorie deutet möglicherweise auf ein systemisches Problem hin und nicht nur auf ein hohes Arbeitsaufkommen beim Support-Team.

Überwachen Sie zudem geschäftsrelevante Kennzahlen: erfolgreiche Zahlungen, Konversionsraten auf Kursseiten sowie die Anzahl der Support-Anfragen pro 100 aktive Lernende. Vergleichen Sie diese Werte mit ähnlichen Zeiträumen und berücksichtigen Sie saisonale Schwankungen, damit Sie Veränderungen nicht fälschlicherweise allein der neuen Plattform zuschreiben.

Warum Zertifikate für Lernende eine eigene Strategie erfordern

Für manche Online-Schulen ist ein Zertifikat lediglich eine ansprechende Zusammenfassung der absolvierten Ausbildung. Für andere dient es als Nachweis über den Abschluss eines verbindlichen Programms, das von einem Arbeitgeber oder Partner gefordert wird. Im letzteren Fall bedeutet der Verlust der Dokumentenhistorie nicht nur einen erheblichen Mehraufwand, sondern birgt auch Risiken für den Ruf der Einrichtung sowie für die Einhaltung vertraglicher Verpflichtungen.

Erstellen Sie vorab ein Verzeichnis mit folgenden Angaben: Dokumentennummer, Programmname, Ausstellungsdatum, Empfänger, Abschlusskriterien und Authentifizierungsmethode. Falls Ihr bisheriges Lernmanagementsystem (LMS) Zertifikate mit automatischen Links generiert, prüfen Sie, ob diese Links nach der Migration weiterhin funktionieren. Gegebenenfalls müssen Sie ein separates Archiv oder eine Validierungsseite bereitstellen.

Es ist nicht notwendig, die gesamte Historie zu übertragen, nur damit das neue System eine bestimmte Anzahl an Abschlüssen anzeigt. Wichtiger ist es, sicherzustellen, dass der Anspruch eines Teilnehmers auf ein Dokument jederzeit korrekt verifiziert werden kann. Sollten bestimmte Daten nicht importiert werden können, legen Sie einen alternativen Verifizierungsweg fest und informieren Sie den Support.

Bei Programmen, für die formale Aufbewahrungsfristen für Dokumente gelten, müssen die entsprechenden Vorgaben gesondert geprüft werden. Die technische Lösung muss sich an diesen Vorgaben orientieren – nicht umgekehrt.

Warum das alte und das neue System eine Zeit lang parallel existieren sollten

Eine Migration ohne Übergangsphase erscheint zunächst kostengünstiger: Man schaltet das alte System ab und wechselt direkt zum neuen. Doch genau an diesem Tag können Fehler auftreten, die in der Testphase nicht aufgefallen sind. So könnte beispielsweise ein Teilnehmer mit einer speziellen Zugriffsart plötzlich keinen Zugriff mehr auf die Lerninhalte haben, oder ein Mentor stellt fest, dass bestimmte Kommentare aus dem alten System nicht korrekt übertragen wurden.

Eine Übergangsphase lässt sich so gestalten, dass das alte System weiterhin für administrative Prüfungen zur Verfügung steht, während neue Kursbuchungen und Schulungen bereits im neuen System abgewickelt werden. Es ist entscheidend, eine „einzige Quelle der Wahrheit“ (Single Source of Truth) zu definieren: Wo werden neue Ergebnisse erfasst? Wo werden Lernmaterialien bearbeitet? Welche Aktionen sind im alten System noch zulässig? Andernfalls führt die parallele Nutzung zwangsläufig zu Versionskonflikten.

Kurse, die Studierende während der Migration belegen, stellen eine besondere Herausforderung dar. Wenn jemand gestern eine Lektion im alten LMS abgeschlossen hat und heute im neuen System fortfährt, sollte der Lernfortschritt korrekt übertragen werden – oder es muss eine klare Möglichkeit geben, den Kurs nahtlos fortzusetzen. Bei umfangreichen Programmen kann es sinnvoll sein, einzelne Kohorten erst nach Abschluss eines Bewertungsmoduls zu migrieren.

Lassen Sie den Parallelbetrieb nicht unnötig in die Länge ziehen. Legen Sie ein Enddatum für die Übergangsphase fest sowie Kriterien, anhand derer die alte Plattform endgültig abgeschaltet werden kann.

Barrierefreiheit und mobile Nutzung nach der Migration

Ein Kurs kann technisch zwar funktionieren, aber dennoch schwieriger zu bedienen sein. Überprüfen Sie die Tastaturnavigation, die Zugänglichkeit für Screenreader, Untertitel, Kontraste, die Skalierbarkeit von Texten, die Darstellung von Tabellen sowie die Möglichkeit, Aufgaben auf einem kleinen Bildschirm zu bearbeiten.

Kursautoren testen oft nur auf ihren eigenen Laptops – mit schneller Internetverbindung und großem Bildschirm. Studierende hingegen nutzen möglicherweise Smartphones, sind unterwegs oder verfügen über eine instabile Internetverbindung. Das Testen solcher Szenarien hilft dabei, Probleme noch vor dem vollständigen Rollout aufzudecken.

Testen Sie eingebettete Inhalte separat. Videoplayer, externe Formulare, interaktive Elemente oder Dateiverknüpfungen könnten von der Domain des alten Systems abhängig sein. Wenn sich die Seite zwar öffnen lässt, aber beispielsweise der „Absenden“-Button nicht funktioniert, war der technische Test, der den Kurs als „verfügbar“ einstufte, irreführend.

Lassen Sie eine kleine Gruppe von Studierenden mit unterschiedlichen Endgeräten den gesamten Kursablauf durchlaufen und berichten, an welcher Stelle sie die Orientierung verloren haben. Dieser Test ist kostengünstiger, als am Tag der Einführung Hunderte von Beschwerden bearbeiten zu müssen.

Migrationsbudget: Was bei der Kalkulation oft übersehen wird

Die Kosten für das neue Abonnement machen nur einen Teil des Budgets aus. Berücksichtigen Sie auch den Zeitaufwand für Instructional Designer (Inhaltsprüfung), technisches Personal (Datenimport), Management (Anpassung von Zahlungsprozessen), Support-Mitarbeiter (Unterstützung der Studierenden) sowie das Marketing-Team (Überprüfung der SEO-Aspekte). Manche Integrationen erfordern zudem eine Neukonfiguration oder neue Verträge mit Anbietern.

Schätzen Sie die Kosten für optimistische, realistische und risikoreiche Szenarien. Das realistische Szenario sollte manuelle Inhaltskorrekturen berücksichtigen. Das risikoreiche Szenario sollte Verzögerungen beim Start, den vorübergehenden Betrieb zweier Plattformen und einen erhöhten Supportbedarf beinhalten.

Vergessen Sie nicht die Ausfallkosten. Wenn die Zahlungsseite während der Umstellung am Starttag einige Stunden lang nicht erreichbar ist, können die finanziellen Folgen die Kosten für den Import der Kurse selbst übersteigen. Daher sollte die Umstellung oft außerhalb der Spitzenzeiten und mit einem bewährten Wiederherstellungsplan erfolgen.

Das letzte Kriterium ist, ob das neue LMS die Probleme löst, für die die Umstellung initiiert wurde. Wenn eine Schule nach dem Start immer noch Zugänge manuell öffnen muss und die benötigten Berichte nicht sieht, bedeutet eine technisch erfolgreiche Migration nicht automatisch einen wirtschaftlichen Erfolg.

Generalprobe vor dem Start

Am Tag vor dem Start sollte ein kleines Team den gesamten Ablauf durchspielen: Ein neuer Teilnehmer sieht eine Kursseite, registriert sich, bezahlt den Zugang, öffnet eine Lektion, absolviert einen Test, erhält Nachrichten und kontaktiert den Support. Jeder Teilnehmer sollte seiner Rolle entsprechend handeln und nicht mit Administratorrechten, die uneingeschränkten Zugriff haben.

Anschließend sollte ein Fehlerszenario simuliert werden: Die Zahlung wurde erfolgreich durchgeführt, der Zugang jedoch nicht gewährt. Wer überprüft die Transaktion, wer kann den Zugang sicher gewähren, wo werden manuelle Eingriffe erfasst und wie lässt sich eine doppelte Bestellung vermeiden? Im zweiten Szenario sieht der Teilnehmer sein altes Zertifikat nicht. Auf welches Archiv greift der Support zu und welche Reaktionszeit wird zugesichert?

Eine solche Generalprobe ist selbst für kleine Schulen sinnvoll. Sie zeigt, ob die Rollen klar definiert sind und ob die Wiederherstellung nicht von einer einzelnen Person abhängt, die am Starttag möglicherweise nicht verfügbar ist. Ist für ein kritisches Szenario noch niemand verantwortlich, sollte die Umstellung verschoben werden, bis diese Zuständigkeit geklärt ist.

Dokumentieren Sie die Ergebnisse der Probe in einer kurzen Checkliste: geprüft, nicht geprüft, Risiko, Verantwortlicher und Korrekturfrist. Dies gibt dem Manager eine objektive Grundlage für die Entscheidung über den Start und verhindert, dass der Starttag zu einem improvisierten Test mit echten Studierenden wird.

Wie lässt sich der Erfolg der Migration nach einem Monat bewerten?

Der Umstellungstag ist nicht das Ende des Projekts. Nach vier Wochen empfiehlt es sich, die Teams aus Schulung, Support, Finanzen und Marketing zusammenzubringen und die Ergebnisse mit den ursprünglichen Zielen zu vergleichen. Hat sich die Zeit bis zur Freischaltung des Zugangs verkürzt? Sind weniger manuelle Eingriffe nötig? Sind kritische Daten erhalten geblieben? Ist der Anteil fehlgeschlagener Zahlungen gestiegen?

Sprechen Sie separat mit den Studierenden vor und nach der Umstellung. Möglicherweise bemerken sie kleinere Beeinträchtigungen: ein fehlendes Lesezeichen, eine umständlichere Navigation, eine schwierigere Lektionssuche oder eine veränderte Interaktion mit dem Mentor. Solche Details werden nicht immer im Verwaltungsbericht erfasst.

Die Zusammenfassung sollte nicht nur eine Liste der behobenen Fehler enthalten, sondern auch eine Entscheidung über die Weiterentwicklung. Wenn das neue LMS eine wesentliche Einschränkung beseitigt, aber einige kleinere Unannehmlichkeiten bestehen lässt, kann dies ein gutes Ergebnis sein. Bleibt das Hauptproblem jedoch bestehen, müssen Sie Ihre Erwartungen realistisch einschätzen und weitere Änderungen planen.

Fazit

Nach Ablauf des Monats sollte das Team prüfen, ob die alten Dienste abgeschaltet werden können, ohne wichtige Archivdaten zu verlieren. Kündigen Sie Verträge erst, wenn Sie die Datensicherung und den Zugriff auf die benötigten historischen Daten bestätigt haben. Dies ist der letzte praktische Schritt, der oft erst dann erfolgt, wenn kein Support mehr verfügbar ist.

Bei der Migration zwischen LMS geht es um die Übertragung eines laufenden Lernprozesses, nicht um das Kopieren einer Videobibliothek. Bevor Sie beginnen, müssen Sie verstehen, was mit Zugriff, Zahlungen, Ergebnissen, Integrationen und Suchseiten geschieht. Eine gute Bestandsaufnahme und Datenabgleichsübersicht sind wichtiger als die Geschwindigkeit des Importvorgangs.

Beginnen Sie mit einem Pilotprojekt mit einem komplexen Kurs, verfolgen Sie die Reise des Studenten von der Anmeldung bis zum Abschluss, behalten Sie eine Rollback-Option bei und investieren Sie in die Kommunikation. WeStudy oder jedes andere LMS sollte zeigen, dass es für Ihre tatsächlichen Arbeitsabläufe funktioniert, und nicht nur auf einer Demoseite.

Quellen

1. 1EdTech – Common Cartridge – standardisierte Verpackung und Weitergabe von Bildungsinhalten.

2. 1EdTech – Learning Tools Interoperability (LTI) – Integration externer Lerntools.

3. Google Search Central – Websiteumzüge mit URL-Änderungen.

4. Google Search Central – Weiterleitungen und Google-Suche.

5. ADL – SCORM.