Was kostet ein LMS wirklich? Warum der Lizenzpreis nicht reicht

Zwei LMS-Angebote liegen auf dem Tisch. Das eine kostet pro Nutzer deutlich weniger als das andere. Die Rechnung scheint einfach: Nutzerzahl mal Monatspreis, günstigeren Anbieter wählen, fertig.

Nur ist das selten die Rechnung, die ein Unternehmen später tatsächlich bezahlt.

Schon aktuelle LMS-Ausschreibungen behandeln Konfiguration, Datenmigration, Integrationen, Training und laufenden Support als eigene Leistungsblöcke. Allgemeine Beschaffungsmodelle gehen noch einen Schritt weiter: Sie betrachten Kosten über den gesamten Lebenszyklus – von Einführung und Betrieb bis zum Ende der Nutzung.

Für einen belastbaren LMS-Vergleich heißt das: Der Lizenzpreis ist eine Kostenposition. Die eigentliche Entscheidung braucht ein gemeinsames Kostenmodell.

Ein günstiger Tarif ist noch kein günstiges LMS

Der einfachste Preisvergleich funktioniert nur, wenn die Angebote auch außerhalb der Lizenz praktisch identisch sind. Genau das ist bei Unternehmenssoftware selten der Fall.

Ein Anbieter rechnet SSO und HR-Integration als Projektleistung ab. Beim nächsten gehören Standardschnittstellen zum Paket, dafür kostet historische Datenmigration extra. Ein dritter bietet günstige Lizenzen, erwartet aber mehr Eigenleistung bei Konfiguration, Testing und Support. Dazu kommen interne Aufwände, die in keinem Angebot stehen.

Das Grundprinzip ist gut dokumentiert. Die Europäische Kommission beschreibt Life-Cycle Costing als Betrachtung von Anschaffung, Betrieb und End-of-Life-Kosten. Das britische Sourcing Playbook nutzt Should Cost Models, um Whole-Life-Kosten unterschiedlicher Delivery-Modelle vergleichbar zu machen. Dabei werden auch interne Ressourcen und Fähigkeiten sichtbar, wenn Leistungen im eigenen Haus erbracht werden.

Bei einem LMS lassen sich diese Kosten nicht sinnvoll vergleichen, wenn jede Position mit einem anderen Leistungsumfang kalkuliert wurde.

Was in aktuellen LMS-Beschaffungen tatsächlich eingekauft wird

Ein Blick in reale Ausschreibungen macht das Problem konkreter.

Union County in North Carolina suchte 2026 ein cloudbasiertes Enterprise-LMS. Der veröffentlichte Scope nennt nicht nur die Plattform selbst, sondern ausdrücklich Systemkonfiguration, Datenmigration, Integrationsleistungen, Training und laufenden Support.

Ein aktuelles britisches Vergabeverfahren von Fairhive Homes beschreibt den Bedarf ähnlich breit: gehostetes LMS, Konfiguration von Workflows und Rollen, Implementierungsunterstützung, Datenmigration, SSO und Provisionierung, Training sowie laufende Wartung und Support.

Solche Verfahren sind kein Marktpreisindex. Aus ihrem Budget lässt sich nicht ableiten, was „ein LMS“ normalerweise kostet. Dafür unterscheiden sich Nutzerzahl, Funktionsumfang, Integrationen, Migrationsbestand, Servicelevel und Vertragsmodell zu stark.

Sie zeigen aber etwas anderes sehr deutlich: Organisationen kaufen im Ernstfall nicht bloß Zugang zu Software. Sie kaufen eine betriebsfähige Lösung plus den Weg dorthin.

Die Kosten entstehen in verschiedenen Phasen

Die vier Phasen sind kein neuer Standard. Sie sind eine praktische Struktur, um typische Lebenszykluskosten eines LMS nicht in einer einzigen Lizenzzeile verschwinden zu lassen.

Einführungskosten sind mehr als die Rechnung des Anbieters

Bei der Einführung gibt es zwei Kostenarten, die oft vermischt werden.

Die erste ist sichtbar: externe Projektleistung. Dazu können Workshops, Konfiguration, Datenmigration, Schnittstellen, Tests, Schulungen oder individuelle Anpassungen gehören.

Die zweite steht häufig in keinem Angebot: eigene Arbeitszeit.

HR oder L&D bereinigt Stammdaten, entscheidet über Rollen, Gruppen und Schulungslogik, prüft migrierte Lernhistorien, testet Prozesse und koordiniert Fachbereiche. IT kümmert sich um SSO, Provisionierung, Security und Schnittstellen. Datenschutz, Einkauf oder Betriebsrat können ebenfalls beteiligt sein. Führungskräfte und Key User brauchen Zeit für Tests und Freigaben.

Diese Stunden sind keine Lizenzkosten. Für die Entscheidung sind sie trotzdem real.

Deshalb sollte eine TCO-Rechnung externe Zahlungen und interne Aufwände getrennt ausweisen. Nicht, um jede interne Viertelstunde mit Scheingenauigkeit zu bepreisen. Sondern damit ein Angebot mit viel Eigenleistung nicht künstlich billig aussieht.

Im Betrieb entscheidet die Architektur über wiederkehrende Arbeit

Nach dem Go-live wird der Lizenzpreis planbarer. Der restliche Aufwand nicht unbedingt.

Ein LMS mit sauberer HR-Anbindung kann Benutzer, Organisationseinheiten und Statusänderungen weitgehend automatisiert übernehmen. Ohne passende Integration entstehen manuelle Importe, Fehlerkorrekturen und Abstimmung. Ein flexibles Rollenmodell kann Administration reduzieren; eine unpassende Struktur erzeugt Sonderprozesse. Reporting kann Self-Service sein oder regelmäßig Unterstützung erfordern.

Dasselbe gilt für Support und Änderungen. Entscheidend ist nicht nur, ob ein Anbieter Support „inklusive“ nennt, sondern was enthalten ist: Reaktionszeiten, Ansprechpartner, technische Analyse, Konfigurationshilfe oder Projektarbeit. Auch Updates können unterschiedlich viel interne Prüfung auslösen, wenn Prozesse, Schnittstellen oder Inhalte betroffen sind.

Genau hier kippt ein reiner Preis-pro-Nutzer-Vergleich. Zwei Systeme können denselben fachlichen Zweck erfüllen und trotzdem sehr unterschiedliche Betriebsarbeit erzeugen.

Migration gehört in die Kaufentscheidung – auch wenn sie erst später weh tut

Wer ein bestehendes LMS ersetzt, kalkuliert Migration meist für den Start. Der gleiche Gedanke gehört aber auch ans Ende des neuen Vertrags.

Welche Benutzer-, Abschluss-, Zertifikats-, Kurs- und Zuordnungsdaten lassen sich exportieren? Was geschieht mit historischen Nachweisen? Welche Konfigurationen müssen im Zielsystem neu aufgebaut werden? Wie lange müssen zwei Systeme parallel laufen? Wer prüft, ob die Daten nach dem Wechsel noch fachlich dasselbe bedeuten?

Die Kosten dafür entstehen vielleicht erst in drei oder fünf Jahren. Ignorieren sollte man sie deshalb nicht.

Ein Exit-Budget muss auch nicht behaupten, den exakten Wechselpreis im Jahr 2031 zu kennen. Es reicht zunächst, die Kostenmechanismen sichtbar zu machen und mit Szenarien zu arbeiten. Ein System, dessen Daten und Integrationen gut dokumentiert und portabel sind, hat ein anderes Kostenrisiko als eine Architektur, deren Ablösung erst beim Kündigen verstanden wird.

Wer tiefer in die technische Seite einsteigen will, findet die separate Frage in unserem Beitrag zur LMS-Migration und Lernhistorie. Die allgemeinen Wechselhürden von SaaS behandelt außerdem der Beitrag zum Data Act und SaaS-Exit.

Eine TCO-Rechnung braucht dieselben Annahmen für alle Anbieter

Die Rechnung wird erst vergleichbar, wenn alle Angebote auf denselben Fall normalisiert werden.

Dazu gehören vor allem der gleiche Betrachtungszeitraum, dieselbe Nutzerentwicklung und derselbe fachliche Scope. Wenn Anbieter A mit 1.000 aktiven Nutzern kalkuliert, Anbieter B mit 1.500 registrierten Accounts und Anbieter C eine Flatrate nennt, sind die Summen noch nicht vergleichbar. Dasselbe gilt, wenn bei einem Angebot Migration, Support oder SSO enthalten sind und beim anderen nicht.

Praktisch braucht jede Position deshalb mindestens vier Angaben: Was wird benötigt? Ist es im Angebot enthalten? Welche externe Zahlung entsteht? Welcher interne Aufwand bleibt?

Für unsichere Größen sind Bandbreiten ehrlicher als eine einzelne Zahl. Eine einfache Basis-, Hoch- und Niedrig-Schätzung für Migration, Integrationsänderungen oder internen Betrieb zeigt oft mehr als ein scheinbar exakter Fünfjahreswert auf den Euro.

Die Gegenposition: TCO kann selbst zur Scheingenauigkeit werden

Das Gegenargument ist berechtigt. Je mehr Kostenarten eine TCO-Tabelle enthält, desto professioneller sieht sie aus. Das macht ihre Annahmen nicht automatisch besser.

Gerade spätere Änderungen sind schwer vorherzusagen. Das gilt für neue Integrationen, geänderte Organisationsstrukturen, zusätzliche Mandanten oder einen späteren Systemwechsel. Eine TCO-Rechnung sollte solche Größen deshalb nicht als sichere Zukunftskosten behandeln, wenn sie heute nur als Szenario abschätzbar sind.

Außerdem beantwortet TCO nur die Kostenseite. Ein billigeres System ist nicht automatisch die bessere Lösung, wenn es den fachlichen Bedarf schlechter erfüllt.

Eine TCO-Rechnung sollte deshalb keine Einkaufsentscheidung simulieren, die längst mathematisch entschieden ist. Sie beantwortet eine engere Frage: Welche Kostenrisiken kaufen wir mit dieser Lösung über den Lebenszyklus mit?

Erst danach kommt die Nutzenfrage: Welches System erfüllt die Anforderungen besser, reduziert Risiken, spart reale Arbeit oder ermöglicht Prozesse, die heute nicht funktionieren?

So wird aus drei Preisblättern eine belastbare Entscheidung

Ein brauchbarer Vergleich beginnt nicht mit dem Addieren aller denkbaren Positionen. Zuerst wird ein gemeinsames Einsatzszenario festgelegt.

Dann werden die Kosten entlang von Einführung, Betrieb, Veränderung und Exit erfasst. Externe Zahlungen bleiben von internen Aufwänden getrennt. Einmalige, wiederkehrende und optionale Kosten werden nicht zusammengeschoben. Unsichere Positionen bekommen Bandbreiten oder Szenarien.

Erst auf dieser Basis lohnt sich der Vergleich der Gesamtkosten.

Das Ergebnis kann durchaus sein, dass der Anbieter mit der niedrigsten Lizenz auch insgesamt am günstigsten ist. Es kann aber ebenso passieren, dass eine teurere Subscription durch weniger Projektaufwand, bessere Integrationen oder geringere Betriebsarbeit wirtschaftlich sinnvoller wird.

Die entscheidende Zahl ist deshalb nicht „Preis pro Nutzer“. Sie lautet auch nicht automatisch „TCO in Euro“.

Die bessere Entscheidungsfrage ist: Welche Lösung erfüllt unseren Bedarf – und welche vollständige Kostenlogik hängt an ihr, wenn wir sie tatsächlich einführen, betreiben, verändern und irgendwann wieder verlassen?