Jira vs. Confluence: zwei Tools oder eine Plattform?

Der Plan für das nächste Release steht in Confluence, die Umsetzung läuft in Jira. Auf der Release-Seite kommt beides zusammen: oben die Beschreibung des Releases, darunter die zugehörigen Jira-Vorgänge. Für das Team ist das ein zusammenhängender Arbeitsablauf.

In vielen Unternehmen funktioniert dieses Zusammenspiel seit Jahren. Wie viel davon auf der Integration zweier eigenständiger Produkte beruht, wird oft erst dann relevant, wenn ein Wechsel ansteht.

Genau vor dieser Situation stehen Unternehmen, die Jira und Confluence als Data-Center-Versionen betreiben. Für beide Produkte hat Atlassian das Supportende auf den 28. März 2029 festgelegt. Damit steht auch die Frage im Raum, wie die gewachsenen Verbindungen zwischen Aufgaben, Anforderungen und Dokumentation künftig funktionieren sollen.

Ein solcher Wechsel ist deshalb mehr als ein Umzug von Tickets und Wiki-Seiten. Er ist eine Gelegenheit, die bisherige Struktur zu hinterfragen: Sollen Arbeit und Wissen weiterhin in zwei integrierten Produkten liegen? Oder künftig auf einer gemeinsamen Plattform?

Jira und Confluence erfüllen unterschiedliche Aufgaben und ergänzen sich. Wer nach „Jira vs. Confluence“ sucht, landet deshalb schnell bei einer grundsätzlicheren Frage: Wie viel Aufwand braucht es, damit zwei Systeme im Alltag wie eines funktionieren?

Key takeaways

1. Jira und Confluence ergänzen sich, bleiben aber eigenständige Produkte

   Jira organisiert Aufgaben und Abläufe, Confluence dokumentiert Wissen. Ihre Verbindung muss über Produktgrenzen hinweg funktionieren, auch bei Berechtigungen, Administration und Lizenzierung.

   
   

2. Wie viel Aufwand die Integration verursacht, zeigt sich besonders bei Veränderungen

   Bei Upgrades, Testkopien und Migrationen müssen Verknüpfungen und Jira-Makros geprüft und gegebenenfalls angepasst werden. Mit dem Ende von Data Center steht für viele Unternehmen ein solcher Wechsel bevor.

   
   

3. Atlassian bündelt seine Produkte in der Cloud

   Die Teamwork Collection bündelt Jira, Confluence, Loom und Rovo in einem Angebot. Atlassian setzt dabei aber auf die Cloud. Wer weiterhin selbst hosten möchte, bekommt mit der Teamwork Collection keine entsprechende Alternative.

   
   

4. Eine gemeinsame Plattform muss sich im Arbeitsalltag bewähren

   Entscheidend ist, wie Aufgaben, Wissen und Berechtigungen zusammenspielen. Sechs Prüffragen helfen zu beurteilen, wie durchgängig ein System tatsächlich funktioniert.

   
   

5. Vor der Toolwahl steht die Bestandsaufnahme

   Welche Seiten enthalten Jira-Abfragen? Welche Arbeitsabläufe hängen davon ab? Wer diese Verbindungen kennt, kann den Migrationsaufwand besser einschätzen und Nachfolgesysteme gezielt prüfen.

Jira vs. Confluence: der Unterschied

Jira organisiert die Umsetzung: Aufgaben, Tickets, Sprints, Fehler und Freigaben. Confluence hält das Wissen dazu fest: Anforderungen, Entscheidungen, Handbücher und Protokolle.

Diese Aufgabenteilung ist klar. Im Arbeitsalltag hängen die Inhalte jedoch eng zusammen. Eine Anforderung in Confluence beschreibt, was entstehen soll. Die verknüpften Jira-Vorgänge zeigen, wie weit die Umsetzung ist. Umgekehrt erklärt die Dokumentation, warum ein Jira-Epic existiert und welche Entscheidungen dahinterstehen.

Die enge Verbindung hat allerdings ihren Preis. Wo Anforderungen, Entscheidungen und Aufgaben über zwei Produkte verteilt sind, müssen Verknüpfungen, Berechtigungen und Abfragen aufeinander abgestimmt bleiben. Besonders bei Upgrades oder einem Systemwechsel zeigt sich, wie viel technische und organisatorische Arbeit dieses Zusammenspiel erfordert.

Für Nutzer:innen wirkt die Kombination wie ein System. Dahinter stehen zwei eigenständige Produkte – und ein Plattformteam, das dafür sorgt, dass sie zusammen funktionieren.

Wie Jira und Confluence miteinander verbunden sind

Zurück zu dem Besipiel der Release-Seite mit der Jira-Tabelle. Damit die Jira-Confluence-Integration auf dieser Seite aktuelle Vorgänge anzeigen kann, müssen drei technische Bausteine zusammenspielen.

Erstens: der Application Link
Er stellt die Vertrauensbeziehung zwischen beiden Anwendungen her und ermöglicht Confluence, Daten aus Jira abzufragen. Beide Produkte bringen dafür eine eigene Version der Application-Links-Komponente mit. Welche Versionen miteinander kompatibel sind, dokumentiert Atlassian in einer Versionsmatrix.

Zweitens: das Jira-Makro
Es fragt die gewünschten Vorgänge aus Jira ab und zeigt sie auf der Confluence-Seite an. Standardmäßig wartet Confluence zehn Sekunden auf eine Antwort. Dauert eine komplexe Abfrage länger, kann das Makro mit einer Fehlermeldung abbrechen.

Drittens: die gespeicherten Verweise
Die Verbindung hängt auch an IDs und URLs, die in den Systemen hinterlegt sind. Ändern sich diese, etwa beim Kopieren einer Umgebung, können bestehende Verknüpfungen ihre Ziele verlieren.

Hinzu kommen zwei Berechtigungsmodelle. Jira steuert Zugriffe über Projekte und Berechtigungsschemata, Confluence über Bereiche und Seiten. Beides muss zusammenpassen. Andernfalls kann eine Person zwar die Dokumentation öffnen, sieht aber die zugehörigen Jira-Vorgänge nicht.

Auch die Lizenzierung bleibt bei Data Center getrennt. Für jedes Produkt wird eine eigene Nutzerstufe benötigt. Was das insgesamt kosten kann, haben wir im Beitrag zu den Jira-Kosten durchgerechnet.

Selbst einfache Verwaltungsaufgaben können dadurch Abstimmung erfordern. Wird ein neues Jira-Projekt angelegt, braucht es möglicherweise auch einen passenden Confluence-Bereich, die richtigen Zugriffsrechte und eine Verbindung zwischen beiden.

Die Release-Seite ist damit das sichtbare Ergebnis mehrerer technischer und organisatorischer Abhängigkeiten. Damit sie wie selbstverständlich funktioniert, muss im Hintergrund einiges zusammenpassen.

Im Alltag hält die Verbindung

Dieser Aufbau bedeutet nicht, dass die Integration ständig Probleme verursacht. Sie ist seit vielen Jahren im Einsatz und funktioniert in gewachsenen Installationen häufig zuverlässig.

Das ist ein gutes Argument für die Kombination. Confluence bietet ein ausgereiftes Wiki mit einem großen Ökosystem an Makros und Apps. Jira ist in vielen Entwicklungsteams fest etabliert. Manche Unternehmen trennen die Administration bewusst, weil Confluence unternehmensweit genutzt wird, Jira dagegen vor allem in der Entwicklung.

Solange sich wenig verändert, bleibt der Aufwand für die Verbindung oft im Hintergrund. Sichtbar wird er vor allem dann, wenn Unternehmen aktualisieren, testen oder migrieren.

Wo die Verbindung bricht: Upgrade, Testkopie, Umzug

Das Upgrade

Jira und Confluence haben eigene Versionsstände und Releasezyklen. Ein Upgrade muss deshalb auch darauf geprüft werden, ob die Verbindung zum jeweils anderen Produkt weiterhin funktioniert.

Hinzu kommen die Marketplace-Apps. Jede installierte App muss mit der neuen Version kompatibel sein. In gewachsenen Installationen ist diese Prüfung oft aufwendiger als die Verbindung selbst. Mehr dazu weiter unten bei den Prüffragen.

Ein dokumentiertes Beispiel stammt aus dem November 2023: Nach einem Upgrade auf Jira 8.20.28 funktionierten Application Links nicht mehr. Betroffen waren unter anderem Jira-Makros in Confluence sowie Such- und Filterfunktionen.

Der Fehler wurde von Atlassian nach wenigen Wochen behoben. Er zeigt jedoch, dass auch ein Update innerhalb eines Produkts Funktionen im anderen beeinträchtigen kann.

Atlassian beschreibt außerdem Fälle, in denen Jira-Makros in Confluence nach einem Upgrade ihren Application Link nicht mehr finden. Die im Makro gespeicherte Application-ID ist dann veraltet und muss aktualisiert werden (Atlassian Support).

Für Nutzer:innen zeigt sich das Problem dort, wo sie aktuelle Informationen erwarten: Die Seite ist erreichbar, die eingebetteten Jira-Vorgänge laden jedoch nicht.

Die Testkopie

Vor einem Upgrade steht häufig ein Test in einer Kopie der Produktivumgebung. Auch hier muss die Verbindung zwischen Jira und Confluence berücksichtigt werden.

Atlassian dokumentiert, dass Verknüpfungen beim Kopieren beider Anwendungen in eine andere Umgebung häufig brechen. Die neuen URLs passen nicht mehr zu den gespeicherten Verweisen. Je nach Situation sind Anpassungen an den Application Links oder an Datenbankeinträgen erforderlich.

Damit gehört zur Testvorbereitung mehr als das Kopieren zweier Anwendungen. Auch ihr Zusammenspiel muss in der neuen Umgebung wiederhergestellt und geprüft werden. Viele Plattformteams haben diese Schritte inzwischen automatisiert. Wo das nicht der Fall ist, fällt der Aufwand bei jeder weiteren Testkopie erneut an.

Der Umzug

Mit dem Ende von Data Center steht eine wesentlich größere Veränderung an. Dabei stellt sich für jedes eingebettete Jira-Makro die Frage: Was bleibt davon im Nachfolgesystem erhalten?

Drei Ergebnisse sind denkbar:

• Eine Live-Abfrage: Die Seite zeigt weiterhin aktuelle Vorgänge und deren Status.

• Eine Momentaufnahme: Übernommen wird nur der Stand zum Zeitpunkt des Exports.

• Ein nicht mehr nutzbarer Verweis: Das Makro oder sein Ziel lässt sich im neuen System nicht sinnvoll auflösen.

Welches Ergebnis entsteht, hängt vom Zielsystem und vom Migrationsverfahren ab. Ebenso wichtig ist, ob Jira und Confluence gemeinsam oder nacheinander abgelöst werden.

Die Prüfpunkte für den Wiki-Teil haben wir im Beitrag zur Confluence-Alternative beschrieben.

Was die Verbindung kostet und warum Abwarten wenig spart

Bis 2029 möglichst wenig zu verändern, klingt zunächst nach einer kostengünstigen Lösung. Der bestehende Betrieb erfordert jedoch weiterhin Wartung und Sicherheitsupdates. Auch dabei muss geprüft werden, ob Jira, Confluence und ihre Verbindung nach der Aktualisierung wie erwartet funktionieren.

Gleichzeitig rücken die Fristen näher. Der Verkauf zusätzlicher Data-Center-Lizenzen und Erweiterungen an Bestandskunden endet am 30. März 2028. Das Supportende für Jira und Confluence Data Center folgt am 28. März 2029. Wer auch danach mit Herstellersupport arbeiten möchte, muss rechtzeitig eine Nachfolgelösung vorbereiten.

Abwarten beseitigt den Migrationsaufwand also nicht. Es verkürzt die Zeit, die bleibt, um Abhängigkeiten zu erfassen, Alternativen zu prüfen und den Wechsel zu testen.

Wie hoch die Kosten der Verbindung ausfallen, lässt sich nicht pauschal beziffern. Für eine belastbare Schätzung brauchen Sie die Daten Ihrer eigenen Installation:

1. Erfassen Sie die Veränderungen: Wie viele Upgrades und Testkopien fallen pro Jahr an?

2. Messen Sie den Integrationsaufwand: Dokumentieren Sie bei den nächsten beiden Durchgängen die Stunden für Application Links, Makros, Verweise und die zugehörigen Tests.

3. Ermitteln Sie die betroffenen Seiten: Welche Confluence-Seiten enthalten Jira-Makros?

4. Bewerten Sie deren Bedeutung: Welche Abfragen müssen live bleiben, wo reicht eine Momentaufnahme und welche Inhalte können entfallen? Schätzen Sie den Prüf- und Anpassungsaufwand pro Gruppe.

5. Vergleichen Sie über denselben Zeitraum: Rechnen Sie die Stunden mit Ihren internen oder externen Kostensätzen hoch. Stellen Sie diesen Aufwand den Betriebs-, Integrations- und Migrationskosten der Alternativen gegenüber.

Was Atlassian selbst anbietet

Mit der Teamwork Collection bündelt Atlassian Jira, Confluence, Loom und Rovo in einem gemeinsamen Angebot. Die Anwendungen bleiben eigenständige Produkte, werden aber gemeinsam angeboten und technisch enger miteinander verbunden. Die Collection ist ausschließlich in der Atlassian Cloud verfügbar.

Eine zentrale Rolle spielt dabei der Teamwork Graph. Diese gemeinsame Datenebene verknüpft Informationen aus unterschiedlichen Anwendungen und stellt sie unter anderem für Rovo bereit.

Auch Inhalte aus Jira Data Center lassen sich über einen Connector einbeziehen. Dafür wird jedoch eine Atlassian-Cloud-Umgebung benötigt. Der Connector indexiert unter anderem Projekte, Vorgänge und Kommentare aus der selbst betriebenen Installation. Weitere Details zum KI-Teil finden Sie im Beitrag zu Atlassian Rovo.

Mit der Anbindung verarbeitet ein Cloud-Dienst von Atlassian Inhalte aus der selbst betriebenen Installation. Für regulierte Unternehmen gehört deshalb auch die aufsichtsrechtliche Einordnung zur Prüfung. Bei Finanzunternehmen in der EU können die DORA-Anforderungen an IKT-Drittdienstleistungen relevant sein. Für Betreiber kritischer Infrastrukturen und andere Einrichtungen im Anwendungsbereich von NIS2 können die Anforderungen an die Sicherheit der Lieferkette relevant sein, wie sie die nationalen Umsetzungsgesetze vorsehen. In der Schweiz sind die jeweils anwendbaren FINMA-Vorgaben zu berücksichtigen. Welche Dokumentations-, Prüf- oder Meldepflichten entstehen, hängt vom konkreten Einsatz ab.

Atlassians Weg zu einer enger verbundenen Produktwelt führt damit über die Cloud. Für Unternehmen, die vollständig im Eigenbetrieb bleiben möchten, bietet die Teamwork Collection keine entsprechende Betriebsoption.

Was „eine Plattform“ heißen muss: sechs Prüffragen

Ob Atlassian Cloud, zwei eigenständige Tools oder eine gemeinsame Plattform: Entscheidend ist, wie die Lösung Ihre tatsächlichen Arbeitsabläufe unterstützt.

Die Release-Seite mit der Jira-Tabelle eignet sich dafür als konkretes Prüfstück.

1. Fragt die Seite ein zweites System ab? Auch innerhalb einer Plattform ist eine gefilterte Liste eine Abfrage. Entscheidend ist, ob dafür eine zusätzliche Produktintegration mit eigener Authentifizierung, Versionskompatibilität und Fehlerbehandlung benötigt wird.

   
   

2. Gibt es ein gemeinsames Berechtigungsmodell?

   Prüfen Sie, wie Rollen und Gruppen für Seiten und Aufgaben zusammenspielen. Lassen sich Administrationsrechte trotzdem gezielt trennen, sodass etwa ein Wiki-Team seine Bereiche verwalten kann, ohne Workflows anderer Teams zu verändern?

   
   

3. Wie funktionieren Nutzerverwaltung und Lizenzierung?
   Klären Sie, ob Konten zentral verwaltet werden und wie der Zugriff auf Aufgaben und Wiki abgerechnet wird. Bei getrennten Produkten können unterschiedliche Nutzerzahlen, Tarifstufen und Vertragsbedingungen relevant sein.

   
   

4. Was wird aus Ihren bestehenden Verknüpfungen?
   Lassen Sie sich an einer eigenen Seite zeigen, was nach der Migration erhalten bleibt. Zeigt sie weiterhin aktuelle Vorgänge, nur einen exportierten Stand oder lediglich einen Link?

   
   

5. Wie werden Updates und Exporte gehandhabt?
   Fragen Sie, ob Aufgaben und Wiki gemeinsam aktualisiert werden. Prüfen Sie außerdem, ob ein Export beide Bereiche einschließlich ihrer Verknüpfungen umfasst.

   
   

6. Was kosten Betrieb und Ausstieg über die gesamte Laufzeit?
   Berücksichtigen Sie neben den Lizenzkosten auch Administration, Integrationen, Migration und einen späteren Wechsel. Lassen Sie sich Vertragslaufzeiten, Preisanpassungen und Exportmöglichkeiten schriftlich bestätigen.

Zwei getrennte Tools bleiben die bessere Wahl, wenn nur eine Seite das Problem ist: Manche Unternehmen wollen nur ihr Wiki ablösen, andere nur Jira.

Bei der Migration wiegt oft ein anderer Punkt schwerer als die Verbindung selbst. Viele Jira-Confluence-Installationen sind über Jahre mit Marketplace-Apps gewachsen. ScriptRunner-Skripte, Testmanagement, Zeiterfassung oder Diagramm-Makros auf Confluence-Seiten finden sich nicht automatisch in einer integrierten Plattform. Für jede dieser Erweiterungen braucht es eine eigene Entscheidung: übernehmen, ersetzen oder aufgeben.

Die Fragen helfen, solche Abhängigkeiten früh sichtbar zu machen und den Aufwand zu erkennen, der nach dem Wechsel bestehen bleibt.

Wo sovara in diese Prüfung passt

sovara ist eine europäische Alternative zu Jira und Confluence. Aufgaben, Wiki-Seiten und Anfragen sind in sovara dieselbe Art von Element. Suche, Berichte, Automationen und Berechtigungen funktionieren deshalb für alle gleich. Damit setzt sovara direkt bei dem Aufwand an, Aufgaben und Dokumentation über zwei Produkte hinweg zu verbinden.

Wie gut das zur eigenen Installation passt, sollte sich an denselben sechs Fragen zeigen.

Seite und Aufgaben in einem System

Eine Wiki-Seite in sovara kann die mit ihr verknüpften Tickets oder ihre Unterseiten als Tabelle anzeigen. Seite und Tickets liegen im selben System. Eine zusätzliche Integration zwischen Wiki und Aufgabenverwaltung ist dafür nicht erforderlich.

Berechtigungen und Nutzerverwaltung

Rollen und Administrationsrechte werden pro Projekt vergeben. Ein Wiki-Team kann dadurch seine Bereiche verwalten, ohne Zugriffsrechte auf die Workflows anderer Projekte zu erhalten.

Die Anmeldung erfolgt per SSO, beispielsweise über Microsoft Entra ID. Konten und Gruppen lassen sich per SCIM aus dem Identitätsdienst übernehmen.

sovara läuft als SaaS, das rready in der EU betreibt, mit Rechenzentrum in Deutschland. Alternativ betreiben Sie sovara selbst auf Ihrem eigenen Kubernetes oder auf Red Hat OpenShift, im Rechenzentrum oder in einer Private Cloud (Sovereign Trust Center). Beide Varianten nutzen dieselbe Software in denselben Versionen. Der Eigenbetrieb unterscheidet sich nur in der Konfiguration.

sovara erscheint in häufigen, versionierten Releases mit Release Notes, dazwischen gibt es Fehlerbehebungen. Ein Update umfasst Aufgabenverwaltung und Wiki gemeinsam.

Im Eigenbetrieb entscheiden Sie, wann Sie aktualisieren. rready spielt keine Updates ein. Jedes Release ist ein festes, nummeriertes Paket mit genau festgelegten Komponentenversionen. Ein Upgrade lässt sich dadurch wiederholen, zuerst in der Testumgebung und dann in der Produktion. Die meisten Releases lassen sich ohne Ausfallzeit installieren. Mit jedem Release kommt ein automatisiertes Testpaket, mit dem Sie direkt nach dem Upgrade prüfen, ob alles funktioniert. Projekte, Workflows und Automationen lassen sich aus der Testumgebung exportieren und in die Produktion übernehmen.

Die Installation funktioniert auch ohne Internetzugang. Inhalte lassen sich per API oder Kommandozeile als JSON exportieren, Texte bleiben dabei im Markdown-Format. Ticketlisten lassen sich zusätzlich als CSV oder Excel exportieren.

Automationen, Diagramme, Zeiterfassung und Tests

Automationen, Testmanagement, Zeiterfassung und Diagramme sind Teil der Plattform. Zusätzliche App-Lizenzen fallen dafür nicht an.

Automationen starten bei Ereignissen, etwa wenn ein Element angelegt wird, den Status wechselt, zugewiesen wird oder sich ein Feld ändert. Dazu kommen zeitgesteuerte Jobs, skriptbasierte Automationen, Webhooks an andere Systeme und Workflow-Schaltflächen: Wer ein Element per Klick in den nächsten Status setzt, kann damit eine Automation starten. Bestehende ScriptRunner-Skripte werden bei der Migration neu geschrieben. Eins zu eins übernehmen lassen sie sich nicht.

Diagramme in Mermaid, draw.io und BPMN liegen direkt auf der Seite. draw.io-Diagramme wurden in Kundenmigrationen bereits übernommen. Gliffy-Diagramme werden nicht automatisch übernommen, exportieren Sie diese vorher separat. Miro-Boards lassen sich über einen öffentlichen Board-Link einbetten.

Für die persönliche Zeiterfassung buchen Nutzer:innen Zeit direkt auf ein Ticket oder ziehen Zeitblöcke in einen Kalender. Eine Wochenansicht zeigt die eigenen Zeiten über alle Projekte.

Das Testmanagement ist eingebaut und entwickelt sich schnell weiter. Es wird pro Kunde aktiviert, ohne zusätzliche Lizenz. Testfälle mit einzelnen Schritten lassen sich wiederverwenden und pro Release zu Testläufen bündeln. Beim Testen wird jeder Schritt als bestanden oder fehlgeschlagen markiert. Die Testabdeckung ist direkt am Feature-Ticket sichtbar.

Migration bestehender Inhalte

Für Standard-Setups aus Jira bietet rready eine Geld-zurück-Garantie auf die Migration. Sie umfasst Tickets, Workflows, Automationen und die Kernkonfiguration. Plugins und eigener Code sind ausgenommen. Die Garantie gilt für die Jira-Migration. Confluence-Inhalte sind darin nicht eingeschlossen.

Für die Release-Seite aus unserem Beispiel ist entscheidend, wie die bisherige Jira-Abfrage im neuen System abgebildet wird. sovara hat eine eigene Abfragesprache. Gespeicherte Jira-Filter lassen sich darin nachbauen. sovara kann außerdem die mit einer Release-Seite verknüpften Tickets anzeigen. Wie aus einem bestehenden Confluence-Makro diese Verknüpfungen entstehen, muss im konkreten Migrationsumfang geklärt werden.

Einen Vergleich auf Funktionsebene finden Sie auf der Seite sovara im Vergleich mit Jira und Confluence.

Erst die eigenen Seiten, dann die Toolwahl

Die Release-Seite steht für einen Teil Ihrer Installation, der in keiner Lizenzübersicht sichtbar wird: die gewachsene Verbindung zwischen Aufgaben und Wissen.

Verschaffen Sie sich deshalb einen Überblick, bevor Sie Anbieter vergleichen. Mit der Confluence-Suchsprache CQL können Sie nach Seiten mit Jira-Makros suchen: macro in (jira, jirachart). Die Abfrage findet Seiten mit eingebundenen Jira-Vorgängen und mit Jira-Diagrammen. Seitenvorlagen erfasst sie nicht. Prüfen Sie Vorlagen deshalb separat. Ergänzen Sie diese Bestandsaufnahme, soweit verfügbar, um Nutzungsdaten aus Confluence Analytics.

Halten Sie für jede relevante Seite fest:

• Welche Jira-Abfrage ist eingebunden?

• Welche weiteren Makros aus Marketplace-Apps nutzt die Seite?

• Wer nutzt die Seite und für welchen Arbeitsablauf?

• Muss die Anzeige im Nachfolgesystem live bleiben?

• Welche Folgen hätte es, wenn die Verbindung entfällt?

Diese Liste bildet die Grundlage für Ihre Aufwandsschätzung und Migrationsplanung.

Wählen Sie daraus zehn repräsentative Seiten aus unterschiedlichen Bereichen. Lassen Sie jedes Nachfolgesystem an denselben Beispielen zeigen, wie Aufgaben, Dokumentation und ihre Verknüpfungen nach dem Wechsel funktionieren – möglichst in einer Testinstanz mit Ihren eigenen Daten und vor Vertragsabschluss.

So prüfen Sie konkret, ob eine gemeinsame Plattform den bisherigen Integrationsaufwand reduziert und die Arbeitsabläufe Ihres Unternehmens unterstützt.

Wie Sie die Entscheidung insgesamt strukturieren, beschreibt unser Entscheidungsrahmen für die Migration bis 2029.

FAQs

Sind Jira und Confluence das Gleiche?

Nein. Jira verwaltet Aufgaben, Confluence Dokumentation. Beide stammen von Atlassian und werden getrennt lizenziert. Confluence und Jira lassen sich über Application Links verbinden.

Wird Confluence eingestellt?

Nein, aber die selbst betriebene Variante läuft aus. Für Confluence Data Center endet der Support am 28. März 2029. Die Cloud-Version entwickelt Atlassian weiter. Mehr dazu im Beitrag zum Ende von Atlassian Data Center.

Gibt es Jira und Confluence in einem Tool?

Atlassians Teamwork Collection ist ein gemeinsames Cloud-Abonnement, die Produkte bleiben getrennt. Andere Anbieter, darunter sovara, decken Aufgaben und Wiki in einer Plattform ab. Eine Übersicht bietet unser Vergleich der europäischen Alternativen zu Jira und Confluence.

Was kostet Confluence zusätzlich zu Jira?

Confluence wird getrennt von Jira lizenziert, bei Data Center jeweils mit eigener Nutzerstufe. Eine Beispielrechnung für beide Produkte finden Sie in unserem Beitrag zu den Jira-Kosten.