Koniec wsparcia Atlassian Connect 31 stycznia 2027: przenoszenie własnych aplikacji Jira i Confluence na Forge

31 stycznia 2027 Atlassian kończy wsparcie dla Connect, frameworka, na którym zbudowano większość starszych aplikacji do Jira i Confluence Cloud. Od tego dnia, jak mówi Atlassian, firma „będzie usuwać w Connect wyłącznie krytyczne podatności bezpieczeństwa”, a prywatna aplikacja wciąż działająca na Connect „nie będzie już wspierana i może przestać działać prawidłowo”.

Jeśli każda aplikacja w Twojej witrynie pochodzi z Atlassian Marketplace, to zadanie producentów, a większość z nich już je wykonała: Atlassian poinformował w sierpniu 2026, że „ponad 95% płatnych stanowisk aplikacji zmigrowano na Forge”.

Ten artykuł dotyczy drugiego przypadku. Twoja firma ma aplikację do Jira albo Confluence, którą ktoś dla niej zbudował: wewnętrzny programista, wykonawca, partner. Zainstalowano ją z linku, a nie kupiono. Nikt spoza firmy jej nie przeniesie, a osoby, która ją napisała, może już nie być w pobliżu.

Co oznacza koniec wsparcia, a czego nie oznacza

Nie ma opublikowanej daty wyłączenia. Atlassian nie powiedział, że aplikacje Connect przestaną działać 1 lutego 2027, a jego pierwotne ogłoszenie harmonogramu mówiło, że „klienci, którzy mają zainstalowane aplikacje Connect, nie stracą dostępu do aplikacji”.

Nie czytaj tego jako gwarancji bezpieczeństwa. Zmienia się to, że nikt w Atlassian nie opiekuje się już Connect:

• Naprawiane są tylko krytyczne podatności bezpieczeństwa. Błędy niekrytyczne zostają.
• „Wycofywanie funkcji Connect będzie następować z niewielkim wyprzedzeniem.”
• Wsparcie Atlassian „nie będzie w stanie naprawiać problemów spowodowanych tą przestarzałą technologią”.
• Słowami samego Atlassian: „Po zakończeniu wsparcia Connect nie pozostanie w stanie stabilnym. Awarii będzie przybywać, a luki w zgodności będą się powiększać.”

Ryzyko narasta więc stopniowo, a nie jak urwisko. Prawdopodobny scenariusz awarii: Jira zmienia stronę, panel Connect przestaje się wyświetlać i nie ma komu zgłosić problemu. Jeśli ta aplikacja jest częścią akceptacji w dziale finansów albo obsługi klienta w service desku, dowiesz się o tym od ludzi, którzy od niej zależą.

Co już się wydarzyło

Data styczniowa to ostatni krok sekwencji, która zaczęła się w 2025.

• Wrzesień 2025: Marketplace przestał przyjmować nowe aplikacje Connect.
• 31 marca 2026: aktualizacje zostały zamrożone. Wytyczne Atlassian dla aplikacji własnych mówiły wprost, że po tej dacie „nie będzie już można wypychać aktualizacji aplikacji Connect”. Kod na Twoim własnym serwerze nadal możesz zmieniać, ale to, co aplikacja deklaruje wobec Jira albo Confluence (moduły, zakresy i webhooki), jest zamrożone.
• Marzec 2026: harmonogram mówił też, że „możliwość instalowania nowych prywatnych aplikacji Connect przez Connected Apps przestanie być dostępna”. Traktuj odinstalowanie jako nieodwracalne: nie usuwaj prywatnej aplikacji Connect tylko po to, żeby zobaczyć, co przestanie działać.
• Sierpień 2026: Atlassian przesunął koniec wsparcia z grudnia 2026 na 31 stycznia 2027. To jeden dodatkowy miesiąc. Nie planuj kolejnego.
• Teraz: Atlassian wprowadza ostrzeżenia w Atlassian Administration, gdzie prywatne aplikacje wciąż działające na Connect są „oznaczone statusem LEGACY”.

Jak znaleźć prywatne aplikacje

Zacznij w Atlassian Administration, na stronie Connected Apps. Wszystko, co ma etykietę LEGACY, działa na Connect. Lista kontrolna Atlassian do rozpoznawania prywatnej aplikacji: jeśli większość z poniższych się zgadza, jej przeniesienie należy do Ciebie:

• zainstalowana z bezpośredniego linku albo w trybie deweloperskim, a nie z Marketplace;
• niewidoczna w wyszukiwarce Marketplace;
• Twoja organizacja utrzymuje kod źródłowy;
• brak informacji licencyjnych, a Twoja organizacja jest jedyną wymienioną w instalacjach;
• brak paska bocznego z powiązanymi linkami na jej stronie w Connected Apps (aplikacje z Marketplace go mają).

Atlassian dodaje praktyczną regułę: własna aplikacja chmurowa zbudowana ponad pięć lat temu to prawdopodobnie aplikacja Connect, a aplikacje Connect są hostowane poza Atlassian, „zwykle w usłudze takiej jak Heroku, AWS, Azure albo Google Cloud Platform”. Link View app details (szczegóły aplikacji) pokazuje, kto jest jej twórcą, o ile Atlassian to wie.

Dla każdej aplikacji zapisz pięć rzeczy, zanim ktokolwiek dotknie kodu:

1. Co robi i kto jej używa, w jednym zdaniu, które rozpozna właściciel biznesowy.
2. Gdzie jest kod źródłowy. W repozytorium, które kontrolujesz, na laptopie wykonawcy albo nigdzie.
3. Gdzie działa i z czyjego konta płaci się za hosting. Jeśli serwer stoi na koncie chmurowym byłego wykonawcy, to ryzyko już dziś, a nie w styczniu.
4. Deskryptor. Każda aplikacja Connect udostępnia plik atlassian-connect.json pod adresem URL. Wymienia on każdy moduł, zakres i webhook, z którego aplikacja korzysta, co czyni go najbardziej wiarygodnym inwentarzem, jaki dostaniesz.
5. Jakie dane przechowuje i gdzie: we własnej bazie danych czy we właściwościach zapisanych w zgłoszeniach Jira i na stronach Confluence.

Zdecyduj, zanim zaczniesz budować

Nie każda prywatna aplikacja zasługuje na migrację. Atlassian sam radzi sprawdzić, czy natywna funkcja Jira albo Confluence nie wykonuje już tego zadania, i migrować tylko to, czego organizacja nadal potrzebuje. Stare aplikacje często wypełniały lukę, którą produkt od tego czasu zamknął.

Każda aplikacja dostaje jedną z trzech odpowiedzi: migracja, zastąpienie czymś wspieranym albo wycofanie. Wycofanie to uprawniony wynik. Atlassian zaleca, by przy rezygnacji z aplikacji poinformować jej użytkowników i zaplanować usunięcie przed 31 stycznia 2027, zamiast czekać, aż sama przestanie działać.

Co obejmuje przejście na Forge

Forge to nie Connect pod nową nazwą. Model hostingu, model bezpieczeństwa i model interfejsu użytkownika są inne, dlatego Atlassian radzi nawet właścicielom prostych aplikacji, by wcześnie zaczęli od weryfikacji koncepcji (proof of concept).

Hosting

Aplikacja Connect to usługa internetowa, którą prowadzisz. Aplikacja Forge działa na infrastrukturze Atlassian jako funkcje z twardymi limitami: 25 sekund dla funkcji wywołanej przez użytkownika, do 900 sekund dla zdarzeń asynchronicznych i wyzwalaczy harmonogramowanych. Aplikacja Connect, która uruchamia dziesięciominutową synchronizację, podczas gdy użytkownik czeka, musi przenieść tę pracę do zdarzeń asynchronicznych, a wszystko, co trwa dłużej niż piętnaście minut, trzeba podzielić na kroki. Ograniczone są też wywołania wychodzące: każda domena niezadeklarowana w manifeście aplikacji jest odrzucana.

Zachowanie dotychczasowego backendu

Forge Remote pozwala aplikacji Forge wywoływać usługi hostowane gdzie indziej, pozwala Twojemu serwerowi sprawdzić, czy żądanie naprawdę przyszło z Forge, i daje backendowi tokeny do wywoływania API Atlassian. Dla prywatnej aplikacji z latami logiki biznesowej na serwerze to często krótsza droga: interfejs i punkty integracji przechodzą na Forge, logika zostaje na miejscu.

Kompromis: Forge Remote może sprawić, że aplikacja nie zakwalifikuje się do programu Runs on Atlassian. Dla narzędzia wewnętrznego ma to mniejsze znaczenie, ale Twój zespół bezpieczeństwa powinien zaakceptować to świadomie.

Uwierzytelnianie i uprawnienia

Aplikacje Connect uwierzytelniają się tokenem JWT podpisanym wspólnym sekretem. Forge zastępuje to zakresami OAuth 2.0 zadeklarowanymi w manifeście, a dla zdalnych backendów tokenem Forge Invocation Token, który serwer waliduje zamiast JWT.

Każde uwierzytelnione wywołanie API Jira albo Confluence odbywa się wtedy albo jako asUser, z uprawnieniami osoby korzystającej z aplikacji, albo jako asApp, co słowami Atlassian działa „niezależnie od tego, kto korzysta z aplikacji”. Przejście przez każde wywołanie i świadomy wybór to najważniejszy przegląd bezpieczeństwa w całej migracji.

Jedna różnica zaskakuje zespoły. Moduły Connect domyślnie renderują się dla użytkowników bez licencji i anonimowych; moduły Forge nie, chyba że manifest to włączy przez unlicensedAccess. Jeśli Twoja aplikacja pokazuje cokolwiek klientom service desku albo anonimowym czytelnikom Confluence, przetestuj tę ścieżkę osobno.

Interfejs użytkownika

Strony Connect to ramki iframe, które komunikują się z Jira albo Confluence przez JavaScript API Atlassian. Forge daje dwie możliwości:

• UI Kit: framework oparty na React, który renderuje natywne komponenty Atlassian. Szybki i spójny, ale budujesz z komponentów Atlassian: własny HTML może nie działać, a jedynymi akceptowanymi zasobami statycznymi są obrazy.
• Custom UI: własny HTML, CSS i JavaScript w ramce iframe, komunikujący się z produktem przez @forge/bridge.

Istniejący frontend w iframe zwykle przechodzi na Custom UI z najmniejszą liczbą zmian. Małe panele i ekrany ustawień często szybciej przerobić w UI Kit.

Dane

Tu migracje się wykolejają. Forge ma własne hostowane magazyny danych: magazyn klucz-wartość, magazyn własnych encji, Forge SQL i magazyn obiektów w wersji preview. Dane są przypisane do konkretnej instalacji i przechowywane w tej samej lokalizacji co macierzysta witryna Jira albo Confluence, więc rezydencja danych działa bez dodatkowej konfiguracji.

Co to oznacza dla prywatnej aplikacji:

• Dane we własnej bazie aplikacji Connect albo przenosi się do magazynu Forge jednorazowym zadaniem migracyjnym, albo zostawia na miejscu i sięga po nie przez Forge Remote.
• Wszystko, co aplikacja Connect zapisała po stronie Atlassian pod własnym kluczem aplikacji, należy wyeksportować, póki stara aplikacja jeszcze działa. Wcześnie przetestuj, czy nowa aplikacja potrafi to odczytać; nie zakładaj tego.
• Forge przechowuje hostowane dane przez 28 dni po odinstalowaniu, ale ponowna instalacja nie przywraca ich automatycznie.

Napisz migrację jako powtarzalny skrypt z liczbami, które da się sprawdzić, przećwicz ją na witrynie testowej i zachowaj eksport.

Ścieżka przyrostowa i dlaczego prawdopodobnie nie jest Twoja

Atlassian zbudował łagodniejszą drogę dla aplikacji Connect: przyrostowe przejście na Forge, z zachowaniem istniejących instalacji, konwersją deskryptora na manifest Forge i przenoszeniem jednej rodziny modułów naraz, z wbudowaną migracją danych dla niektórych modułów, takich jak makra, pola niestandardowe i walidatory przepływów pracy.

Haczyk jest w pierwszym akapicie przewodnika: „Przyrostowe przejście na Forge jest dostępne wyłącznie dla aplikacji Connect do Confluence i Jira, które są już wystawione w Marketplace.”

Dla prywatnej aplikacji zaplanuj nową aplikację Forge. Wdrażasz ją do środowiska produkcyjnego, udostępniasz swojej witrynie przez link instalacyjny z konsoli deweloperskiej, uruchamiasz obok starej aplikacji Connect, gdy dane są migrowane, a użytkownicy testują, a potem usuwasz aplikację Connect.

Przewodniki po przejściu nadal przydają się ze względu na mapowanie modułów, podobnie jak lista funkcji Connect niedostępnych w Forge: kilka modułów Jira Service Management i obsługa aplikacji mobilnej są oznaczone jako nieplanowane, a jiraReports jest wciąż rozważany. Porównaj swój deskryptor z tą listą w pierwszym tygodniu. Luka na niej zmienia projekt.

Plan liczony wstecz od 31 stycznia 2027

Od początku października 2026 zostaje około siedemnastu tygodni, a grudzień jest krótki dla wszystkich. Plan, który się utrzyma:

1. W tym tygodniu: spisz każdą aplikację LEGACY z pięcioma opisanymi wyżej informacjami. Potwierdź, kto kontroluje kod źródłowy i konto hostingowe.
2. Do połowy października: dla każdej aplikacji zdecyduj: migracja, zastąpienie albo wycofanie. Poinformuj użytkowników wszystkiego, co zostanie wycofane.
3. Do końca października: weryfikacja koncepcji na Forge dla najtrudniejszej części najtrudniejszej aplikacji. Zwykle jest to moduł bez bezpośredniego odpowiednika w Forge albo ten, który przechowuje najwięcej danych.
4. Listopad: budowa i więcej niż jedno przeprowadzenie migracji danych na witrynie testowej.
5. Początek grudnia: zainstaluj aplikację Forge obok aplikacji Connect, zmigruj kopię danych i pozwól sprawdzić ją ludziom, którzy korzystają z niej na co dzień.
6. Styczeń 2027: ostateczna migracja, przeniesienie użytkowników i usunięcie aplikacji Connect dopiero wtedy, gdy nowa przez jakiś czas działała bez zarzutu.

Pojedynczy panel, który czyta dane z Jira i niczego nie przechowuje, to mała praca. Aplikacja z własną bazą danych, regułami przepływu pracy i połączeniami z innymi systemami potrzebuje każdego z tych tygodni.

Jeśli nie zdążysz, nic z tego, co opublikował Atlassian, nie mówi, że aplikacja przestanie działać tego dnia. Ale od tej chwili prowadzisz proces biznesowy na platformie, której właściciel przestał ją naprawiać. Traktuj ten czas jako pożyczony i dokończ przeprowadzkę.

Gdy pierwotnego autora już nie ma

Atlassian odnosi się do tego przypadku bezpośrednio. Jeśli nie możesz ustalić ani skontaktować się z pierwotnym właścicielem aplikacji albo nie masz już zasobów programistycznych, sugeruje zaangażowanie partnera rozwiązań (Solution Partner). Równie jasno mówi, że bez kodu źródłowego „może być konieczne zbudowanie aplikacji na Forge od zera”.

Nawet bez kodu źródłowego nie zaczynasz po omacku. Deskryptor wymienia wszystko, do czego aplikacja się podłącza, jej zachowanie można obserwować na witrynie testowej, a jeśli Twoja firma płaci za serwer, możesz zobaczyć, co faktycznie jest na nim wdrożone. Odbudowa z tych elementów jest wolniejsza niż przeniesienie, ale jest wielkością znaną.

Gdzie szukać pomocy

Przejmujemy kod, którego nikt z obecnego zespołu nie pisał, ustalamy, co naprawdę robi, i go przenosimy: w przypadku aplikacji Connect oznacza to przeczytanie deskryptora i serwera, zbudowanie aplikacji Forge oraz napisanie i przećwiczenie migracji danych. Zwykle zaczyna się to od naszej usługi utrzymania systemów odziedziczonych, a jeśli masz programistów, ale za mało, staff augmentation dodaje ludzi do Twojego zespołu na czas projektu. Napisz nam, co robi aplikacja i gdzie działa: office@c9group.dev.