LMS-Migration: So wechseln Sie ohne Datenverlust

Wenn Sie das hier lesen, sind Sie Ihr aktuelles LMS wahrscheinlich leid. Vielleicht dauert die Administration doppelt so lange, wie sie sollte. Vielleicht haben sich Ihre Teilnehmenden seit Monaten nicht mehr eingeloggt. Vielleicht verschwinden Support-Tickets in einer Warteschlange und kommen eine Woche später zurück, mit einem Link zu einem Hilfeartikel, den Sie längst gelesen hatten.

Sie sind nicht allein. 2020 stellte die Brandon Hall Group fest, dass 42 % der Unternehmen aktiv auf der Suche nach einem Ersatz für ihr LMS waren.

Die meisten Organisationen wachsen irgendwann aus ihrer Lernplattform heraus oder haben sie schlicht satt. Und trotzdem bleiben viele deutlich länger, als sie sollten, weil sich der LMS-Wechsel anfühlt wie eine Operation am offenen Herzen: Abschlussdaten aus vielen Jahren, Compliance-Zertifikate, Kursinhalte und Integrationen liegen in diesem System. Was, wenn auf dem Weg etwas verloren geht?

Diese Angst ist berechtigt. Aber sie ist auch beherrschbar. Eine gut gemachte LMS-Migration ist kein Sprung ins Ungewisse. Sie ist ein Projekt mit bekannten Risiken, bekannten Sicherheitsnetzen und einer klaren Reihenfolge. Dieser Leitfaden führt Sie durch alles: Woran Sie erkennen, dass es wirklich Zeit ist. Welche Daten Sie schützen müssen. Ob Sie beide Systeme parallel laufen lassen sollten. Was Ihr neuer Anbieter für Sie tun sollte. Und was Sie tun, wenn auf halbem Weg etwas schiefgeht.

Eines noch, bevor wir anfangen: Sie müssen sich nicht zwischen einem weiteren Jahr Leidensdruck mit dem alten System und einer sechsmonatigen Großbaustelle entscheiden. Das ist eine falsche Alternative, die meist von Anbietern kommt, deren Plattformen tatsächlich sechs Monate Einrichtung brauchen. Stecken Sie den Umfang ehrlich ab und holen Sie sich echte Hilfe vom neuen Anbieter, dann ist eine Migration in Wochen zu schaffen.

Woran erkennen Sie, dass es Zeit ist, das LMS zu wechseln?

Fünf Signale sollten Sie ernst nehmen, und keines davon handelt von einer schlechten Woche:

• Ihre Admins arbeiten am System vorbei statt damit. Wenn Ihr Team Daten in Tabellen exportiert, um einfache Fragen zu beantworten, oder eine parallele Ordnerstruktur pflegt, weil die Suche nach Inhalten im LMS aussichtslos ist, hat die Plattform bereits verloren.
• Teilnehmende meiden die Plattform. Niedrige Login-Raten, angefangene, aber nie abgeschlossene Kurse, Führungskräfte, die Abschlüssen per E-Mail hinterherlaufen. Bevor Sie der Plattform die Schuld geben, lohnt sich allerdings ein ehrlicher Blick darauf, ob das Problem das System ist oder die Art, wie es genutzt wird. Genau darüber haben wir hier geschrieben: warum Ihr LMS nicht genutzt wird. Wenn Sie Inhalte, Kommunikation und die Einbindung der Führungskräfte in Ordnung gebracht haben und die Menschen trotzdem an der Oberfläche abprallen, ist die Plattform das Problem.
• Der Support ist ein schwarzes Loch geworden. Sie reichen Tickets ein, warten, eskalieren, warten wieder. Wenn Sie bei etwas Geschäftskritischem keinen Menschen ans Telefon bekommen, tragen Sie ein Risiko, das so nie vereinbart war.
• Die Preise passen nicht mehr zu Ihrer Realität. Sie zahlen für Lizenzen, die niemand nutzt, oder stoßen auf Überraschungsgebühren für Funktionen, die Standard sein sollten.
• Die Roadmap ist verstummt. Keine nennenswerten Updates seit ein, zwei Jahren bedeutet meist: Die Aufmerksamkeit Ihres Anbieters liegt woanders.

Neu ist das alles übrigens nicht. Schon 2016 zeigte eine Umfrage der Brandon Hall Group, dass 44 % der Unternehmen mit Lerntechnologie ihre Lösung ersetzen wollten, und der häufigste Grund, genannt von 87 %, war der Bedarf an einer besseren User Experience.

Wenn Ihnen drei oder mehr dieser Punkte bekannt vorkommen, lautet die Frage nicht mehr „Sollen wir wechseln?“, sondern „Wie wechseln wir sicher?“. Und wenn Sie zur Auswahl kommen: Wählen Sie dieses Mal sorgfältiger. Ein strukturierter Anforderungsprozess, inklusive Exit-Klauseln, die Ihnen garantieren, dass Sie Ihre Daten wieder herausbekommen, bewahrt Sie davor, in drei Jahren wieder an genau diesem Punkt zu stehen. Wie Sie diesen Prozess aufsetzen, haben wir hier beschrieben: Leitfaden zu LMS-Anforderungen.

Ihre Checkliste für die LMS-Migration: Kennen Sie Ihre Risiken, bevor Sie wechseln

Bevor Sie sich auch nur eine Demo einer neuen Plattform ansehen, verschaffen Sie sich einen Überblick darüber, was Sie eigentlich mitnehmen. Die meisten Horrorgeschichten über Migrationen entstehen durch eine Abhängigkeit, die niemand vor dem Wechsel entdeckt hat. Arbeiten Sie zuerst diese Checkliste durch; alles Weitere in diesem Artikel baut darauf auf.

Die Kernfragen, die die Checkliste abdeckt:

• Daten: Was muss mitziehen, was kann archiviert werden, was kann zurückbleiben? Nutzerkonten, Anmeldehistorie, Abschlussdaten, Zertifikate, Testergebnisse.
• Inhalte: Welche Kurse werden aktiv genutzt? In welchen Formaten liegen sie vor, und können Sie sie in einem Standardformat wie SCORM, xAPI oder cmi5 exportieren?
• Integrationen: Welche Systeme sind heute an Ihr LMS angebunden? HR-Systeme, Single Sign-on, Kalender-Tools, Reporting-Pipelines. Jede Verbindung ist eine eigene Migrationsaufgabe.
• Compliance: Welche Nachweise müssen Sie gesetzlich aufbewahren, und wie lange? Hier werden Zertifikate und Abschlusshistorie zu Hochrisikodaten (mehr dazu weiter unten).
• Menschen: Wer muss informiert, geschult und überzeugt werden? Admins, Führungskräfte, Teilnehmende, IT.
• Timing: Gibt es Schulungsfristen, Audits oder Onboarding-Wellen, die Sie auf keinen Fall stören dürfen?

Beantworten Sie diese Fragen ehrlich, und Sie haben bereits mehr Vorbereitung geleistet als die meisten Organisationen, die hinterher wütende Beiträge über ihre Migration schreiben.

Parallelbetrieb oder Big Bang: Welcher Weg für den Wechsel passt zu Ihnen?

Sie haben zwei grundlegende Strategien, und die Wahl zwischen ihnen prägt Ihr gesamtes Risikoprofil: das alte und das neue System für eine Übergangszeit nebeneinander laufen lassen, oder ein Datum festlegen und alles auf einmal umstellen.

Keine der beiden ist pauschal richtig.

Parallelbetrieb bedeutet: Teilnehmende schließen laufende Kurse im alten System ab, während neue Aktivitäten im neuen System starten. Ihr Sicherheitsnetz ist eingebaut: Wenn etwas kaputtgeht, ist das alte System noch live. Die Kosten sind allerdings real. Sie zahlen doppelte Lizenzen für die Überlappungszeit, Ihre Admins pflegen zwei Systeme, und Teilnehmende können verwirrt sein, wohin sie eigentlich sollen. Parallelbetrieb passt zu Ihnen, wenn Sie langlaufende Kurse haben, die nicht unterbrochen werden dürfen, strenge Compliance-Fristen einhalten müssen oder so viele Teilnehmende haben, dass ein einziger misslungener Starttag teuer würde.

Big Bang bedeutet: Sie migrieren, validieren und stellen zu einem festen Datum um. Das ist sauberer, günstiger und erzwingt Entscheidungen, statt sie schleifen zu lassen. Das Risiko ist konzentriert: Wenn etwas nicht stimmt, spüren es alle gleichzeitig. Big Bang passt zu Ihnen, wenn Ihr Kurskatalog kompakt ist, wenig laufende Aktivität besteht (Sommer und Jahresende sind nicht ohne Grund beliebt) und Sie Ihre Datenmigration vor der Umstellung gründlich validiert haben.

Ein praktischer Mittelweg, bei dem viele Organisationen landen: Big Bang für die Plattform, paralleler Zugriff auf das alte System im Nur-Lese-Modus für ein paar Wochen. Sie bekommen einen klaren Stichtag, aber die historischen Daten bleiben erreichbar, während Sie prüfen, ob alles korrekt angekommen ist. Fragen Sie Ihren bisherigen Anbieter, was eine Nur-Lese-Auslaufphase kostet, bevor Sie annehmen, dass sie möglich ist; das ist ein Verhandlungspunkt, und ein Grund mehr, warum Exit-Bedingungen vom ersten Tag an in Ihren Vertrag gehören.

Was zieht wirklich mit um: Daten, Zertifikate, Inhalte, Integrationen

Teilen Sie Ihr Inventar in vier Kategorien, denn jede zieht anders um. „Wir migrieren einfach alles“ ist der Grund, warum Projekte über jede Schätzung hinauswachsen.

Nutzerdaten und Historie. Konten, Rollen, Gruppenstrukturen, Anmeldungen, Abschlussdaten. Die Struktur lässt sich selten eins zu eins zwischen Plattformen abbilden, rechnen Sie also mit Mapping-Arbeit: Was Ihr altes System „Lernpfad“ nennt, heißt im neuen vielleicht „Kursprogramm“. In diesem Mapping verstecken sich die Fehler, und es ist Arbeit, die Ihr neuer Anbieter gemeinsam mit Ihnen erledigen und nicht per Vorlage an Sie abgeben sollte.

Zertifikate und Abschlusshistorie: Ihre Hochrisikodaten. Wenn Ihre Schulungen compliance-relevant sind (Sicherheitszertifizierungen, regulatorische Schulungen, Betriebserlaubnisse), sind die Abschlussnachweise das Wertvollste in Ihrem alten LMS. Sie zu verlieren kann bedeuten, dass Mitarbeitende Pflichtschulungen wiederholen müssen oder Ihre Organisation ein Audit nicht besteht, das sie sonst bestanden hätte. Behandeln Sie diese Daten als eigenes Teilprojekt: Exportieren Sie sie früh, in einem Format, das ein Auditor akzeptieren würde (inklusive Daten, Versionen und wer was abgeschlossen hat), und prüfen Sie sie unabhängig von der Hauptmigration. Selbst wenn die neue Plattform nicht jedes historische Zertifikat nativ importieren kann, schützt Sie ein vollständiges, gut organisiertes Archiv.

Kursinhalte. Inhalte in Standardformaten lassen sich problemlos übertragen; fragen Sie beide Anbieter ausdrücklich nach SCORM-, xAPI- und cmi5-Unterstützung für Export und Import, und testen Sie mit einem echten Kurs, bevor Sie sich festlegen. Inhalte, die im proprietären Autorentool Ihres alten Anbieters gebaut wurden, lassen sich oft gar nicht übertragen, und genau hier wachsen Migrationen über ihre Schätzung hinaus. Eine Migration ist außerdem eine seltene Gelegenheit, tote Inhalte zurückzulassen, also nutzen Sie sie. Wenn ein Kurs seit zwei Jahren nicht angefasst wurde, fragen Sie sich, ob er ein zweites Leben verdient oder ein würdevolles Archiv.

Integrationen. Jedes System, das mit Ihrem LMS verbunden ist, muss neu verbunden, neu konfiguriert oder abgeschaltet werden. Listen Sie sie auf, weisen Sie jeder Verbindung eine verantwortliche Person zu und testen Sie sie in der neuen Umgebung vor dem Launch.

Stellen Sie bei der Bestandsaufnahme auch die Speicherfrage: Wo werden Ihre Daten nach dem Umzug physisch liegen? Für europäische Organisationen ist Datenresidenz zunehmend eine zwingende Anforderung. Auch deshalb hosten wir bei Learnifier die Daten unserer Kunden auf EU-Servern, mit schwedischem Hosting als Option, wenn die Daten Schweden nicht verlassen sollen. Für welchen Anbieter Sie sich auch entscheiden, lassen Sie sich die Antwort schriftlich geben.

Wie vermeiden Sie Datenverlust und Ausfallzeiten bei der LMS-Migration?

Fünf Grundregeln, alle rund um Kopien und Verifizierung, decken den Großteil des Datenverlust-Risikos ab:

1. Ziehen Sie zuerst einen vollständigen Export. Bevor irgendeine Migrationsarbeit beginnt, exportieren Sie Nutzer, Abschlüsse, Zertifikate und Inhalte komplett aus dem alten System und speichern Sie alles an einem Ort, den Sie selbst kontrollieren. Dieser Snapshot ist Ihre Versicherungspolice und das Fundament jedes Rollbacks (dazu später mehr). Tun Sie es, solange Ihr alter Vertrag Ihnen den Zugriff noch garantiert.
2. Migrieren Sie in Etappen, verifizieren Sie jede Etappe. Erst Nutzer, dann Historie, dann Inhalte, dann Integrationen. Prüfen Sie nach jeder Etappe die Zahlen und machen Sie Stichproben: Stimmt die Zahl der Abschlüsse im neuen System mit dem Export überein? Haben zehn zufällig ausgewählte Teilnehmende die richtige Historie? Kleine Verifizierungsschleifen fangen Fehler ab, solange sie noch billig zu beheben sind.
3. Frieren Sie Änderungen im finalen Migrationsfenster ein. Wählen Sie ein kurzes Fenster, kommunizieren Sie es klar und pausieren Sie Admin-Änderungen im alten System, damit sich die Daten während der Migration nicht mehr ändern. Das muss übrigens keine Ausfallzeit für Teilnehmende bedeuten; mit einem etappenweisen Vorgehen lässt sich die tatsächliche Ausfallzeit oft auf wenige Stunden begrenzen.
4. Schützen Sie laufende Kurse. Niemand sollte wegen Ihres Zeitplans mitten in einer Zertifizierung den Fortschritt verlieren. Lassen Sie laufende Kohorten entweder im alten System abschließen (das Argument für den Parallelbetrieb) oder legen Sie die Umstellung auf einen natürlichen Tiefpunkt der Aktivität.
5. Halten Sie das alte System so lange im Nur-Lese-Modus, wie Ihr Budget es erlaubt. Es ist das günstigste Verifizierungswerkzeug, das Sie je haben werden: Jede Unstimmigkeit darüber, ob ein Datensatz korrekt migriert wurde, klärt ein Blick in die Quelle.

Nichts davon ist technisch schwierig. Was es braucht, ist die richtige Reihenfolge und ein neuer Anbieter, der das schon einmal gemacht hat. Der schwierigere Teil sind die Menschen.

Change Management: Wie nehmen Sie Ihre Mitarbeitenden beim Wechsel mit?

Eine technisch makellose Migration kann am Starttag trotzdem scheitern, wenn sich niemand einloggen will. Das System hat gewechselt; die Menschen nicht.

Der LMS-Wechsel lässt sich leichter vermitteln als die meisten IT-Projekte, weil Sie in der Regel etwas ersetzen, das die Menschen ohnehin nicht mögen. Nutzen Sie das. Verkaufen Sie die Migration nicht als „Wir wechseln das System“ (das interessiert niemanden). Sagen Sie den Menschen, was jetzt aufhört zu nerven: weniger Klicks bis zum eigenen Kurs, Zertifikate, die sich tatsächlich herunterladen lassen, eine Plattform, die auf dem Handy funktioniert.

Ein paar Dinge, die den Unterschied verlässlich ausmachen:

• Informieren Sie die Admins zuerst und binden Sie sie früh ein. Sie wissen, wo im alten System die Leichen im Keller liegen, und sie werden die Fragen aller anderen beantworten. Eine Migration, die ohne Ihre Power-User geplant wird, übersieht Dinge, die nur sie kennen.
• Kommunizieren Sie Termine, mit denen die Menschen planen können. „Laufende Kurse bis zum 15. abschließen. Neue Plattform öffnet am 20. Altes System bis Monatsende lesbar.“ Drei Zeilen reichen.
• Geben Sie Führungskräften etwas an die Hand. Teilnehmende hören auf ihre eigene Führungskraft mehr als auf ein Projektpostfach. Eine kurze Nachricht zum Weiterleiten plus ein Gesprächspunkt fürs Teammeeting tragen weiter als jede Launch-Kampagne.
• Machen Sie den ersten Login lohnend. Das Erste, was die Menschen in der neuen Plattform sehen, sollte für sie relevant sein: ihr Kurs, ihre Historie, ihr nächster Schritt. Ein leeres Dashboard am ersten Tag gibt jedem Skeptiker recht.

Und wecken Sie keine falschen Erwartungen. Manches wird in Woche eins anders sein, ohne besser zu sein. Sagen Sie das vorab. Es kostet nichts, und die Menschen sind geduldiger mit dem, wovor man sie gewarnt hat.

Welche Unterstützung sollten Sie von Ihrem neuen Anbieter verlangen?

Zu wenige Käufer stellen dem Anbieter die direkte Frage: Was genau werden Sie während der Migration für uns tun, und was kostet das?

Die Antworten fallen im Markt extrem unterschiedlich aus, und sie verraten viel darüber, mit wem Sie sich da gerade einlassen. Migrationsunterstützung gibt es in drei Stufen.

• Was kostenlos sein sollte: eine namentlich benannte Kontaktperson, die Ihr Onboarding verantwortet (keine Ticket-Warteschlange), Hilfe beim Mapping Ihrer Datenstruktur auf die neue Plattform, Beratung zu Exportformaten aus Ihrem alten System, Admin-Schulungen und ehrliche Antworten darauf, was nicht sauber übertragen wird. Wenn ein Anbieter für grundlegende Onboarding-Hilfe extra kassiert, ist das ein Vorgeschmack auf die Zusammenarbeit.
• Was fairerweise bezahlt wird: die Massenmigration großer Content-Bibliotheken, individuelle Integrationsentwicklung, der Neuaufbau von Kursen, die in einem proprietären Format feststecken, historische Datentransformation jenseits von Standardimporten. Das ist echte Projektarbeit; dafür zu zahlen ist fair, aber Umfang und Preis gehören in den Vertrag, bevor Sie unterschreiben, nicht als Überraschung in Monat zwei.
• Was ein Warnsignal ist: „unsere Dokumentation deckt das alles ab“, keine benannte Person, Migrationsleistungen nur über einen Drittpartner, den Sie nie getroffen haben, oder ein Onboarding-Prozess, der voraussetzt, dass Sie eine Projektleitung übrig haben.

Das Verhalten des Anbieters während Ihrer Migration ist der ehrlichste Vorgeschmack auf seinen späteren Support. Ein Anbieter, der reaktionsschnell, menschlich und großzügig ist, während er Sie gewinnen will, bleibt es meist auch; einer, der schon vor Ihrer Unterschrift langsam ist, wird später nicht schneller. Deshalb stellen wir bei Learnifier Menschen mit Namen und Telefonnummer ins Zentrum des Onboardings: Die Wochen, in denen Sie Ihre Daten umziehen und Ihr Setup neu aufbauen, sind genau die Zeit, in der Sie jemanden brauchen, der ans Telefon geht.

Stellen Sie also die unbequemen Fragen im Verkaufsprozess. Wer genau hilft uns (mit Namen) bei der Migration? Wie viele Wochen hat Ihre letzte Migration bei einem Kunden unserer Größe tatsächlich gedauert? Was ist inklusive, was wird berechnet? Schreiben Sie die Antworten in den Vertrag.

Was sind die häufigsten Fehler bei der LMS-Migration?

Migrationen scheitern fast immer an denselben Punkten. In grober Reihenfolge der Häufigkeit:

1. Alles migrieren. Veraltete Kurse aus zehn Jahren und inaktive Konten mitzunehmen vervielfacht die Arbeit und importiert genau das Chaos, das das alte System unerträglich gemacht hat. Migrieren Sie, was lebt; archivieren Sie den Rest.
2. Die Testmigration überspringen. Wenn die echte Migration die erste Migration ist, entdecken Sie Mapping-Fehler erst im Produktivbetrieb. Machen Sie immer einen Probelauf mit einer Teilmenge echter Daten und verifizieren Sie ihn vor dem vollständigen Umzug.
3. Zertifikate als Nebensache behandeln. Die Compliance-Historie wird unter „Daten“ einsortiert, und niemand prüft sie, bis ein Audit es tut. Geben Sie ihr einen eigenen Arbeitsstrang, eine eigene Verifizierung, ein eigenes Archiv.
4. Integrationen unterschätzen. Das LMS migriert problemlos; das SSO nicht, und am ersten Tag kann sich niemand einloggen. Testen Sie jede Verbindung in der neuen Umgebung vor der Umstellung.
5. Verkünden vor dem Validieren. Der ganzen Organisation „Wir sind live!“ zu melden und dann kaputte Daten zu finden: So verbrennen Sie Vertrauen, das Sie noch monatelang brauchen werden.
6. Keinen Rollback-Plan haben. Das ist der Fehler, über den fast kein Migrationsleitfaden spricht, also ändern wir das jetzt.

Ihr Rollback-Plan: Was, wenn es auf halbem Weg schiefgeht?

Erst ein Rollback-Plan gibt Ihnen die Sicherheit, entschlossen weiterzumachen. Er hat vier Teile:

• Ein Wiederherstellungspunkt. Der vollständige Export, den Sie vor dem Start gezogen haben (siehe oben), plus das alte System, das während der Übergangszeit live oder im Nur-Lese-Modus bleibt. Solange beides existiert, ist kein Fehler fatal.
• Definierte Auslöser. Entscheiden Sie im Voraus, was Sie pausieren oder zurückrollen lässt: Abschlussdaten, die sich nicht abgleichen lassen, Login-Fehler über einem Schwellenwert, ein Compliance-Nachweis, den Sie nicht verifizieren können. Diese Entscheidung trifft man besser in Ruhe als mitten in der Krise.
• Eine entscheidungsbefugte Person. Eine namentlich benannte Person mit der Befugnis zu sagen: „Wir stoppen, wir beheben, wir versuchen es nächste Woche erneut.“ Rollbacks scheitern, wenn diese Entscheidung durch ein Gremium muss.
• Eine Kommunikationsvorlage. Zwei vorformulierte Nachrichten: „Wir verschieben die Umstellung, mit Begründung und neuem Termin“ und „Wir sind vorübergehend zurück im alten System.“ Sind die beiden geschrieben, ist eine Verzögerung nur noch eine E-Mail.

In der Praxis bedeutet ein Rollback selten, die Migration aufzugeben. Meist bedeutet er, für ein paar Tage zum alten System zurückzukehren, während Sie einen Mapping-Fehler beheben, und dann erneut umzustellen. Organisationen mit Rollback-Plan behandeln das als kleine Verzögerung. Organisationen ohne behandeln es als Katastrophe, weil sie bis dahin oft ihren alten Vertrag haben auslaufen lassen. Terminieren Sie die Kündigung Ihres alten Systems auf die Zeit nach der erfolgreichen Validierung.

Nach dem Wechsel: Validierung und die ersten Wochen

Zwei Dinge schließen die Migration ab: Die Zahlen stimmen überein, und die Menschen arbeiten tatsächlich in der neuen Plattform.

Validieren Sie, bevor Sie feiern. Gleichen Sie die Zahlen ab: Nutzerzahlen, Abschlusssummen, Zertifikatszahlen mit Ihrem Export von vor der Migration. Machen Sie Stichproben bei echten Datensätzen, und lassen Sie eine Handvoll Admins und Führungskräfte die Daten ihrer eigenen Teams prüfen; sie entdecken Dinge, die kein Skript findet. Testen Sie die kritischen Wege von Anfang bis Ende: per SSO einloggen, anmelden, einen Kurs abschließen, ein Zertifikat herunterladen, den Bericht ziehen, den Ihre Geschäftsleitung jedes Quartal verlangt.

Beobachten Sie dann die menschlichen Signale. Login-Raten in Woche eins und Woche drei. Wo sich Supportfragen häufen (sie zeigen Ihnen exakt, was eine bessere Anleitung oder einen fünfminütigen Rundgang braucht). Ob Führungskräfte den Fortschritt ihrer Teams finden, ohne nachzufragen. Beheben Sie die kleinen Reibungspunkte schnell; frühe Ärgernisse verhärten sich schneller zu „das neue System ist auch schlecht“, als Sie denken.

Und behalten Sie eines im Blick: Die Migration hat Ihre Daten sicher in ein neues Zuhause gebracht, aber sie hat noch keine neuen Gewohnheiten aufgebaut, keine neuen Programme gestartet und noch nicht die Ergebnisse geliefert, für die Sie gewechselt haben. Nach der Migration beginnt eine neue Implementierung, und das ist ein Projekt mit eigenem Vorgehen: Checkliste für die LMS-Implementierung.

Die Angst, die Organisationen an ein LMS fesselt, aus dem sie herausgewachsen sind, ist fast immer größer als das tatsächliche Risiko, sobald das Risiko benannt, aufgelistet und eingeplant ist. Eine gute Migration ist eine Liste bekannter Risiken, in der richtigen Reihenfolge abgearbeitet, mit echter Hilfe vom Anbieter, zu dem Sie wechseln. Wenn Sie vorher einen Schritt zurücktreten und sich noch einmal ansehen möchten, was eine Lernplattform überhaupt für Sie leisten sollte, tun Sie das, bevor Sie loslegen. Und dann nehmen Sie die Checkliste oben, gehen Sie sie mit Ihrem Team durch und finden Sie heraus, wie viel kleiner dieses Projekt ist, als es von außen aussieht.