Da Atlassian das Ende des Supports für Jira Data Center im März 2029 angekündigt hat, prüfen viele Unternehmen derzeit intensiv, wie es weitergehen soll. OpenProject hat sich zu einer der überzeugendsten Open-Source-Antworten auf diese Frage entwickelt. Es ist eine souveräne Plattform, die sich selbst hosten lässt und Projektmanagement, Produktmanagement, Issue-Tracking, Gantt-Diagramme, agile Boards sowie die Zusammenarbeit im Team in einer einzigen Anwendung vereint.
Doch der Wechsel der Anwendungen für das Projektmanagement einer Organisation ist niemals nur ein Datenexport. Er betrifft gleichzeitig Menschen, Prozesse und Daten. Die Frage, die uns von Teams, die ihren Jira-Ausstieg planen, am häufigsten gestellt wird, ist einfach: Wie sollen wir eigentlich migrieren?
Es gibt keine einzig richtige Antwort. Die passende Strategie hängt von der Größe Ihrer Organisation ab, von der Komplexität Ihrer Jira-Konfiguration, von Ihrer Risikobereitschaft, von den Abhängigkeiten zwischen den Teams und von Ihrer Unternehmenskultur. Dieser Artikel führt Sie durch die drei wichtigsten Migrationsstrategien, ihre Vor- und Nachteile sowie die jeweils am besten geeigneten Szenarien. Zum Ende gibt es einen Ansatz, den wir heute den meisten Unternehmen empfehlen.
Schnellnavigation:
- Kurzer Hinweis zum OpenProject Jira Migrator
- Drei Migrationsstrategien
- Die Strategien im Überblick
- Unsere Empfehlung: Pilot-First, dann Phased Wave
- Was erfolgreiche Migrationen von herausfordernden Migrationen unterscheidet
- Wichtige Risiken, die Sie im Blick behalten sollten
- Zusammenfassung
- Weiterführende Literatur
Kurzer Hinweis zum OpenProject Jira Migrator
Bevor wir über die Strategie sprechen, lohnt sich ein Blick darauf, welche Werkzeuge zur Verfügung stehen.
OpenProject bringt einen integrierten Jira Migrator mit, der seit Anfang 2026 verfügbar ist und sich derzeit in der Beta-Phase befindet. Er verbindet sich über einen Personal Access Token mit Jira Data Center 10.x und 11.x und überträgt die Daten über die API in OpenProject. Jira Cloud wird derzeit noch nicht unterstützt, ist jedoch in der Roadmap vorgesehen.
Was der Migrator aktuell importiert:
- Projekte (einzeln wählbar)
- Tickets, einschließlich Zusammenfassung, Beschreibung, Anhängen, Verlauf und Kommentaren
- Nutzer (Name, E-Mail, Projektmitgliedschaft) und Gruppen
- Status und Ticket-Typen
- Selbstdefinierte Felder, für die es in OpenProject eine Entsprechung gibt
Was noch auf der Roadmap steht und derzeit nicht abgedeckt ist:
- Beziehungen zwischen Tickets
- Sprint-Zuweisungen
- Workflows auf Projektebene
- Berechtigungen
- Schemas
- Bezeichnungen (Labels)
- Fix Versions und Affected Versions
- Komponenten
Hinweis
Der Jira Migrator wird aktiv weiterentwickelt, und wir veröffentlichen jeden Monat Verbesserungen. Werfen Sie vor der Planung einer Migration immer einen Blick in die Dokumentation zum Jira Migrator und in die Release Notes. Manche Lücken, die heute bestehen, sind bis zu Ihrem Start womöglich bereits geschlossen.
Drei Migrationsstrategien
Strategie A: Big Bang (direkte Umstellung)
Alle Teams und Projekte wechseln an einem einzigen, vorab festgelegten Umstellungstermin von Jira zu OpenProject. Jira wird unmittelbar danach außer Betrieb genommen.
Vorteile: Die Umstellung ist in einem einzigen Schritt abgeschlossen, die langfristigen Betriebskosten sind geringer, da kein Parallelbetrieb nötig ist, die Kommunikation ist einfacher, da alle Beteiligten gleichzeitig umstellen, es müssen keine zwei Systeme synchron gehalten werden, und alle Teams arbeiten zu jedem Zeitpunkt in derselben Anwendung.
Nachteile: Das Risiko ist hoch, da sich jeder Fehler bei der Migration unmittelbar auf das gesamte Unternehmen auswirkt. Der Bedarf an Schulungen konzentriert sich auf einen kurzen Zeitraum; ein Rollback würde die Wiederherstellung von Jira aus einem Backup bedeuten, was zu Betriebsunterbrechungen führt, und der Aufwand für das Änderungsmanagement häuft sich in einem engen Zeitfenster.
Am besten geeignet für: kleine Organisationen (unter 250 Nutzer), einfache Jira-Konfigurationen mit wenigen selbstdefinierten Feldern oder Situationen, in denen die Jira-Lizenzen zu einem festen Termin auslaufen.
Strategie B: Phased/Wave (phasen- bzw. stufenweise Migration)
Teams oder Geschäftsbereiche wechseln in aufeinanderfolgenden Phasen über Wochen oder Monate hinweg. Jede Phase nutzt die Erkenntnisse aus der vorherigen.
Vorteile: Das Risiko ist begrenzt, da Probleme in einer Phase nicht alle Teams betreffen. Der Jira Migrator lässt sich zwischen den Phasen anpassen, sobald neue Funktionen verfügbar sind, Schulungs- und Support-Materialien verbessern sich Schritt für Schritt, frühe Anwender werden zu internen Beratern für spätere Phasen, und der Aufwand für das Change Management verteilt sich über die Zeit.
Nachteile: Jira und OpenProject laufen während der Migrationsphase parallel; teamübergreifende Abhängigkeiten werden komplexer, wenn die Teams unterschiedliche Tools verwenden; und es bedarf einer klaren Steuerung, um die Reihenfolge der Migrationsphasen festzulegen.
Am besten geeignet für: große Unternehmen mit vielen Teams und unterschiedlichen Projektarten. Dies ist bei weitem der am häufigsten anzutreffende Ansatz in Unternehmen.
Strategie C: Pilot-First (Proof of Concept)
Ein einzelnes Team oder Projekt wechselt zuerst, als Proof of Concept. Die Ergebnisse werden dokumentiert und dazu genutzt, das Migrationshandbuch vor einer umfassenderen Einführung weiter zu optimieren.
Ein typisches Pilotprojekt läuft wie folgt ab: Sie wählen ein Team mit sehr geringen externen Abhängigkeiten aus, bestimmen Fürsprecher, erfassen die aktuellen Prozesse in einem Workshop, richten eine Staging-Umgebung ein, lassen das Team diese testen, vereinbaren einen Umstellungstermin, “frieren” Jira ein (idealerweise über ein Wochenende), migrieren in die Produktionsumgebung und geben OpenProject anschließend für den täglichen Einsatz frei.
Vorteile: Das Risiko ist sehr gering, da nur ein Team betroffen ist. Der Ansatz erprobt sowohl den Jira Migrator als auch OpenProject in einer realen Umgebung, liefert konkrete Belege für Beteiligte und die Geschäftsleitung, deckt Probleme mit der Datenqualität und Unstimmigkeiten frühzeitig auf, erzeugt Nutzerfeedback, verbessert die Schulungsmaterialien kontinuierlich, und frühe Anwender werden zu Beratern für spätere Migrationen.
Nachteile: Während der Pilotphase läuft der Parallelbetrieb weiter, und das Pilotteam trägt in der Testphase eine zusätzliche Last.
Am besten geeignet für: Unternehmen, die OpenProject noch nicht kennen und das Tool zunächst testen möchten, bevor sie sich festlegen, sowie solche, die große Ziele verfolgen, aber klein anfangen möchten. Ein Pilotprojekt eignet sich zudem sehr gut als erster Schritt einer schrittweisen Migration.
Die Strategien im Überblick
| Strategie | Risikoniveau | Dauer | Umfang pro Phase | Maßnahmen im Bereich Schulung und Änderungsmanagement | Betriebskosten | Zentrale Software |
|---|---|---|---|---|---|---|
| Big Bang | Hoch | Kurz | Gesamte Organisation auf einmal | Verdichtet | Niedrig (kein Parallelbetrieb) | Jira Migrator |
| Phased / Wave | Mittel | Mittel bis lang | Eine Stufe nach der anderen | Über einen bestimmten Zeitraum verteilt. Frühanwender werden zu internen Experten. | Mittel (Parallelbetrieb pro Stufe) | Jira Migrator |
| Pilot-First | Sehr niedrig | Mittel bis lang | Erst ein Team, dann phasenweise | Gering, zunächst auf frühe Anwender beschränkt. | Niedrig (nur Pilot) | Jira Migrator |
Unsere Empfehlung: Pilot-First, dann Phased Wave
Angesichts des aktuellen Stands des Jira Migrators (produktionsreif für Kerndaten, bei erweiterten Funktionen noch in der Weiterentwicklung), der bewährten Verfahren für Unternehmensmigrationen sowie der Anforderungen, die das Änderungsmanagement an reale Organisationen stellt, empfehlen wir den meisten Organisationen folgenden Ansatz: Beginnen Sie mit einem kontrollierten Pilotprojekt und migrieren Sie anschließend den Rest der Organisation schrittweise.
So sieht das in der Praxis aus.
Phase 1: Vorbereitung (4 bis 6 Wochen)
- Wählen Sie ein Pilotprojekt von mittlerer Komplexität aus – weder das einfachste noch das komplizierteste. Keine oder nur wenige externe Abhängigkeiten sind von Vorteil.
- Installieren und konfigurieren Sie OpenProject (selbst gehostet oder in der Cloud) sowohl in der Staging- als auch in der Produktionsumgebung und sorgen Sie dabei für eine angemessene Dimensionierung der Infrastruktur.
- Überprüfen Sie Ihre Daten aus Jira: Erfassen Sie die Projekte, selbstdefinierte Felder, Workflows, Ticket-Typen, Nutzergruppen und Integrationen (GitHub, Confluence-Verknüpfungen usw.).
- Testen Sie die API-Verbindung, damit OpenProject die Daten aus Jira abrufen kann.
- Schulen Sie die Administratoren und das Pilotteam und erklären Sie den Beteiligten klar, wo sie Hilfe erhalten können.
Tipp
Sie können die Pilotmigration bereits heute mit dem Jira Migrator von OpenProject durchführen. Es gibt keinen Grund zu warten. Sollten Sie zusätzliche Unterstützung benötigen, kann unser Team das Pilotprojekt direkt unterstützen.
Phase 2: Pilot-Migration (2 bis 4 Wochen)
- Führen Sie den Migrator für die Projekte des Pilotteams in der Staging-Umgebung aus.
- Überprüfen Sie die migrierten Daten: Tickets, Beschreibungen, Anhänge, Nutzerzuweisungen.
- Dokumentieren Sie die Lücken: benutzerdefinierte Felder, Beziehungen und alles, was der Jira Migrator noch nicht unterstützt.
- Konfigurieren Sie OpenProject bei Bedarf manuell, um diese Lücken zu schließen.
- Führen Sie Nutzerakzeptanztests (UAT) in der Staging-Umgebung durch.
- Sobald der UAT erfolgreich ist, wiederholen Sie die Migration in der Produktionsumgebung.
- Vereinbaren Sie mit dem Pilotteam einen Termin für die Inbetriebnahme und führen Sie die Umstellung durch.
- Sammeln Sie wöchentlich Feedback, halten Sie gewonnene Erkenntnisse fest und aktualisieren Sie den Leitfaden.
Phase 3: Schrittweise Einführung (2 bis 3 Wochen pro Phase)
- Ordnen Sie die Phasen nach der Komplexität der Teams: einfachere Teams zuerst, komplexere Teams zuletzt.
- Führen Sie den Migrator für die ausgewählten Projekte stufenweise aus.
- Verwenden Sie die Vorbereitungscheckliste aus dem Pilotprojekt erneut. Es kann nun auch als allgemeiner Leitfaden dienen.
- Bieten Sie für jede Phase gezielte Schulungen und Sprechstunden an.
- Sammeln Sie wöchentlich Feedback und lassen Sie die gewonnenen Erkenntnisse in künftige Phasen einfließen.
- Erfassen Sie verschiedene Metriken: Dauer der Migration, Datenqualitätswerte, Nutzerzufriedenheit.
Phase 4: Umstellung und Außerbetriebnahme
- Sobald alle Durchläufe abgeschlossen sind, legen Sie ein endgültiges Datum für den schreibgeschützten Modus in Jira fest (Archivmodus).
- Behalten Sie eine schreibgeschützte Jira-Instanz für etwa drei Monate als Referenz bereit.
- Stellen Sie die Jira-Lizenzen und die Infrastruktur nach Ablauf der Archivierungsfrist außer Betrieb.
- Führen Sie eine Retrospektive nach der Migration durch und aktualisieren Sie Ihre interne Prozessdokumentation.
Was erfolgreiche Migrationen von herausfordernden Migrationen unterscheidet
Die Werkzeuge sind zwar wichtig, doch die Migrationen, die gut verlaufen, sind fast immer jene, bei denen die Teams einige nichttechnische Methoden ebenfalls ernst nehmen.
Datenqualität. Bereinigen Sie die Daten vor der Migration. Schließen Sie veraltete Tickets, entfernen Sie ungenutzte benutzerdefinierte Felder und bereinigen Sie doppelte Benutzer. Führen Sie niemals eine Migration von Produktionsdaten durch, ohne dass verifizierte Sicherungskopien sowohl von Jira als auch von OpenProject vorliegen. Nutzen Sie die Überprüfungsmöglichkeiten des Jira Migrators, um die Importe vor der Freigabe zu prüfen.
[!IMPORTANT] Sobald ein Import im Jira Migrator freigegeben ist, lässt er sich nicht mehr rückgängig machen. Prüfen Sie die importierten Daten immer zuerst im Review-Modus.
Change Management. Kommunizieren Sie frühzeitig und regelmäßig, und unterschätzen Sie nicht, wie viel Kommunikation eine Migration braucht. Kündigen Sie Zeitpläne und Auswirkungen mindestens vier Wochen vor jeder Phase an. Benennen Sie in jedem Team Verantwortliche für OpenProject, die ihre Kolleginnen und Kollegen unterstützen können. Führen Sie praxisorientierte Workshops durch und beschränken Sie sich nicht nur auf die Dokumentation, denn Menschen lernen am besten durch praktische Anwendung. Halten Sie während der gesamten Migration einen Kanal für Rückmeldungen offen, sei es ein Chat, ein E-Mail-Alias oder ein eigens dafür eingerichtetes OpenProject-Helpdesk-Projekt. Gerne begleiten wir Sie auch auf Ihrem Weg der Migration mit bewährten Verfahren, Schulungen oder maßgeschneiderten Beratungsleistungen, die genau auf Ihre Bedürfnisse zugeschnitten sind.
Technische Absicherung. Führen Sie Tests stets zunächst in der Staging-Umgebung durch, bevor Sie sie in der Produktionsumgebung ausführen. Der integrierte Jira Migrator benötigt einen Personal Access Token mit Administratorrechten aus Jira, gehen Sie mit diesen Zugangsdaten also sorgfältig um.
Überprüfung nach der Migration. Vergleichen Sie die Anzahl der Tickets, die Anzahl der Anhänge und die Nutzermitgliedschaften zwischen Jira und OpenProject. Überwachen Sie die Leistung von OpenProject nach jeder Phase, insbesondere bei umfangreichen Importen. Archivieren Sie Jira-Projekte, anstatt sie zu löschen, bis jedes Team eine erfolgreiche Migration bestätigt hat, und passen Sie Ihre interne Dokumentation für Entwickler- und Projektmanagement an die Arbeitsabläufe von OpenProject an.
Wichtige Risiken, die Sie im Blick behalten sollten
| Risiko | Schweregrad | Gegenmaßnahme |
|---|---|---|
| Datenverlust während der Migration | Hoch | Erstellen Sie von beiden Systemen Sicherungskopien; nutzen Sie den Review-Modus, bevor Sie die Freigabe erteilen; führen Sie zunächst einen Pilotversuch durch. |
| Mangelnde Akzeptanz bei den Nutzern | Hoch | Investieren Sie frühzeitig in Change Management, Fürsprecher und Schulungen; holen Sie kontinuierlich Feedback ein. Man kann gar nicht zu viel kommunizieren. Beziehen Sie die Nutzer frühzeitig in den Veränderungsprozess ein, um ein Gefühl der Eigenverantwortung für die Veränderung zu schaffen. |
| Fehler bei der Zuordnung benutzerdefinierter Felder | Mittel | Dokumentieren Sie Zuordnungen; Validieren Sie Stichproben vor der vollständigen Migration. |
| Instabilität des Migrations Werkzeugs (Beta) | Niedrig–Mittel | Führen Sie eine Staging-Umgebung ein; überprüfen Sie die Ergebnisse der Migration. |
Zusammenfassung
Die Migration von Jira zu OpenProject ist ein umfangreiches, aber machbares Vorhaben. Der OpenProject Jira Migrator bietet bereits eine solide Grundlage, um mit begrenztem technischem Aufwand die Kerndaten zu importieren, auf die sich die meisten Teams stützen. Die Roadmap schließt die verbleibenden Lücken Monat für Monat.
Die von uns empfohlene Strategie – zunächst ein Pilotprojekt, gefolgt von einer schrittweisen Migration – schafft ein Gleichgewicht zwischen Risikominimierung und betrieblicher Effizienz. Sie gibt den Migrationsprogrammen Zeit zu reifen, gibt den Teams Zeit, OpenProject kennenzulernen, und stellt sicher, dass jede Stufe von den Erkenntnissen der vorherigen profitiert. Eine “Big Bang”-Umstellung sollten Sie nur in Betracht ziehen, wenn die Organisation klein und die Jira-Konfiguration einfach ist, und der Migrator alles abdeckt, was Sie benötigen.
Der Erfolg hängt gleichermaßen von der technischen Umsetzung und vom Management der Veränderungen ab. Ob die neue Anwendung angenommen oder abgelehnt wird, entscheidet sich an Investitionen in Nutzerschulungen, interne Fürsprecher und klare Kommunikation, und zwar unabhängig davon, wie sauber die Datenmigration verläuft. Für weitere Anregungen dazu, wie man den Wandel von Closed Source zu Open Source gestaltet, empfehlen wir den Vortrag von Rosanna Sibora (CPO bei OpenProject) von der FOSDEM.
Der sinnvollste nächste Schritt, den Sie diese Woche gehen können, ist die Wahl eines Pilotteams und die Migration von dessen erstem Projekt. Von einem echten Piloten werden Sie mehr lernen als in drei Monaten voller Planungstreffen. Beginnen Sie mit der Planung Ihrer ersten Migration und führen Sie Ihre Projekte und Ihre Organisation Schritt für Schritt zu Ihrer neuen, vollständig souveränen digitalen Lösung.
Weiterführende Literatur
- Dokumentation zur Migration von Jira zu OpenProject
- OpenProject als Alternative zu Jira Data Center
- OpenProject Roadmap: Ausstieg aus Jira
- Förderung der Nutzerakzeptanz und Anleiten des Wandels beim Umstieg von Jira auf OpenProject
- Ihre Lösung für den Ausstieg aus Jira: der OpenProject Jira Migrator
- OpenProject Gundlagen Handbuch
Haben Sie Fragen zu den Migrationswerkzeugen von OpenProject oder dazu, wie Sie Ihren Ausstieg aus Jira planen können? Kontaktieren Sie unser Team.
