Atlassian Connect mister støtten 31. januar 2027: slik flytter du egne Jira- og Confluence-apper til Forge

Én rød puslespillbrikke blant grønne

Den 31. januar 2027 avslutter Atlassian støtten for Connect, rammeverket de fleste eldre Jira- og Confluence Cloud-apper ble bygget på. Fra den dagen vil Atlassian, ifølge egne opplysninger, «bare håndtere kritiske sikkerhetssårbarheter i Connect», og en privat app som fortsatt kjører på Connect, «vil ikke lenger ha støtte og kan slutte å fungere som den skal».

Kom alle appene på nettstedet ditt fra Atlassian Marketplace, er dette leverandørenes jobb, og de fleste av dem har gjort den: Atlassian rapporterte i august 2026 at «over 95 % av betalte appseter er migrert til Forge».

Denne artikkelen er for det andre tilfellet. Selskapet ditt har en Jira- eller Confluence-app som noen har bygget for dere: en intern utvikler, en innleid konsulent, en partner. Den ble installert via en lenke, ikke kjøpt. Ingen utenfor selskapet kommer til å flytte den, og den som skrev den, er kanskje ikke der lenger.

Hva slutt på støtte betyr, og hva det ikke betyr

Det finnes ingen publisert dato for avstengning. Atlassian har ikke sagt at Connect-apper slutter å kjøre 1. februar 2027, og den opprinnelige kunngjøringen av tidslinjen sa at «kunder som har Connect-apper installert, ikke vil miste tilgangen til appen».

Ikke les det som en garanti. Det som endres, er at ingen hos Atlassian tar vare på Connect lenger:

Bare kritiske sikkerhetssårbarheter blir rettet. Ikke-kritiske feil blir stående.
«Funksjoner i Connect vil bli avviklet på kort varsel.»
Atlassians support «vil ikke kunne rette problemer forårsaket av den eldre teknologien».
Med Atlassians egne ord: «Connect vil ikke forbli stabilt etter at støtten opphører. Feilene vil øke, og kompatibilitetsgapene vil bli større.»

Risikoen er altså gradvis, ikke et stup. Et sannsynlig feilscenario: Jira endrer en side, et Connect-panel slutter å vises, og det finnes ingen å melde saken til. Ligger den appen inne i en godkjenningsflyt i økonomi eller en kundeorientert service desk, får du høre om det fra dem som er avhengige av den.

Hva som allerede har skjedd

Datoen i januar er det siste trinnet i en rekke som startet i 2025.

September 2025: Marketplace sluttet å ta imot nye Connect-apper.
31. mars 2026: oppdateringene ble frosset. Atlassians veiledning for egenutviklede apper sa det rett ut: etter den datoen «vil du ikke lenger kunne sende oppdateringer til Connect-apper». Koden på din egen server kan du fortsatt endre, men det appen deklarerer overfor Jira eller Confluence (modulene, scopene og webhookene), ligger fast.
Mars 2026: tidslinjen sa også at «muligheten til å installere nye private Connect-apper via Connected Apps vil bli utilgjengelig». Behandle en avinstallering som enveis: ikke fjern en privat Connect-app bare for å se hva som slutter å virke.
August 2026: Atlassian flyttet slutten på støtten fra desember 2026 til 31. januar 2027. Det er én måned ekstra. Ikke regn med en til.
Nå: Atlassian ruller ut advarsler i Atlassian Administration, der private apper som fortsatt er på Connect, «merkes med statusen LEGACY».

Finn de private appene dine

Start i Atlassian Administration, på siden Connected Apps. Alt som er merket LEGACY, kjører på Connect. Atlassians sjekkliste for å kjenne igjen en privat app: er de fleste av disse punktene sanne, er det du som må flytte den:

installert via en direkte lenke eller utviklermodus, ikke fra Marketplace;
ikke synlig i søk på Marketplace;
organisasjonen din vedlikeholder kildekoden;
ingen lisensopplysninger, og organisasjonen din er den eneste som står oppført under installasjoner;
ingen sidekolonne med relaterte lenker på siden i Connected Apps (Marketplace-apper har en).

Atlassian legger til en tommelfingerregel: en egenutviklet skyapp som ble bygget for mer enn fem år siden, er sannsynligvis en Connect-app, og Connect-apper driftes utenfor Atlassian, «typisk på en tjeneste som Heroku, AWS, Azure eller Google Cloud Platform». Lenken View app details viser hvem utvikleren er, så langt Atlassian vet.

For hver app skriver du ned fem ting før noen rører koden:

Hva den gjør og hvem som bruker den, i en setning en forretningsansvarlig ville kjent igjen.
Hvor kildekoden er. Et kodelager dere kontrollerer, en konsulents bærbare PC, eller ingen steder.
Hvor den kjører, og hvem sin konto som betaler for driften. Står serveren på en tidligere konsulents skykonto, er det en risiko i dag, ikke i januar.
Deskriptoren. Hver Connect-app leverer en atlassian-connect.json-fil på en URL. Den lister opp hver modul, hvert scope og hver webhook appen bruker, og er dermed den mest pålitelige oversikten du får.
Hvilke data den lagrer, og hvor: i sin egen database, eller i egenskaper lagret på Jira-saker og Confluence-sider.

Bestem deg før du bygger

Ikke alle private apper fortjener en migrering. Atlassians eget råd er å sjekke om en innebygd funksjon i Jira eller Confluence nå gjør jobben, og bare migrere det organisasjonen fortsatt trenger. Gamle apper fylte ofte et hull som produktet siden har tettet.

Hver app får ett av tre svar: migrere, erstatte med noe som har støtte, eller avvikle. Avvikling er et legitimt utfall. Atlassian anbefaler at du, hvis du dropper en app, sier fra til brukerne og planlegger fjerningen før 31. januar 2027, i stedet for å la den feile av seg selv.

Hva flyttingen til Forge innebærer

Forge er ikke Connect med nytt navn. Driftsmodellen, sikkerhetsmodellen og UI-modellen er alle forskjellige, og derfor ber Atlassian selv eierne av enkle apper om å starte en konseptutprøving tidlig.

Drift

En Connect-app er en webtjeneste du drifter. En Forge-app kjører på Atlassians infrastruktur som funksjoner med harde grenser: 25 sekunder for en funksjon en bruker utløser, opptil 900 sekunder for asynkrone hendelser og planlagte utløsere. En Connect-app som kjører en synkronisering på ti minutter mens brukeren venter, må flytte det arbeidet over i asynkrone hendelser, og alt som tar mer enn femten minutter, må deles opp i trinn. Utgående kall er også begrenset: ethvert domene som ikke er deklarert i appens manifest, avvises.

Beholde backenden dere har

Forge Remote lar en Forge-app kalle tjenester du drifter et annet sted, lar serveren din kontrollere at en forespørsel virkelig kom fra Forge, og gir backenden din tokener for å kalle Atlassians API-er. For en privat app med mange år med forretningslogikk på serveren er dette ofte den korteste veien: brukergrensesnittet og integrasjonspunktene flyttes til Forge, logikken blir der den er.

Avveiningen: Forge Remote kan gjøre en app uaktuell for Atlassians program Runs on Atlassian. For et internt verktøy betyr det mindre, men sikkerhetsteamet deres bør godta det med åpne øyne.

Autentisering og tillatelser

Connect-apper autentiserer med JWT signert med en delt hemmelighet. Forge erstatter det med OAuth 2.0-scopes deklarert i manifestet og, for eksterne backender, et Forge Invocation Token som serveren din validerer i stedet for en JWT.

Hvert autentisert kall til API-et i Jira eller Confluence gjøres deretter enten asUser, med tillatelsene til personen som bruker appen, eller asApp, som med Atlassians ord fungerer «uansett hvem som bruker appen». Å gå gjennom hvert kall og velge bevisst er den viktigste sikkerhetsgjennomgangen i hele migreringen.

Én forskjell overrasker mange team. Connect-moduler vises som standard for brukere uten lisens og anonyme brukere; Forge-moduler gjør det ikke, med mindre manifestet slår det på med unlicensedAccess. Viser appen din noe til kunder i service desk eller anonyme lesere i Confluence, test den løypa for seg.

Brukergrensesnittet

Connect-sider er iframes som snakker med Jira eller Confluence gjennom Atlassians JavaScript-API. Forge gir deg to valg:

UI Kit: et React-basert rammeverk som viser innebygde Atlassian-komponenter. Raskt og konsistent, men du bygger med Atlassians komponenter: egen HTML virker kanskje ikke, og de eneste statiske ressursene det godtar, er bilder.
Custom UI: din egen HTML, CSS og JavaScript i en iframe, som snakker med produktet gjennom @forge/bridge.

Et eksisterende iframe-grensesnitt flyttes som regel til Custom UI med færrest endringer. Små paneler og innstillingssider er ofte raskere å lage på nytt i UI Kit.

Data

Det er her migreringer går galt. Forge har sin egen driftede lagring: et nøkkel-verdi-lager, et lager for egne entiteter, Forge SQL og et objektlager i forhåndsversjon. Dataene avgrenses per installasjon og lagres på samme sted som det tilhørende Jira- eller Confluence-nettstedet, så datalokalisering følger med uten ekstra konfigurasjon.

Hva det betyr for en privat app:

Data i Connect-appens egen database flyttes enten inn i Forge-lagringen med en engangsjobb for migrering, eller blir liggende der de er og nås gjennom Forge Remote.
Alt Connect-appen lagret på Atlassians side under sin egen appnøkkel, bør eksporteres mens den gamle appen fortsatt kjører. Test tidlig om den nye appen kan lese det; ikke gå ut fra det.
Forge beholder driftede data i 28 dager etter en avinstallering, men en ny installasjon gjenoppretter dem ikke automatisk.

Skriv migreringen som et gjentakbart skript med tall du kan kontrollere, øv på den på et testnettsted, og ta vare på eksporten.

Den gradvise veien, og hvorfor den trolig ikke er din

Atlassian har laget en mildere vei for Connect-apper: å ta i bruk Forge gradvis, beholde eksisterende installasjoner, konvertere deskriptoren til et Forge-manifest og flytte én modulfamilie om gangen, med innebygd datamigrering for noen moduler, som makroer, egendefinerte felt og validatorer i arbeidsflyter.

Haken står i første avsnitt av veiledningen: «Gradvis innføring av Forge er bare tilgjengelig for Connect-apper for Confluence og Jira som allerede er oppført på Marketplace.»

For en privat app bør du planlegge med en ny Forge-app. Du ruller den ut i produksjonsmiljøet, deler den med nettstedet ditt via en installasjonslenke fra utviklerkonsollen, kjører den ved siden av den gamle Connect-appen mens data migreres og brukerne tester, og fjerner deretter Connect-appen.

Veiledningene for innføring er fortsatt nyttige for koblingen mellom moduler, og det samme er listen over Connect-funksjoner som ikke er tilgjengelige i Forge: flere moduler for Jira Service Management og støtte for mobilappen er merket som ikke planlagt, og jiraReports er fortsatt under vurdering. Sjekk deskriptoren din mot den listen den første uken. Et hull der endrer designet.

En plan regnet bakover fra 31. januar 2027

Fra begynnelsen av oktober 2026 er det rundt sytten uker igjen, og desember er kort for alle. En plan som holder:

Denne uken: list opp hver LEGACY-app med de fem opplysningene over. Bekreft hvem som kontrollerer kildekoden og driftskontoen.
Innen midten av oktober: bestem migrere, erstatte eller avvikle for hver app. Si fra til brukerne av alt som skal avvikles.
Innen utgangen av oktober: en konseptutprøving i Forge for den vanskeligste delen av den vanskeligste appen. Som regel er det en modul uten direkte motsvarighet i Forge, eller den som har mest data.
November: utvikling, og kjør datamigreringen mot et testnettsted mer enn én gang.
Begynnelsen av desember: installer Forge-appen ved siden av Connect-appen, migrer en kopi av dataene, og la dem som bruker den hver dag, kontrollere den.
Januar 2027: endelig migrering, flytt brukerne over, og fjern Connect-appen først når den nye har kjørt feilfritt en stund.

Ett enkelt panel som leser data fra Jira og ikke lagrer noe, er en liten jobb. En app med egen database, regler for arbeidsflyt og koblinger til andre systemer trenger hver eneste av de ukene.

Rekker du ikke datoen, sier ingenting Atlassian har publisert, at appen slutter å virke den dagen. Men da kjører du en forretningsprosess på en plattform eieren har sluttet å reparere. Behandle den tiden som lånt, og fullfør flyttingen.

Når den opprinnelige utvikleren er borte

Atlassian tar opp dette tilfellet direkte. Kan du ikke identifisere eller kontakte den opprinnelige eieren av appen, eller har du ikke lenger utviklingskapasitet, foreslår Atlassian å engasjere en Solution Partner. Selskapet er like tydelig på at det uten kildekoden «kan bli nødvendig å bygge appen på nytt i Forge fra bunnen av».

Selv uten kildekode starter du ikke i blinde. Deskriptoren lister opp alt appen kobler seg til, oppførselen kan observeres på et testnettsted, og betaler selskapet ditt for serveren, kan du se hva som faktisk er rullet ut. En gjenoppbygging ut fra de bitene går tregere enn en portering, men den er en kjent størrelse.

Hvor du får hjelp

Vi tar over kode ingen i dagens team har skrevet, finner ut hva den egentlig gjør, og flytter den: for en Connect-app betyr det å lese deskriptoren og serveren, bygge Forge-appen og skrive og øve på datamigreringen. Arbeidet vårt med vedlikehold av eldre systemer er som regel der dette starter, og har dere utviklere, men ikke nok av dem, tilfører teamforsterkning folk til teamet deres så lenge det trengs. Fortell oss hva appen gjør og hvor den kjører: skriv til office@c9group.dev.