Wie Floating Licenses die Jira-DC-Rechnung einer 15.000-User-Instanz um bis zu 60 % gesenkt haben

1. Jira Data Center Preise: wo wir stehen

1.1 Fünf Jahre Preiserhöhungen

Wer in den letzten Jahren Jira Data Center Lizenzen verlängert hat, kennt den Trend. Für den 15.000-User-Tier sehen die Zahlen so aus:

• 2019: USD 290.400 (~19,36 $ pro Nutzer)
• 2021: USD 525.000 (~35 $ pro Nutzer)
• 2024: USD 604.000 (~40,27 $ pro Nutzer)

Mehr als verdoppelt in fünf Jahren. Atlassian hat kräftig in die Plattform investiert, aber die Rechnung muss irgendwo landen — und sie landet bei eurer Verlängerung. (Listenpreise ändern sich regelmäßig; den aktuellen Stand findet ihr in Atlassians Data Center Pricing.)

1.2 Warum das härter trifft als es aussieht

Der Listenpreis ist nur ein Teil der Geschichte. Die meisten Jira-DC-Kosten liegen im OPEX, können also nicht aktiviert werden — sie treffen die Gewinn- und Verlustrechnung (GuV) direkt, jedes Jahr. Und es ist nicht nur die Jira-Lizenz selbst. Drittanbieter-Apps rechnen meistens ebenfalls nach Nutzerzahl ab. Wenn Atlassian den Tier-Preis anhebt, steigt die Tempo-Rechnung mit, die ScriptRunner-Rechnung steigt mit, und plötzlich liegen die Gesamtkosten 30–40 % über der reinen Lizenz.

Wir haben mehr als einmal gesehen, wie das Finance-Teams kalt erwischt hat. Die Jira-Verlängerung kommt rein, wird durchgewunken weil „ist ja das Gleiche wie letztes Jahr plus Inflation“ — und drei Monate später fällt auf, dass die Marketplace-Rechnungen auch hochgegangen sind.

1.3 Was man dagegen tun kann

Die eine Lösung gibt es nicht, aber ein paar Dinge machen erfahrungsgemäß den größten Unterschied:

Räumt eure Nutzerbasis regelmäßig auf. In den meisten Jira-Instanzen gibt es Hunderte Accounts, die sich seit Monaten nicht eingeloggt haben — manchmal seit Jahren. Die zählen trotzdem zum Lizenz-Tier. Ein vierteljährlicher Cleanup klingt unsexy, kann aber dafür sorgen, dass ihr einen ganzen Pricing-Tier runterrutscht.

Findet heraus, wer wirklich eine Volllizenz braucht. Nicht jeder Nutzer in eurem Verzeichnis arbeitet täglich mit Jira. Manche loggen sich einmal im Quartal ein für ein Statusupdate. Andere haben das Unternehmen verlassen, aber der Account ist noch aktiv. Heavy User von Gelegenheitsnutzern zu trennen ist die Grundlage für alles Weitere.

Verrechnet die Kosten an die Teams, die sie verursachen. Sobald Abteilungen sehen, was ihr Anteil an der Jira-Rechnung tatsächlich ist, ändert sich das Verhalten. Wir haben erlebt, dass Teams freiwillig ihre eigenen inaktiven Accounts aufgeräumt haben, nachdem die Kostenstellen-Zuordnung das sichtbar gemacht hat.

Und dann gibt es den großen Hebel: Floating Licenses. Statt für jeden Nutzer im Verzeichnis zu zahlen, optimiert ihr, wie viele lizenzierte Nutzer ihr tatsächlich braucht — indem Lizenzen dynamisch auf Basis der Aktivität zugewiesen und freigegeben werden. Darum geht es im Rest dieses Artikels.

1.4 Jira-Nutzer ist nicht gleich Jira-Nutzer

Bevor wir in Floating Licenses einsteigen, lohnt sich ein Blick darauf, wer eigentlich in eurer Jira-Instanz sitzt. Bei einem typischen Setup mit 15.000 Nutzern sehen wir grob fünf Gruppen:

Admins verwalten die Instanz — die brauchen permanente Lizenzen, keine Frage. Aber das sind meistens weniger als 50 Leute.

Heavy User leben den ganzen Tag in Jira. Entwickler, Projektmanager, Scrum Master. Die erstellen Issues, pflegen Boards, lassen Queries laufen. Permanente Lizenzen machen hier ebenfalls Sinn.

Management / VIP-Nutzer schauen auf Dashboards, prüfen Reports, geben Freigaben. Die loggen sich ein paar Mal pro Woche ein, manchmal seltener. Volllizenzen für diese Gruppe sind teuer gemessen an der tatsächlichen Nutzung.

Standard-Nutzer arbeiten regelmäßig mit Jira, hängen aber nicht minütlich drin. Sie aktualisieren ihre Tickets, schauen aufs Sprint Board, buchen vielleicht Zeiten.

Gelegenheitsnutzer und inaktive Accounts — die stille Mehrheit in vielen Instanzen. Leute, die sich einmal im Monat einloggen, oder Accounts, die seit zwei Jahren nicht angefasst wurden, weil jemand die Abteilung gewechselt hat — und niemand den Account angefasst hat. Diese Accounts kosten genauso viel wie der aktivste Entwickler im Team.

Gruppen drei bis fünf sind der Punkt, an dem das Geld liegt. Sie machen den Großteil der Nutzerzahl aus, aber nur einen Bruchteil der tatsächlichen gleichzeitigen Nutzung. Genau diese Lücke schließen Floating Licenses.

2. Umstieg auf Floating Licenses — ein Fallbeispiel mit 15.000 Nutzern

2.1 Was ihr braucht

Ihr braucht die VIP.LEAN Floating Licenses App, installiert auf eurer Jira Data Center Instanz.

Wir bieten eine kostenlose 3-Monats-Testlizenz an, damit ihr euer optimales Setup finden könnt, bevor ihr euch festlegt. Diese Testphase ist wichtig — wer das überstürzt, landet entweder bei zu vielen Lizenzen (Geld verschwendet) oder zu wenigen (Nutzer ausgesperrt).

2.2 Initiales Setup

Zuerst identifiziert ihr, welche Nutzer über Floating Licenses verwaltet werden sollen. Bei einer 15.000-User-Instanz nehmt ihr typischerweise Admins, technische/API-User und eure aktivsten Heavy User aus dem Floating-Pool heraus. In unserem Beispiel bleiben rund 14.500 Nutzer übrig, die dynamisch verwaltet werden.

Erstellt zwei Jira-Gruppen:

• jira-software-users: Nutzer mit aktiver Jira Software Lizenz
• jira-virtual-users: Nutzer im Floating-Pool, ohne permanente Lizenz

Installiert die Testlizenz für 15.000 Floating Licenses. Verschiebt die 14.500 Nutzer in „jira-virtual-users.“ Ab jetzt passiert Folgendes: Wenn sich einer dieser Nutzer einloggt, weist die App automatisch eine Lizenz zu und fügt ihn zu „jira-software-users“ hinzu. Wenn er für eine bestimmte Zeit inaktiv war — wir starten meistens mit 60 Minuten — wird die Lizenz wieder freigegeben und steht dem nächsten Nutzer zur Verfügung.

In den ersten Tagen ändert sich sichtbar nichts. Alle können sich wie gewohnt einloggen. Die App trackt im Hintergrund nur die Nutzungsmuster.

2.3 Die richtige Anzahl finden

Jetzt wird es spannend. Fangt an, die verfügbaren Floating Licenses von 14.500 schrittweise zu reduzieren — wir senken normalerweise um 200–500 pro Woche, je nach Nutzungsmuster. Beobachtet, ob jemand beim Login abgewiesen wird oder sich beschwert.

Nach unserer Erfahrung landen viele Unternehmen bei rund 3.500 gleichzeitigen Lizenzen, um 14.500 Floating-Nutzer komfortabel zu bedienen. Das entspricht ungefähr einem Verhältnis von 4:1 — ein Wert, den wir in vielen Enterprise-Setups sehen.

Falls Nutzer beim Login abgewiesen werden:

• Versucht zuerst, den Inaktivitäts-Timeout zu senken (z. B. von 60 auf 45 Minuten). Das gibt Lizenzen schneller frei.
• Wenn das nicht reicht, erhöht die Lizenzanzahl um 500 und stabilisiert dort.

Das Ziel ist nicht, jede letzte Lizenz rauszuquetschen — sondern den Punkt zu finden, an dem niemand merkt, dass das System überhaupt im Einsatz ist.

2.4 Das finale Setup

Sagen wir, ihr landet bei 4.000 gleichzeitigen Lizenzen für eure 15.000 Nutzer. Ihr kauft die VIP.LEAN Floating Licenses App für 15.000 Floating-Nutzer und behaltet ein 3-Monats-Beobachtungsfenster bei, um die Zahlen zu bestätigen.

Danach reduziert ihr euer Jira Data Center Abonnement von 15.000 auf den Lizenz-Tier, der euren tatsächlichen Bedarf abdeckt. Die Rechnung:

USD 604.000 (15.000 Nutzer) → USD 231.000 (reduzierter Tier) = USD 373.000 Ersparnis pro Jahr

Das ist keine theoretische Zahl. Das passiert, wenn man aufhört, für 11.000 Nutzer zu zahlen, die nicht eingeloggt sind.

3. Ist das für jedes Unternehmen das Richtige?

Floating Licenses funktionieren am besten, wenn eine große Lücke zwischen Gesamtnutzerzahl und gleichzeitiger Spitzenauslastung besteht — und das ist bei den meisten Enterprise-Jira-Instanzen der Fall. Wenn eure 15.000 Nutzer alle Entwickler sind, die acht Stunden am Tag in Jira arbeiten, wird das Verhältnis nicht 4:1 sein. Aber das ist selten die Realität.

Die 3-Monats-Testphase gibt es genau aus diesem Grund: erst messen, dann entscheiden. Die Daten zeigen euch, ob die Einsparung da ist.