Atlassian Connect slutar stödjas den 31 januari 2027: så flyttar du egenutvecklade Jira- och Confluence-appar till Forge

Den 31 januari 2027 upphör Atlassians stöd för Connect, det ramverk som de flesta äldre appar för Jira Cloud och Confluence Cloud byggdes på. Från den dagen kommer Atlassian enligt egen uppgift ”bara att åtgärda kritiska säkerhetssårbarheter i Connect”, och en privat app som fortfarande körs på Connect ”kommer inte längre att stödjas och kan sluta fungera som den ska”.

Kommer varje app på din webbplats från Atlassian Marketplace är det här leverantörernas jobb, och de flesta har redan gjort det: Atlassian rapporterade i augusti 2026 att ”över 95 % av de betalda appanvändarplatserna har migrerats till Forge”.

Den här artikeln handlar om det andra fallet. Ditt företag har en app för Jira eller Confluence som någon har byggt åt er: en intern utvecklare, en konsult, en partner. Den installerades via en länk, den köptes inte. Ingen utanför företaget kommer att flytta den, och den som skrev den kanske inte finns kvar.

Vad slutet på stödet betyder, och vad det inte betyder

Det finns inget publicerat datum då Connect stängs av. Atlassian har inte sagt att Connect-appar slutar fungera den 1 februari 2027, och det ursprungliga tillkännagivandet av tidslinjen sa att ”kunder som har Connect-appar installerade inte förlorar åtkomsten till appen”.

Läs inte det som en garanti. Det som ändras är att ingen på Atlassian längre tar hand om Connect:

• Bara kritiska säkerhetssårbarheter åtgärdas. Icke-kritiska buggar blir kvar.
• ”Funktioner i Connect kommer att fasas ut med kort varsel.”
• Atlassians support ”kommer inte att kunna åtgärda problem som orsakas av den äldre tekniken”.
• Med Atlassians egna ord: ”Connect kommer inte att förbli i ett stabilt läge efter att stödet upphört. Fel kommer att öka och kompatibilitetsluckorna kommer att växa.”

Risken kommer alltså gradvis, inte som ett stup. Ett troligt haveri: Jira ändrar en sida, en Connect-panel slutar visas, och det finns ingen att skicka ett ärende till. Ligger appen mitt i ett attestflöde inom ekonomi eller i en servicedesk mot kunder, får du höra det från dem som är beroende av den.

Vad som redan har hänt

Datumet i januari är sista steget i en följd som började 2025.

• September 2025: Marketplace slutade ta emot nya Connect-appar.
• 31 mars 2026: uppdateringar frystes. Atlassians vägledning för egenutvecklade appar sa det rakt ut: efter det datumet ”kommer du inte längre att kunna skicka ut uppdateringar till Connect-appar”. Koden på din egen server kan du fortfarande ändra, men det appen deklarerar mot Jira eller Confluence (moduler, scopes och webhooks) är låst.
• Mars 2026: tidslinjen sa också att ”möjligheten att installera nya privata Connect-appar via Connected Apps kommer att försvinna”. Se en avinstallation som enkelriktad: ta inte bort en privat Connect-app bara för att se vad som går sönder.
• Augusti 2026: Atlassian flyttade slutet på stödet från december 2026 till 31 januari 2027. Det är en extra månad. Räkna inte med ytterligare en.
• Nu: Atlassian rullar ut varningar i Atlassian Administration, där privata appar som fortfarande körs på Connect ”markeras med statusen LEGACY”.

Hitta dina privata appar

Börja i Atlassian Administration, på sidan Connected Apps. Allt som är märkt LEGACY körs på Connect. Atlassians checklista för att känna igen en privat app: stämmer de flesta punkterna är det din app att flytta:

• installerad via en direktlänk eller i utvecklarläge, inte från Marketplace;
• syns inte vid sökning i Marketplace;
• er organisation underhåller källkoden;
• ingen licensinformation, och er organisation är den enda som står under installationer;
• inget sidofält med relaterade länkar på appens sida i Connected Apps (Marketplace-appar har ett).

Atlassian lägger till en tumregel: en egenutvecklad molnapp som byggdes för mer än fem år sedan är troligen en Connect-app, och Connect-appar ligger utanför Atlassian, ”vanligen hos en tjänst som Heroku, AWS, Azure eller Google Cloud Platform”. Appens länk View app details visar vem utvecklaren är, så långt Atlassian vet.

Skriv ner fem saker för varje app innan någon rör koden:

1. Vad den gör och vem som använder den, i en mening som en verksamhetsansvarig känner igen.
2. Var källkoden finns. Ett repo som ni styr över, en konsults bärbara dator eller ingenstans.
3. Var den körs, och vems konto som betalar för driften. Ligger servern på en tidigare konsults molnkonto är det en risk redan i dag, inte i januari.
4. Deskriptorn. Varje Connect-app tillhandahåller en fil, atlassian-connect.json, på en URL. Den listar varje modul, scope och webhook som appen använder, vilket gör den till den mest tillförlitliga inventering du kan få.
5. Vilka data den sparar, och var: i en egen databas eller i egenskaper som lagras på Jira-ärenden och Confluence-sidor.

Bestäm innan du bygger

Alla privata appar förtjänar inte en migrering. Atlassians eget råd är att kontrollera om en inbyggd funktion i Jira eller Confluence numera gör jobbet, och att bara migrera det som organisationen fortfarande behöver. Gamla appar fyllde ofta en lucka som produkten sedan har täppt till.

Varje app får ett av tre svar: migrera, ersätt med något som stöds, eller avveckla. Att avveckla är ett fullt legitimt utfall. Atlassian rekommenderar att du, om du lägger ner en app, informerar användarna och planerar in borttagningen före den 31 januari 2027, i stället för att låta den sluta fungera av sig själv.

Vad flytten till Forge innebär

Forge är inte Connect under ett nytt namn. Driftmodellen, säkerhetsmodellen och gränssnittsmodellen skiljer sig alla åt, och därför uppmanar Atlassian även ägare av enkla appar att börja med en proof of concept tidigt.

Drift

En Connect-app är en webbtjänst som du kör. En Forge-app körs på Atlassians infrastruktur som funktioner med hårda gränser: 25 sekunder för en funktion som en användare startar, upp till 900 sekunder för asynkrona händelser och schemalagda triggers. En Connect-app som kör en tio minuter lång synkronisering medan användaren väntar måste flytta det arbetet till asynkrona händelser, och allt som tar längre än femton minuter måste delas upp i steg. Utgående anrop är också begränsade: varje domän som inte är deklarerad i appens manifest avvisas.

Behålla den backend du har

Med Forge Remote kan en Forge-app anropa tjänster som du driftar någon annanstans, din server kan kontrollera att en förfrågan verkligen kommer från Forge, och din backend får token för att anropa Atlassians API:er. För en privat app med år av affärslogik på servern är det ofta den kortare vägen: gränssnittet och integrationspunkterna flyttar till Forge, logiken stannar där den är.

Avvägningen: Forge Remote kan göra att en app inte kvalificerar för Atlassians program Runs on Atlassian. För ett internt verktyg spelar det mindre roll, men ditt säkerhetsteam bör godta det med öppna ögon.

Autentisering och behörigheter

Connect-appar autentiserar med JWT som signeras med en delad hemlighet. Forge ersätter det med OAuth 2.0-scopes som deklareras i manifestet och, för fjärrbackends, en Forge Invocation Token som din server validerar i stället för en JWT.

Varje autentiserat anrop till Jiras eller Confluences API görs sedan antingen asUser, med behörigheterna hos den som använder appen, eller asApp, som med Atlassians ord fungerar ”oavsett vem som använder appen”. Att gå igenom varje anrop och välja medvetet är den viktigaste säkerhetsgranskningen i hela migreringen.

En skillnad brukar överraska team. Connect-moduler visas som standard för olicensierade och anonyma användare; Forge-moduler gör det inte, om inte manifestet uttryckligen slår på det med unlicensedAccess. Visar din app något för servicedeskkunder eller anonyma Confluence-läsare, testa den vägen separat.

Användargränssnittet

Connect-sidor är iframes som pratar med Jira eller Confluence via Atlassians JavaScript-API. Forge ger dig två alternativ:

• UI Kit: ett React-baserat ramverk som renderar Atlassians egna komponenter. Snabbt och enhetligt, men du bygger av Atlassians komponenter: egen HTML fungerar inte alltid, och de enda statiska resurser som accepteras är bilder.
• Custom UI: din egen HTML, CSS och JavaScript i en iframe, som pratar med produkten via @forge/bridge.

En befintlig frontend i en iframe flyttar oftast till Custom UI med minst ändringar. Små paneler och inställningsskärmar går ofta snabbare att göra om i UI Kit.

Data

Det är här migreringar går snett. Forge har sin egen driftade lagring: ett nyckel-värde-lager, ett lager för egna entiteter, Forge SQL och ett objektlager i förhandsversion. Data avgränsas per installation och lagras på samma plats som den Jira- eller Confluence-webbplats som appen ligger i, så datalokalisering följer med utan extra konfiguration.

Vad det betyder för en privat app:

• Data i Connect-appens egen databas flyttas antingen till Forge-lagringen med ett engångsjobb för migrering, eller lämnas där den är och nås via Forge Remote.
• Allt som Connect-appen har sparat på Atlassians sida under sin egen appnyckel bör exporteras medan den gamla appen fortfarande körs. Testa tidigt om den nya appen kan läsa det; ta det inte för givet.
• Forge behåller driftade data i 28 dagar efter en avinstallation, men en ominstallation återställer dem inte automatiskt.

Skriv migreringen som ett skript som går att köra om, med antal som går att kontrollera, repetera den på en testmiljö och spara exporten.

Den stegvisa vägen, och varför den troligen inte är din

Atlassian har byggt en mjukare väg för Connect-appar: att införa Forge stegvis, behålla befintliga installationer, konvertera deskriptorn till ett Forge-manifest och flytta en modulfamilj i taget, med inbyggd datamigrering för vissa moduler som makron, anpassade fält och validerare i arbetsflöden.

Haken finns i guidens första stycke: ”Det stegvisa införandet av Forge är bara tillgängligt för Connect-appar för Confluence och Jira som redan finns listade på Marketplace.”

För en privat app ska du planera för en ny Forge-app. Du driftsätter den i produktionsmiljön, delar den med din webbplats via en installationslänk från utvecklarkonsolen, kör den vid sidan av den gamla Connect-appen medan data migreras och användarna testar, och tar sedan bort Connect-appen.

Guiderna för införandet är ändå användbara för sin mappning av moduler, och det är även listan över Connect-funktioner som inte finns i Forge: flera moduler för Jira Service Management och stöd för mobilappen är markerade som inte planerade, och jiraReports är fortfarande under övervägande. Kontrollera din deskriptor mot den listan första veckan. En lucka där ändrar designen.

En plan räknad bakåt från 31 januari 2027

Från början av oktober 2026 återstår ungefär sjutton veckor, och december är kort för alla. En plan som håller:

1. Den här veckan: lista varje LEGACY-app med de fem uppgifterna ovan. Bekräfta vem som styr över källkoden och driftkontot.
2. Till mitten av oktober: bestäm för varje app om den ska migreras, ersättas eller avvecklas. Informera användarna av allt som avvecklas.
3. Till slutet av oktober: en proof of concept i Forge för den svåraste delen av den svåraste appen. Oftast är det en modul utan direkt motsvarighet i Forge, eller den som har mest data.
4. November: bygg, och kör datamigreringen mot en testmiljö mer än en gång.
5. Början av december: installera Forge-appen vid sidan av Connect-appen, migrera en kopia av datan och låt dem som använder appen varje dag kontrollera den.
6. Januari 2027: slutlig migrering, flytta över användarna och ta bort Connect-appen först när den nya har gått felfritt ett tag.

En enskild panel som läser data från Jira och inte sparar något är ett litet jobb. En app med egen databas, arbetsflödesregler och kopplingar till andra system behöver var och en av de här veckorna.

Missar du datumet säger ingenting som Atlassian har publicerat att appen slutar fungera den dagen. Men då kör du en affärsprocess på en plattform som ägaren har slutat laga. Se den tiden som lånad, och slutför flytten.

När den ursprungliga utvecklaren är borta

Atlassian tar upp det här fallet direkt. Kan du inte identifiera eller nå den ursprungliga ägaren av appen, eller saknar du längre utvecklingskapacitet, föreslår Atlassian att du anlitar en Solution Partner. Atlassian är lika tydligt med att det utan källkoden ”kan bli nödvändigt att bygga om appen i Forge från grunden”.

Även utan källkod börjar du inte i blindo. Deskriptorn listar allt som appen kopplar in sig i, beteendet kan observeras på en testmiljö, och betalar ditt företag för servern kan du se vad som faktiskt är driftsatt. En ombyggnad utifrån de bitarna går långsammare än en portering, men den är en känd storhet.

Var du får hjälp

Vi tar över kod som ingen i det nuvarande teamet har skrivit, tar reda på vad den verkligen gör och flyttar den: för en Connect-app innebär det att läsa deskriptorn och servern, bygga Forge-appen samt skriva och repetera datamigreringen. Vårt arbete med underhåll av äldre system är oftast där det börjar, och har du utvecklare men inte tillräckligt många, ger konsultförstärkning ditt team fler personer under den tid det behövs. Berätta vad appen gör och var den körs: skriv till office@c9group.dev.