Wenn Sie 2026 Jira Server betreiben, betreiben Sie nicht unterstützte Software. Atlassian hat den Support am 15. Februar 2024 eingestellt. Keine Sicherheitspatches. Keine Fehlerbehebungen. Kein Herstellersupport.
Am 30. März 2026 hat Atlassian keine neuen Data-Center-Abonnements von Neukunden mehr angenommen. Bestandskunden können bestimmte Käufe bis zum 30. März 2028 und Verlängerungen bis zum 28. März 2029 fortsetzen, wenn betroffene Produkte schreibgeschützt werden gemäß dem von Atlassian veröffentlichten End-of-Life-Zeitplan für Data Center.
Also, was jetzt?
2026 gibt es drei ernstzunehmende selbst gehostete Optionen, die einen Vergleich verdienen: OpenProject, Plane und Redmine. Dieser Beitrag vergleicht sie nach Anwendungsarchetyp statt nach Funktionsliste, betrachtet den offiziellen OpenProject Jira Migrator, der jetzt für unterstützte Jira-Server- und Data-Center-Versionen in der Beta ist, und endet mit dem ehrlichen Gegenargument: wann Jira Cloud weiterhin die richtige Antwort ist.
Wenn Sie hier sind, weil „wir müssen bis 2029 migrieren und ich muss meine echten Optionen kennen", lesen Sie weiter. Wenn Sie hier sind, weil „ich will eine Bewertungstabelle mit 47 Spalten", dafür gibt es andere Artikel. Dies ist keiner davon.
Die Kurzfassung
- Jira Server wird bereits nicht mehr unterstützt, und Jira Software Data Center wird schrittweise eingestellt. Der Neuverkauf von Data Center an Neukunden endete 2026; betroffene bestehende Abonnements erreichen 2029 ihr Lebensende.
- Drei echte selbst gehostete Wege im Jahr 2026. OpenProject für Teams, die einen Jira-förmigen Ersatz mit Migrationswerkzeug wollen, Plane für engineering-getriebene Teams, die die UX von Linear ohne SaaS-Rechnung wollen, Redmine für Teams, die einen ressourcenschonenden Issue-Tracker wollen, der seit zwei Jahrzehnten funktioniert.
- OpenProject hat einen integrierten Jira Migrator in der Beta für Jira Server und Data Center 10.x und 11.x, nicht für Jira Cloud. Die offiziellen Quellen sind derzeit nicht deckungsgleich: Der technische Leitfaden vom Mai listet einen engeren Kerndatensatz, während neuere Juli-Seiten sagen, der Migrator importiere auch Vorgangshistorie, Kommentare sowie beteiligte Benutzer und Gruppen. Behandeln Sie diese neueren Angaben als versionsabhängig und bestätigen Sie sie in einem Pilotlauf auf genau der OpenProject-Version, die Sie ausrollen werden. Plane wirbt separat mit einem kontrollierten Jira-Import und persönlicher Migrationsbegleitung für Teams ab 100 Lizenzen. Redmine hat keinen vergleichbaren eigenen Weg.
- Die VPS-Dimensionierung ist bescheiden. Die offiziellen Vorgaben starten OpenProject und Plane bei 4 GB RAM; für die Produktion empfiehlt Plane 8 GB. Das Redmine-Image von Cloudzy nennt 2 GB RAM als Minimum.
- Jira Cloud ist für manche Teams weiterhin richtig, besonders für solche ohne Betriebskapazität. Die Preise von Atlassian variieren je nach Lizenzanzahl und Abrechnungszyklus, nutzen Sie daher die aktuelle Jira-Preisseite statt sich auf einen alten, fest eingetragenen Tarif zu verlassen.
Die Abschaltuhr von Atlassian: Was wirklich passiert
Drei Daten, die den Countdown für Jira setzen:
- 15. Februar 2024: Atlassian hat den Support für Jira Server beendet. Für Server-Produkte oder -Apps werden weder technischer Support noch Sicherheitsupdates oder Fehlerbehebungen bereitgestellt.
- 30. März 2026: Atlassian hat den Verkauf neuer Data-Center-Abonnements und Marketplace-Data-Center-Apps an Neukunden eingestellt. Bestandskunden können weiterhin verlängern.
- 28. März 2029: Betroffene Data-Center-Abonnements und -Apps laufen aus und werden schreibgeschützt. Atlassian gibt an, dass für bestimmte Kunden ausnahmsweise eine verlängerte Wartung verfügbar sein kann.
Teams reagieren grob auf drei Arten. Manche migrieren zu Jira Cloud, zahlen die Rechnung pro Lizenz und nehmen die betriebliche Vereinfachung mit. Manche warten auf Data-Center-Verlängerungen bis 2029 und behandeln die Frist als Problem ihres künftigen Ichs. Manche prüfen jetzt selbst gehostete Alternativen, um sowohl den Preis als auch die Frist zu vermeiden.
Wenn Sie zur zweiten Gruppe gehören („das klären wir später"), lautet die ehrliche Einschätzung: „später" ist nur dann ein 2029-Problem, wenn bis dahin sonst nichts auf Ihrer Roadmap steht. Die meisten Teams, die ich das habe tun sehen, migrieren am Ende in Panik, weil der Kalender schneller läuft, als irgendjemand erwartet.
Profi-Tipp: Wenn Ihr Team auf Server läuft, rechtfertigt allein das Sicherheitsrisiko, dies als 2026-Problem zu behandeln, nicht als 2029-Problem. Nicht unterstützte Issue-Tracker bleiben Angriffsfläche, und sie landen bei Sicherheitsprüfungen oft ganz unten, gerade weil sie „einfach laufen".
Fazit des Abschnitts: Der Countdown ist datiert, öffentlich und offiziell. Planen Sie für 2026-2027, nicht für 2029.
Die drei realistischen selbst gehosteten Wege im Jahr 2026
Im Open-Source-Ökosystem gibt es Dutzende Issue-Tracker. Für einen fokussierten Vergleich behandelt dieser Artikel drei unterschiedliche Wege: OpenProject für formales Projektmanagement und das direkteste Migrationswerkzeug; Plane für einen modernen Engineering-Workflow; und Redmine für einen ausgereiften, erweiterbaren Tracker. Taiga, Tuleap, Kanboard und andere Projekte können für engere Anforderungen weiterhin besser passen.
Hier ist, was jedes davon tatsächlich ist.
OpenProject
OpenProject ist eine Ruby-on-Rails-Anwendung mit PostgreSQL im Hintergrund. Die Community Edition steht unter GPLv3 und ist kostenlos selbst zu hosten; kostenpflichtige Enterprise-on-Premises-Pläne ergänzen Support und Enterprise-Funktionen.
Die UX-Ausrichtung ist zweckmäßig und funktionsdicht. Es sieht aus wie Unternehmens-Projektmanagementsoftware, weil es genau das ist. Starke Unterstützung für Gantt-Diagramme, formales Projektportfolio-Reporting, BCF-basierte Zusammenarbeit für Bau und Ingenieurwesen sowie Verantwortlichkeitsflüsse für Stakeholder. Wenn Ihr Team je nach „echtem Gantt" oder „Abhängigkeiten zwischen Epics über Projekte hinweg" gefragt hat, ist das Ihr Werkzeug.
Am besten passt OpenProject zu einem Team, das klassisches Wasserfall und Agile in derselben Instanz koexistieren lassen muss, formales Reporting nach oben braucht und einen offiziellen Migrationspfad von unterstützten Jira-Server- oder Data-Center-Versionen. Auf den Migrator und seine aktuellen Grenzen kommen wir weiter unten zurück.
Die Schwäche ist die Lernkurve. Teammitglieder, die von Jira Cloud oder Linear kommen, werden Ihnen sagen, dass sich OpenProject schwerfällig anfühlt. Sie haben nicht unrecht. Viele Kernkonzepte von Jira haben Entsprechungen in OpenProject, aber Sie müssen unter Umständen die Dokumentation lesen, um sie zu finden.
OpenProject ist im dem Cloudzy-Marketplace als Ein-Klick-Deployment, wenn Sie sich den Compose-Tanz sparen wollen.
Plane
Plane ist ein jüngeres Projekt, gegründet 2022. Die aktuelle selbst gehostete Distribution ist ein gebündeltes Docker- oder Kubernetes-Deployment mit mehreren Anwendungsdiensten plus PostgreSQL, Redis und Objektspeicher, statt eines einfachen Stapels aus fünf Containern.
- Web- und API-Dienste
- Hintergrund-Worker
- PostgreSQL
- Redis
- Objektspeicher
Die Community Edition steht unter der AGPLv3-Lizenz.
Die UX-Ausrichtung ist offen von Linear inspiriert. Zyklen, Module, Projekte, Ansichten. Modern, schnell, meinungsstark. Wenn Sie je die Standard-Tastenkürzel von Linear oder dessen Issue-Modell mochten, wird Ihnen Plane innerhalb einer Stunde vertraut vorkommen.
Am besten passt ein engineering-getriebenes Team: Start-ups, unabhängige Produktteams, kleine Dev-Shops, in denen Ingenieure die Hauptnutzer sind und das Projektmanagement-Tool im Wesentlichen ein Issue-Tracker plus Sprint-Board ist. Hier glänzt Plane.
Es gibt echte Schwächen, die man anerkennen sollte. Das Projekt ist jünger als die anderen, was ein kleineres Integrations-Ökosystem und eine sich schneller ändernde Deployment-Oberfläche bedeutet. Auch die AGPLv3-Lizenz verdient eine Prüfung, bevor Sie die Software für einen kommerziellen Netzwerkdienst anpassen.
Plane ist Stand Juli 2026 nicht im Cloudzy-Marketplace, dieser Weg erfordert also Planes eigenes Docker- oder Kubernetes-Deployment auf dem VPS Ihrer Wahl. Für ein Team, das mit Containern vertraut ist, ist das machbar, bedeutet aber mehr Einrichtung und Wartung als ein Ein-Klick-Image.
Redmine
Redmine ist der Veteran. Erste Veröffentlichung 2006. Ruby on Rails, Backend mit MySQL oder PostgreSQL. GPLv2. Nach heutigen Maßstäben leichtgewichtig, teils weil der Kern wirklich klein ist, teils weil das meiste, was Leute von Redmine wollen, über Plugins kommt.
Die UX ist älter. Es hat keinen Sinn, so zu tun, als wäre es anders. Redmine 7.0 wurde im Juni 2026 zum neuesten stabilen Zweig, aber seine Standardoberfläche wirkt weiterhin traditionell. Das Bleuclair-Theme modernisiert Redmine 6.1; prüfen Sie die Kompatibilität von Theme und Plugins, bevor Sie auf Redmine 7 wechseln. Wenn moderne UX zwingend ist, sehen Sie sich Plane an.
Am besten passt ein Team, das Redmine bereits einsetzt, oder eines, das einen stabilen, ressourcenschonenden Issue-Tracker ohne stark vorgegebenen Workflow will. Das Plugin-Ökosystem ist riesig:
- Agile Boards
- Gantt
- Zeiterfassung
- SCM-Integrationen
- Benutzerdefinierte Workflows
Wenn ein Team einen bestimmten Workflow-Bedarf hat, gibt es dafür wahrscheinlich ein Redmine-Plugin.
Die Schwäche ist zweifach. Die UX, wie beschrieben. Und das Plugin-Ökosystem selbst, das zweischneidig ist: Plugins lösen Probleme, verursachen aber beim Upgrade Kopfschmerzen mit der Versionskompatibilität. Eine Redmine-Instanz mit acht Plugins ist eine Instanz, bei der jedes Minor-Upgrade Tests erfordert.
Ein Hinweis für Teams, die bereits auf Redmine sind: Wenn die einzige Kritik die UX betrifft und Sie Redmine 6.1 einsetzen, ist das Bleuclair-Theme ein günstiges Experiment, das eine Plattformmigration überflüssig machen kann. Testen Sie es zuerst und prüfen Sie die Kompatibilität vor jedem Upgrade auf Redmine 7.
Fazit des Abschnitts: Wählen Sie nach Archetyp. OpenProject für einen Jira-förmigen Ersatz. Plane für Linear-UX ohne SaaS-Rechnung. Redmine für stabiles Issue-Tracking mit einem Plugin für alles.
Vergleich nebeneinander
Nachdem jedes Werkzeug im Detail behandelt wurde, bringen wir sie in ein übersichtlich vergleichbares Format.
| Dimension | OpenProject (Community) | Plane (Community) | Redmine |
|---|---|---|---|
| Erstveröffentlichung | 2012 | 2022 | 2006 |
| Stapel | Ruby on Rails plus PostgreSQL | Gebündelte App plus PostgreSQL, Redis und Objektspeicher | Ruby on Rails plus MySQL oder PostgreSQL |
| Lizenz | GPLv3 | AGPLv3 | GPLv2 |
| Mindestdimensionierung (kleines Team) | 4 Kerne, 4 GB RAM | Ab 4 GB RAM, 8 GB für die Produktion empfohlen | Ab 2 GB RAM |
| dem Cloudzy-Marketplace | Ja (Ein Klick) | Nein (selbstverwaltetes Deployment) | Ja (Ein Klick) |
| Eigener Jira-Migrationspfad | Integrierte Beta: Server/Data Center 10.x bis 11.x | Geführter Import; persönliche Betreuung ab 100 Lizenzen | Nichts |
| Am stärksten bei | Formales Projektmanagement, Gantt, Portfolio-Reporting | Moderne UX, Engineering-Teams | Leichtgewichtiges Issue-Tracking, Plugins |
| Am schwächsten bei | Schwerfälligere UX; Migrator noch in der Beta | Jüngeres Ökosystem; höhere RAM-Untergrenze | Alternde Standard-UX; Plugin-Kompatibilität |
Der Jira Migrator von OpenProject: Was er tatsächlich leistet
Das ist das Detail, das die meisten Vergleiche von 2026 überspringen oder in eine Fußnote verbannen. Es ist zugleich der tragende Grund, warum OpenProject für Teams, die heute auf Jira sind, die naheliegendste Wahl ist.
OpenProject hat seinen Jira Migrator in der Beta im Jahr 2026 als Teil der Community Edition verfügbar gemacht. Er verbindet sich per API und mit einem Admin-Personal-Access-Token zu Jira Server oder Data Center 10.x und 11.x. Jira Cloud wird derzeit nicht unterstützt.
Was die aktuellen offiziellen OpenProject-Seiten in der Summe als importierbar nennen:
- Projekte und Projektkennungen
- Vorgänge: Zusammenfassung oder Titel, Beschreibung, Anhänge, Historie, Kommentare, Fälligkeitsdatum, geschätzte Stunden und verbleibende Stunden; Vorgangskennungen werden ebenfalls in der Beta unterstützt
- Benutzer und beteiligte Gruppen, einschließlich Namen, E-Mail-Adressen, Projektmitgliedschaft und Gruppenmitgliedschaft
- Unterstützte benutzerdefinierte Felder, die eine Entsprechung in OpenProject haben
- Status und Vorgangstypen
Was Sie weiterhin als nicht unterstützt behandeln sollten:
- Beziehungen zwischen Vorgängen und Sprint-Zuordnungen
- Workflows, Berechtigungen und Schemata auf Projektebene
- Labels, Versionen, Komponenten und andere nicht als abgedeckt gelistete Felder sollten als nicht unterstützt gelten, bis ein Pilotlauf das Gegenteil zeigt
- Jira Cloud, Daten von Marketplace-Apps, Automatisierungsregeln und externe Integrationen
Zwei betriebliche Details sind ebenso wichtig wie die Feldliste. Importläufe landen zunächst in einem Review-Modus, und ein Import lässt sich rückgängig machen, solange er noch in der Prüfung ist. Sobald Sie den Import freigeben, ist ein Rückgängigmachen nicht mehr möglich. Und weil sich der Umfang noch von Release zu Release ändert, prüfen Sie vor jeder Migration die aktuelle Dokumentation.
Ein sinnvolles mentales Modell: Der Beta-Migrator bewältigt einen wachsenden Satz zentraler Projektdaten, nicht eine komplette Jira-Umgebung. Planen Sie einen kontrollierten Pilotlauf und Zeit ein, um nicht unterstützte Workflow-Logik, Berechtigungen, Apps und Integrationen neu aufzubauen.
Hinweis: Der technische Leitfaden von OpenProject vom 6. Mai listet einen engeren Datensatz als die neueren Juli-Seiten, die Historie, Kommentare sowie beteiligte Benutzer und Gruppen ergänzen. Da der Migrator weiterhin in der Beta ist, prüfen Sie den Umfang in genau der Version, die Sie ausrollen, und testen Sie ihn vor der Umstellung an einem repräsentativen Jira-Projekt.
Ein sichererer Migrationspfad auf hoher Ebene sieht so aus:
- Richten Sie eine Nicht-Produktionsinstanz von OpenProject auf einem VPS ein (das Ein-Klick-Image von Cloudzy funktioniert, oder nutzen Sie die unterstützten Deployment-Methoden von OpenProject).
- Bestätigen Sie, dass die Quelle Jira Server oder Data Center 10.x oder 11.x ist, und erstellen Sie dann ein Admin-Personal-Access-Token.
- Sichern Sie die OpenProject-Testinstanz und konfigurieren Sie dann den Migrator mit der Jira-URL und dem Token.
- Führen Sie einen Pilotlauf mit einem repräsentativen Projekt durch und prüfen Sie Projektkennungen, Benutzer, Gruppenmitgliedschaften, Status, Vorgangstypen, unterstützte benutzerdefinierte Felder, Anhänge, Historie, Kommentare, Fälligkeitsdaten, Schätzungen und verbleibende Stunden.
- Prüfen Sie den Pilotlauf sorgfältig. Solange der Import in der Prüfung ist, machen Sie ihn rückgängig, falls die Zuordnungen falsch sind; nach der Freigabe lässt sich dieser Import nicht mehr zurücknehmen.
- Planen Sie die Produktionsmigration erst, wenn der Pilotlauf bestanden ist. Nutzen Sie ein Wartungsfenster, frieren Sie Schreibzugriffe auf Jira ein, bewahren Sie Backups auf und bauen Sie nicht unterstützte Workflows und Integrationen separat neu auf.
Plane wirbt inzwischen mit einem kontrollierten, eigenen Jira-Import , der Projekte, Vorgänge, Sprints, Vorgangstypen, Status, benutzerdefinierte Felder, Kommentare und Anhänge abbildet; Teams ab 100 Lizenzen können persönliche Migrationsbegleitung anfragen. Der Weg von Redmine bleibt weniger direkt und stützt sich auf Community-Plugins oder CSV-Abläufe, die gegen exakte Versionen und Konfigurationen getestet werden müssen.
Fazit des Abschnitts: Der Beta-Migrator von OpenProject unterstützt Jira Server/Data Center 10.x und 11.x, doch die offiziellen Quellen widersprechen sich beim aktuellen Umfang. Validieren Sie Ihre exakte Version. Plane bietet einen geführten Import; Redmine hat keinen vergleichbaren eigenen Weg. Testen Sie OpenProject und Plane vor der Produktion im Pilotbetrieb.
VPS-Dimensionierung: Was jedes Werkzeug wirklich braucht
Die Infrastrukturkosten für das Selbsthosten dieser Werkzeuge sind überschaubar. Zuverlässigkeit, Backups, Restore-Tests und Monitoring wiegen schwerer, als den Stack in den kleinsten Tarif zu quetschen. Cloudzy veröffentlicht derzeit ein 99,95 % Uptime-SLA, und seine VPS-Tarife lassen sich mit wachsender Nutzung anpassen.
| Planungspunkt | OpenProject | Plane | Redmine |
|---|---|---|---|
| Startempfehlung | 4 Kerne, 4 GB RAM | 2 Kerne, 4 GB RAM | Ab 2 GB RAM (Cloudzy-Image) |
| Hinweis für die Produktion | Minimum für Einzelserver; bis zu 200 Benutzer insgesamt | Empfiehlt 8 GB RAM | Plugins und Parallelität bestimmen die Last |
| Skalieren, wenn | Warteschlangen, DB-Latenz oder RAM steigen | Dienste konkurrieren um RAM und CPU | DB-Latenz oder Plugin-Last steigen |
Ein paar Hinweise, die im Betrieb zählen:
- Das offizielle Minimum von OpenProject für eine Einzelserverinstallation ist eine Quad-Core-CPU, 4 GB RAM und 20 GB freier Festplattenspeicher. Das Beispiel für eine kleine Instanz nennt separat 2 CPU-Kerne und 4 GB RAM für die Anwendung plus 2 CPU-Kerne und 4 GB RAM für PostgreSQL.
- Die offiziellen Self-Hosting-Anforderungen von Plane geben mindestens 2 CPU-Kerne und 4 GB RAM an, für die Produktion werden 8 GB empfohlen.
- Das Redmine-Image von Cloudzy nennt 2 GB RAM als Minimum. Übersetzen Sie das nicht in eine garantierte Nutzerzahl: Plugins, Anhangsvolumen, gleichzeitige Anfragen und das Datenbankverhalten bestimmen die reale Kapazität.
Zum Vergleich: der Standardtarif mit 4 GB von Cloudzy bietet 2 vCPU, 120 GB NVMe-Speicher und 5 TB Transfer. Er erfüllt die RAM-Untergrenze von OpenProject, nicht aber das offizielle Vier-Kern-Minimum, nutzen Sie für OpenProject also einen Tarif oder eine individuelle Konfiguration mit mindestens 4 vCPU. Beobachten Sie vor dem Skalieren Datenbanklatenz, Worker-Queues und Speicherdruck; versprechen Sie keinen festen Leistungsfaktor allein aufgrund des Speichertyps.
Entwickeln Sie auf einem Linux-VPS mit Root-Zugriff, NVMe und AMD-EPYC-Power.
Linux-Pläne ansehenFazit des Abschnitts: Redmine kann bei rund 15 $ pro Monat starten und Plane bei rund 29 $ pro Monat, zu den aktuellen Standard-Listenpreisen von Cloudzy und vor Aktionen. OpenProject verlangt laut offiziellem Minimum mindestens vier CPU-Kerne, kalkulieren Sie es also mit einer passenden Konfiguration statt mit dem 2-vCPU-/4-GB-Tarif.
Wann Jira Cloud weiterhin die richtige Antwort ist
Selbsthosten tauscht Geld gegen Zeit. Es gibt eine Teamkonstellation, in der das Geld mehr wert ist als die eingesparte Zeit, und dieses Team sollte Atlassian bezahlen.
Jira-Cloud-Listenpreise mit Stand Juli 2026, entnommen der öffentlichen Preisseite von Atlassian (die Sätze legt Atlassian fest, sie variieren nach Abrechnungszyklus und Lizenzanzahl und ändern sich ohne Ankündigung, behandeln Sie also jede Zahl unten als Momentaufnahme von 2026 und prüfen Sie sie auf der aktuelle Jira-Preisseite bevor Sie budgetieren):
- Kostenlos: bis zu 10 Benutzer.
- Standard: around $8 per user per month as of mid-2026.
- Premium: around $14 per user per month as of mid-2026.
- Enterprise: Jahresverträge, individuelle Preise.
At that rate, 25 seats total roughly $2,400 per year. A Cloudzy 4 GB VPS is $28.95 per month at standard list price, or about $347 per year before promotions. Jira Cloud's subscription is therefore roughly seven times the VPS infrastructure cost on those 2026 figures, but that comparison excludes operator time, backups, monitoring, paid support, and any Enterprise features.
Stellen Sie jetzt die ehrliche Frage: Wer übernimmt Backups, Restore-Tests, Upgrades, Postgres-Wartung, Monitoring, SSL-Zertifikate, Benutzerverwaltung und Incident Response? Vergleichen Sie das Jira-Cloud-Abo mit den vollen Betriebskosten des selbst gehosteten Stacks, nicht nur mit der VM-Rechnung. Wenn niemand diese Arbeit übernimmt, kann die scheinbare Ersparnis schnell verschwinden.
Der Wert von Jira Cloud ist überwiegend betrieblich. Atlassian betreibt die Plattform, Upgrades, Patches und Backups auf Service-Ebene; Ihr Team verantwortet weiterhin Zugriffsrichtlinien, Identitätsintegration, App-Governance und Entscheidungen zur Datenaufbewahrung. Für ein Team, in dem niemand einen Projektmanagement-Stack betreiben kann, ist diese Managed-Schicht echten Wert wert.
Ehrlich formuliert: Selbsthosten passt zu Teams, die ohnehin einen VPS betreiben, einen Ingenieur haben, der sich mit Docker wohlfühlt, und die Kapazität für die Betriebsarbeit mitbringen. Jira Cloud passt zu Teams, in denen niemand derjenige sein will, den man weckt, weil Postgres der Speicherplatz ausgegangen ist.
Wenn Sie unsicher sind, welches Team Sie sind, fahren Sie einen zweiwöchigen OpenProject-Pilot auf einem VPS. Ist Ihre Quelle eine unterstützte Jira-Server- oder Data-Center-Version, importieren Sie ein repräsentatives Projekt mit dem Beta-Migrator; Jira Cloud wird noch nicht unterstützt. Entweder das Team nimmt es an und Sie lernen den Betriebsaufwand kennen, oder die Rechnung für den Managed Service von Jira Cloud wirkt plötzlich vernünftiger.
Schnelles Fazit
- Sie migrieren von einer unterstützten Jira-Server- oder Data-Center-Version und wollen eine integrierte Self-Service-Beta: OpenProject. Prüfen Sie die versionsspezifische Feldabdeckung vor der Produktion.
- Engineering-getriebenes Team, das moderne UX und einen geführten Jira-Import will: Plane. Es benötigt 4 GB RAM, empfiehlt 8 GB für die Produktion und bietet persönliche Migrationsbegleitung für Teams ab 100 Lizenzen.
- Sie nutzen bereits Redmine und wollen einen stabilen Issue-Tracker auf einem ressourcenschonenden VPS: bleiben Sie bei Redmine. Probieren Sie das Bleuclair-Theme aus, bevor Sie über eine Migration nachdenken.
Häufig gestellte Fragen
Wird Jira Server 2026 noch unterstützt?
Nein. Atlassian hat den Support für Jira Server am 15. Februar 2024 beendet. Wer es 2026 betreibt, nutzt nicht unterstützte Software ohne Sicherheitspatches. Neukunden können Jira Data Center nicht mehr kaufen, die realistischen unterstützten Wege sind also Jira Cloud oder eine gepflegte Alternative; bestehende Data-Center-Kunden können gemäß dem von Atlassian veröffentlichten Ausstiegsplan weitermachen.
Kann ich Jira Data Center noch kaufen?
Nein, nicht als Neukunde. Atlassian hat den Data-Center-Neuverkauf an Neukunden am 30. März 2026 eingestellt. Bestandskunden können bis zum 30. März 2028 neue Abonnements, Apps und Erweiterungen kaufen und bestehende Abonnements bis zum 28. März 2029 verlängern. Danach werden betroffene Produkte schreibgeschützt, sofern Atlassian keine Ausnahmeverlängerung gewährt.
Wie migriere ich von Jira zu OpenProject?
Der Jira Migrator von OpenProject ist derzeit in der Beta. Er verbindet sich per API mit Jira Server oder Data Center 10.x und 11.x über ein Admin-Personal-Access-Token; Jira Cloud wird nicht unterstützt. Neuere offizielle Seiten vom Juli 2026 nennen als importierbar: Projekte und Kennungen; Vorgänge mit Beschreibungen, Anhängen, Historie und Kommentaren; beteiligte Benutzer und Gruppen; Status und Typen; sowie unterstützte benutzerdefinierte Felder. Der technische Leitfaden vom Mai listet weiterhin einen engeren Satz, prüfen Sie also den genauen Umfang in der Version, die Sie ausrollen. Workflows, Berechtigungen, Schemata, Vorgangsbeziehungen und Sprint-Zuordnungen bleiben nicht unterstützt oder stehen auf der Roadmap.
Was ist die günstigste selbst gehostete Jira-Alternative?
Nach den derzeit dokumentierten Einstiegswerten ist Redmine auf dem 2-GB-Image von Cloudzy die günstigste Option. Das Einzelserver-Minimum von OpenProject liegt bei vier CPU-Kernen und 4 GB RAM. Plane verlangt 2 Kerne und 4 GB RAM, für die Produktion werden 8 GB empfohlen. Community-Editionen verursachen keine Softwarelizenzkosten, aber kostenpflichtiger Support, Backups, Monitoring und Betreuungszeit zählen trotzdem.
Ist Plane ein echter Jira-Ersatz?
Für engineering-getriebene Teams: ja. Die UX von Plane liegt näher an Linear als an Jira, und sein Vorgangsmodell passt zu Engineering-Workflows. Plane dokumentiert einen kontrollierten Jira-Import, der Projekte, aktive und Backlog-Vorgänge, Zuständige, Labels, Prioritäten, Sprints, Vorgangstypen, Status, benutzerdefinierte Felder, Kommentare und Anhänge abdeckt. Ab 100 Lizenzen gibt es zudem persönliche Migrationsbegleitung, doch Teams mit komplexen Marketplace-Apps oder Workflows sollten trotzdem einen Pilotlauf validieren.
Hat Redmine ein Jira-Migrationswerkzeug?
Offiziell nicht. Es gibt Community-Import-Plugins und CSV-Abläufe, aber Kompatibilität und Datenabdeckung hängen von der Jira- und Redmine-Version ab. Testen Sie den konkreten Weg mit einem repräsentativen Projekt. OpenProject hat einen integrierten Beta-Migrator für unterstützte Jira-Server- oder Data-Center-Quellen, Plane bietet einen geführten eigenen Import.
Kann ich eines davon auf einem kleinen VPS betreiben?
Das Redmine-Image von Cloudzy nennt 2 GB RAM als Minimum, das sind 14,95 $ pro Monat zum Standard-Listenpreis. OpenProject verlangt mindestens vier CPU-Kerne und 4 GB RAM. Plane verlangt 2 Kerne und 4 GB RAM, für die Produktion werden 8 GB empfohlen. Der Standardtarif mit 4 GB von Cloudzy hat 2 vCPU und ist mit 28,95 $ pro Monat gelistet, Aktionen senken das gelegentlich. Alle drei auf einem kleinen VPS zu betreiben, ist kein sinnvolles Produktionsdesign.
