Supportende für Atlassian Connect am 31. Januar 2027: Eigene Jira- und Confluence-Apps auf Forge umziehen

ein rotes Puzzleteil zwischen grünen Teilen

Am 31. Januar 2027 beendet Atlassian den Support für Connect, das Framework, auf dem die meisten älteren Apps für Jira und Confluence Cloud gebaut wurden. Ab diesem Tag wird Atlassian nach eigener Aussage „in Connect nur noch kritische Sicherheitslücken beheben“, und eine private App, die noch auf Connect läuft, „wird nicht mehr unterstützt und funktioniert möglicherweise nicht mehr richtig“.

Wenn jede App auf Ihrer Site aus dem Atlassian Marketplace stammt, ist das Aufgabe Ihrer Anbieter, und die meisten haben sie erledigt: Atlassian meldete im August 2026, dass „über 95 % der bezahlten App-Plätze auf Forge migriert wurden“.

Dieser Artikel behandelt den anderen Fall. Ihr Unternehmen hat eine Jira- oder Confluence-App, die jemand für Sie gebaut hat: ein interner Entwickler, ein Auftragnehmer, ein Partner. Sie wurde per Link installiert, nicht gekauft. Niemand außerhalb Ihres Unternehmens wird sie umziehen, und die Person, die sie geschrieben hat, ist womöglich nicht mehr da.

Was das Supportende bedeutet und was nicht

Ein Abschaltdatum ist nicht veröffentlicht. Atlassian hat nicht gesagt, dass Connect-Apps am 1. Februar 2027 aufhören zu laufen, und in der ursprünglichen Ankündigung des Zeitplans hieß es, dass „Kunden, die Connect-Apps installiert haben, den Zugriff auf die App nicht verlieren“.

Lesen Sie das nicht als Sicherheit. Was sich ändert, ist, dass sich bei Atlassian niemand mehr um Connect kümmert:

Nur kritische Sicherheitslücken werden behoben. Nicht kritische Fehler bleiben.
„Funktionen von Connect werden mit wenig Vorlauf abgekündigt.“
Der Atlassian Support „kann Probleme, die von dieser veralteten Technologie verursacht werden, nicht beheben“.
In Atlassians eigenen Worten: „Connect wird nach dem Supportende nicht in einem stabilen Zustand bleiben. Ausfälle werden zunehmen und Kompatibilitätslücken größer werden.“

Das Risiko kommt also schleichend, nicht als Klippe. Ein plausibler Ausfall: Jira ändert eine Seite, ein Connect-Panel wird nicht mehr angezeigt, und es gibt niemanden, bei dem Sie ein Ticket aufmachen können. Wenn diese App in einer Freigabe der Finanzabteilung oder in einem Service Desk für Kunden steckt, erfahren Sie davon von den Leuten, die darauf angewiesen sind.

Was bereits passiert ist

Der Januartermin ist der letzte Schritt einer Abfolge, die 2025 begonnen hat.

September 2025: Der Marketplace nimmt keine neuen Connect-Apps mehr an.
31. März 2026: Die Updates wurden eingefroren. Atlassians Hinweise für individuelle Apps sagten es klar: Nach diesem Datum „können Sie keine Updates mehr an Connect-Apps ausliefern“. Den Code auf Ihrem eigenen Server dürfen Sie weiter ändern, aber was die App gegenüber Jira oder Confluence deklariert (ihre Module, Scopes und Webhooks), steht fest.
März 2026: Der Zeitplan sagte außerdem, dass „die Möglichkeit, neue private Connect-Apps über Connected Apps zu installieren, nicht mehr verfügbar sein wird“. Behandeln Sie eine Deinstallation als Einbahnstraße: Entfernen Sie keine private Connect-App, nur um zu sehen, was kaputtgeht.
August 2026: Atlassian hat das Supportende von Dezember 2026 auf den 31. Januar 2027 verschoben. Das ist ein zusätzlicher Monat. Planen Sie nicht mit einem weiteren.
Jetzt: Atlassian führt Warnungen in Atlassian Administration ein, wo private Apps, die noch auf Connect laufen, „mit dem Status LEGACY gekennzeichnet sind“.

Ihre privaten Apps finden

Beginnen Sie in Atlassian Administration auf der Seite Connected Apps. Alles, was als LEGACY markiert ist, läuft auf Connect. Atlassians Checkliste, um eine private App zu erkennen: Trifft das meiste davon zu, müssen Sie sie selbst umziehen:

installiert über einen direkten Link oder den Entwicklermodus, nicht aus dem Marketplace;
in der Suche des Marketplace nicht sichtbar;
Ihre Organisation pflegt den Quellcode;
keine Lizenzinformationen, und Ihre Organisation ist die einzige, die unter den Installationen aufgeführt ist;
keine Seitenleiste mit verwandten Links auf ihrer Seite unter Connected Apps (Marketplace-Apps haben eine).

Atlassian ergänzt eine Faustregel: Eine individuelle Cloud-App, die vor mehr als fünf Jahren gebaut wurde, ist wahrscheinlich eine Connect-App, und Connect-Apps werden außerhalb von Atlassian gehostet, „typischerweise bei einem Dienst wie Heroku, AWS, Azure oder Google Cloud Platform“. Der Link View app details der App zeigt, wer der Entwickler ist, soweit Atlassian das weiß.

Halten Sie für jede App fünf Dinge fest, bevor irgendjemand Code anfasst:

Was sie tut und wer sie nutzt, in einem Satz, den ein Verantwortlicher aus dem Fachbereich wiedererkennt.
Wo der Quellcode liegt. Ein Repository, das Sie kontrollieren, der Laptop eines Auftragnehmers oder nirgends.
Wo sie läuft und wessen Konto das Hosting bezahlt. Wenn der Server auf dem Cloud-Konto eines früheren Auftragnehmers liegt, ist das ein Risiko heute, nicht erst im Januar.
Der Deskriptor. Jede Connect-App stellt unter einer URL eine Datei atlassian-connect.json bereit. Sie listet jedes Modul, jeden Scope und jeden Webhook, den die App nutzt, und ist damit das verlässlichste Inventar, das Sie bekommen.
Welche Daten sie hält und wo: in ihrer eigenen Datenbank oder in Properties, die an Jira-Vorgängen und Confluence-Seiten gespeichert sind.

Entscheiden, bevor Sie bauen

Nicht jede private App verdient eine Migration. Atlassians eigener Rat lautet, zu prüfen, ob eine eingebaute Funktion von Jira oder Confluence die Aufgabe inzwischen erledigt, und nur das zu migrieren, was die Organisation noch braucht. Alte Apps haben oft eine Lücke gefüllt, die das Produkt seither geschlossen hat.

Jede App bekommt eine von drei Antworten: migrieren, durch etwas Unterstütztes ersetzen oder stilllegen. Stilllegen ist ein legitimes Ergebnis. Atlassian empfiehlt, die Nutzer zu informieren, wenn Sie eine App aufgeben, und die Entfernung vor dem 31. Januar 2027 einzuplanen, statt sie von allein ausfallen zu lassen.

Was der Umzug auf Forge umfasst

Forge ist nicht Connect unter neuem Namen. Hosting-Modell, Sicherheitsmodell und UI-Modell unterscheiden sich, weshalb Atlassian selbst den Eigentümern einfacher Apps rät, früh mit einem Proof of Concept zu beginnen.

Hosting

Eine Connect-App ist ein Webdienst, den Sie betreiben. Eine Forge-App läuft auf der Infrastruktur von Atlassian als Funktionen mit harten Grenzen: 25 Sekunden für eine Funktion, die ein Benutzer auslöst, bis zu 900 Sekunden für asynchrone Ereignisse und geplante Trigger. Eine Connect-App, die eine zehnminütige Synchronisierung ausführt, während der Benutzer wartet, muss diese Arbeit in asynchrone Ereignisse verlagern, und alles, was länger als fünfzehn Minuten dauert, muss in Schritte aufgeteilt werden. Auch ausgehende Aufrufe sind eingeschränkt: Jede Domain, die nicht im Manifest der App deklariert ist, wird abgewiesen.

Das vorhandene Backend behalten

Forge Remote erlaubt einer Forge-App, Dienste aufzurufen, die Sie anderswo hosten, lässt Ihren Server prüfen, dass eine Anfrage wirklich von Forge kommt, und gibt Ihrem Backend Tokens, um Atlassian-APIs aufzurufen. Für eine private App mit jahrelang gewachsener Geschäftslogik auf ihrem Server ist das oft der kürzere Weg: Die Oberfläche und die Integrationspunkte ziehen auf Forge, die Logik bleibt, wo sie ist.

Der Preis: Mit Forge Remote kann eine App ihre Eignung für Atlassians Programm Runs on Atlassian verlieren. Für ein internes Werkzeug zählt das weniger, Ihr Sicherheitsteam sollte es aber bewusst akzeptieren.

Authentifizierung und Berechtigungen

Connect-Apps authentifizieren sich mit JWT, signiert mit einem gemeinsamen Geheimnis. Forge ersetzt das durch OAuth-2.0-Scopes, die im Manifest deklariert werden, und bei entfernten Backends durch ein Forge Invocation Token, das Ihr Server statt eines JWT prüft.

Jeder authentifizierte Aufruf der Jira- oder Confluence-API erfolgt dann entweder asUser, mit den Berechtigungen der Person, die die App nutzt, oder asApp, was laut Atlassian „unabhängig davon funktioniert, wer die App nutzt“. Jeden Aufruf durchzugehen und bewusst zu wählen, ist die wichtigste Sicherheitsprüfung der ganzen Migration.

Ein Unterschied erwischt viele Teams. Connect-Module werden standardmäßig für nicht lizenzierte und anonyme Benutzer angezeigt; Forge-Module nicht, es sei denn, das Manifest aktiviert das mit unlicensedAccess. Wenn Ihre App Kunden des Service Desk oder anonymen Lesern in Confluence irgendetwas anzeigt, testen Sie diesen Pfad eigens.

Die Benutzeroberfläche

Connect-Seiten sind iframes, die über Atlassians JavaScript-API mit Jira oder Confluence sprechen. Forge bietet zwei Möglichkeiten:

UI Kit: ein auf React basierendes Framework, das native Atlassian-Komponenten rendert. Schnell und einheitlich, aber Sie bauen aus den Komponenten von Atlassian: Eigenes HTML funktioniert möglicherweise nicht, und als statische Ressourcen akzeptiert es nur Bilder.
Custom UI: Ihr eigenes HTML, CSS und JavaScript in einem iframe, das über @forge/bridge mit dem Produkt spricht.

Ein bestehendes iframe-Frontend zieht meist mit den wenigsten Änderungen zu Custom UI um. Kleine Panels und Einstellungsseiten sind in UI Kit oft schneller neu gemacht.

Daten

Hier gehen Migrationen schief. Forge hat einen eigenen gehosteten Speicher: einen Key-Value-Speicher, einen Speicher für eigene Entitäten, Forge SQL und einen Objektspeicher in der Vorschau. Die Daten sind je Installation getrennt und liegen am selben Ort wie die Jira- oder Confluence-Site, auf der die App läuft, die Datenresidenz ergibt sich also ohne zusätzliche Konfiguration.

Was das für eine private App bedeutet:

Daten in der eigenen Datenbank der Connect-App werden entweder per einmaligem Migrationsjob in den Forge-Speicher übertragen oder bleiben, wo sie sind, und werden über Forge Remote erreicht.
Alles, was die Connect-App auf der Seite von Atlassian unter ihrem eigenen App-Schlüssel gespeichert hat, sollten Sie exportieren, solange die alte App noch läuft. Testen Sie früh, ob die neue App es lesen kann; setzen Sie es nicht voraus.
Forge bewahrt gehostete Daten nach einer Deinstallation 28 Tage auf, eine Neuinstallation stellt sie aber nicht automatisch wieder her.

Schreiben Sie die Migration als wiederholbares Skript mit prüfbaren Zählungen, proben Sie sie auf einer Test-Site und behalten Sie den Export.

Der schrittweise Weg und warum er vermutlich nicht Ihrer ist

Atlassian hat für Connect-Apps einen sanfteren Weg gebaut: Forge schrittweise übernehmen, bestehende Installationen behalten, den Deskriptor in ein Forge-Manifest umwandeln und eine Modulfamilie nach der anderen umziehen, mit eingebauter Datenmigration für einige Module wie Makros, benutzerdefinierte Felder und Workflow-Validatoren.

Der Haken steht im ersten Absatz der Anleitung: „Die schrittweise Übernahme von Forge ist nur für Confluence- und Jira-Connect-Apps verfügbar, die bereits im Marketplace gelistet sind.“

Für eine private App planen Sie mit einer neuen Forge-App. Sie stellen sie in der Produktionsumgebung bereit, geben sie über einen Installationslink aus der Developer Console für Ihre Site frei, lassen sie neben der alten Connect-App laufen, während die Daten migriert werden und die Benutzer testen, und entfernen dann die Connect-App.

Die Anleitungen zur Übernahme sind trotzdem nützlich, wegen ihrer Zuordnung der Module, ebenso die Liste der Connect-Fähigkeiten, die in Forge nicht verfügbar sind: Mehrere Module für Jira Service Management und die Unterstützung der mobilen App sind als nicht geplant markiert, und jiraReports wird noch geprüft. Gleichen Sie Ihren Deskriptor in der ersten Woche mit dieser Liste ab. Eine Lücke dort verändert den Entwurf.

Ein Plan rückwärts vom 31. Januar 2027

Ab Anfang Oktober 2026 bleiben rund siebzehn Wochen, und der Dezember ist für alle kurz. Ein Plan, der hält:

Diese Woche: Listen Sie jede LEGACY-App mit den fünf Angaben oben auf. Klären Sie, wer den Quellcode und das Hosting-Konto kontrolliert.
Bis Mitte Oktober: Entscheiden Sie für jede App: migrieren, ersetzen oder stilllegen. Informieren Sie die Benutzer von allem, was stillgelegt wird.
Bis Ende Oktober: ein Proof of Concept auf Forge für den schwierigsten Teil der schwierigsten App. Meist ist das ein Modul ohne direkte Entsprechung in Forge oder das Modul mit den meisten Daten.
November: bauen und die Datenmigration mehr als einmal gegen eine Test-Site laufen lassen.
Anfang Dezember: die Forge-App neben der Connect-App installieren, eine Kopie der Daten migrieren und die Leute, die sie täglich nutzen, prüfen lassen.
Januar 2027: endgültige Migration, Benutzer umstellen und die Connect-App erst entfernen, wenn die neue eine Weile sauber gelaufen ist.

Ein einzelnes Panel, das Jira-Daten liest und nichts speichert, ist eine kleine Aufgabe. Eine App mit eigener Datenbank, Workflow-Regeln und Verbindungen zu anderen Systemen braucht jede dieser Wochen.

Wenn Sie den Termin verpassen, sagt nichts von dem, was Atlassian veröffentlicht hat, dass die App an diesem Tag aufhört. Aber Sie betreiben dann einen Geschäftsprozess auf einer Plattform, die ihr Eigentümer nicht mehr repariert. Behandeln Sie diese Zeit als geliehen und schließen Sie den Umzug ab.

Wenn der ursprüngliche Entwickler weg ist

Atlassian geht direkt auf diesen Fall ein. Wenn Sie den ursprünglichen Eigentümer der App nicht ermitteln oder erreichen können oder keine Entwicklungskapazität mehr haben, schlägt Atlassian vor, einen Solution Partner hinzuzuziehen. Ebenso klar ist, dass es ohne den Quellcode „notwendig sein kann, die App von Grund auf neu auf Forge zu bauen“.

Auch ohne Quellcode fangen Sie nicht blind an. Der Deskriptor listet alles, woran die App andockt, ihr Verhalten lässt sich auf einer Test-Site beobachten, und wenn Ihr Unternehmen den Server bezahlt, können Sie sehen, was tatsächlich bereitgestellt ist. Ein Neubau aus diesen Teilen ist langsamer als eine Portierung, aber eine bekannte Größe.

Wo Sie Hilfe bekommen

Wir übernehmen Code, den niemand im aktuellen Team geschrieben hat, finden heraus, was er wirklich tut, und ziehen ihn um: Bei einer Connect-App heißt das, den Deskriptor und den Server zu lesen, die Forge-App zu bauen und die Datenmigration zu schreiben und zu proben. Meist beginnt das bei unserer Wartung von Bestandssystemen, und wenn Sie Entwickler haben, aber nicht genug, ergänzt unsere Personalverstärkung Ihr Team für die Dauer des Projekts. Sagen Sie uns, was die App tut und wo sie läuft: Schreiben Sie an office@c9group.dev.