Atlassian Connect mister support 31. januar 2027: sådan flytter I egne Jira- og Confluence-apps til Forge

En rød puslespilsbrik blandt grønne

Den 31. januar 2027 afslutter Atlassian supporten for Connect, det framework som de fleste ældre apps til Jira og Confluence Cloud blev bygget på. Fra den dag vil Atlassian ifølge egne oplysninger »kun håndtere kritiske sikkerhedssårbarheder i Connect«, og en privat app, der stadig kører på Connect, »vil ikke længere være understøttet og kan holde op med at fungere korrekt«.

Kom alle apps på jeres site fra Atlassian Marketplace, er det leverandørernes opgave, og de fleste har gjort den: Atlassian oplyste i august 2026, at »over 95 % af de betalte app-pladser er migreret til Forge«.

Denne artikel handler om det andet tilfælde. Jeres virksomhed har en Jira- eller Confluence-app, som nogen har bygget til jer: en intern udvikler, en konsulent, en partner. Den blev installeret via et link, ikke købt. Ingen uden for jeres virksomhed kommer til at flytte den, og den person, der skrev den, er måske ikke længere i nærheden.

Hvad ophør af support betyder, og hvad det ikke betyder

Der er ingen offentliggjort slukkedato. Atlassian har ikke sagt, at Connect-apps holder op med at køre 1. februar 2027, og den oprindelige meddelelse om tidsplanen sagde, at »kunder, der har Connect-apps installeret, ikke mister adgangen til appen«.

Læs det ikke som en garanti. Det, der ændrer sig, er, at ingen hos Atlassian længere passer på Connect:

Kun kritiske sikkerhedssårbarheder bliver rettet. Ikke-kritiske fejl bliver liggende.
»Udfasning af funktioner i Connect vil ske med kort varsel.«
Atlassian Support »vil ikke kunne løse problemer forårsaget af den ældre teknologi«.
Med Atlassians egne ord: »Connect vil ikke forblive i en stabil tilstand efter ophør af support. Fejlene vil blive flere, og kompatibilitetshullerne vil blive større.«

Risikoen er altså gradvis, ikke en klippekant. Et sandsynligt nedbrud: Jira ændrer en side, et Connect-panel holder op med at blive vist, og der er ingen at oprette en sag hos. Sidder appen inde i en godkendelse i økonomiafdelingen eller en kundevendt service desk, hører I om det fra de mennesker, der er afhængige af den.

Hvad der allerede er sket

Januardatoen er det sidste trin i en række, der startede i 2025.

September 2025: Marketplace holdt op med at tage imod nye Connect-apps.
31. marts 2026: opdateringer blev frosset. Atlassians vejledning til egne apps sagde det ligeud: efter den dato »vil I ikke længere kunne sende opdateringer til Connect-apps«. Kode på jeres egen server kan I stadig ændre, men det, appen erklærer over for Jira eller Confluence (dens moduler, scopes og webhooks), ligger fast.
Marts 2026: tidsplanen sagde også, at »muligheden for at installere nye private Connect-apps via Connected Apps bliver utilgængelig«. Behandl en afinstallation som envejs: fjern ikke en privat Connect-app bare for at se, hvad der går i stykker.
August 2026: Atlassian flyttede ophøret af support fra december 2026 til 31. januar 2027. Det er én måned ekstra. Regn ikke med endnu en.
Nu: Atlassian ruller advarsler ud i Atlassian Administration, hvor private apps, der stadig er på Connect, er »markeret med status LEGACY«.

Find jeres private apps

Start i Atlassian Administration på siden Connected Apps. Alt, der er mærket LEGACY, kører på Connect. Atlassians tjekliste til at genkende en privat app: er de fleste af disse udsagn sande, er det jer, der skal flytte den:

installeret via et direkte link eller udviklertilstand, ikke fra Marketplace;
ikke synlig ved søgning på Marketplace;
jeres organisation vedligeholder kildekoden;
ingen licensoplysninger, og jeres organisation er den eneste, der står under installationer;
ingen sidebjælke med relaterede links på dens side under Connected Apps (Marketplace-apps har en).

Atlassian tilføjer en tommelfingerregel: en egen cloudapp, der er bygget for mere end fem år siden, er sandsynligvis en Connect-app, og Connect-apps hostes uden for Atlassian, »typisk på en tjeneste som Heroku, AWS, Azure eller Google Cloud Platform«. Appens link View app details viser, hvem udvikleren er, så vidt Atlassian ved.

Skriv fem ting ned for hver app, før nogen rører koden:

Hvad den gør, og hvem der bruger den, i en sætning, en forretningsansvarlig ville genkende.
Hvor kildekoden er. Et kodearkiv, I kontrollerer, en konsulents bærbare eller ingen steder.
Hvor den kører, og hvis konto der betaler for hostingen. Står serveren på en tidligere konsulents cloudkonto, er det en risiko i dag, ikke i januar.
Descriptoren. Hver Connect-app leverer en atlassian-connect.json-fil på en URL. Den oplister hvert modul, hvert scope og hver webhook, appen bruger, og det gør den til det mest pålidelige overblik, I kan få.
Hvilke data den gemmer, og hvor: i sin egen database eller i properties gemt på Jira-sager og Confluence-sider.

Beslut, før I bygger

Ikke alle private apps fortjener en migrering. Atlassians eget råd er at tjekke, om en indbygget funktion i Jira eller Confluence nu klarer opgaven, og kun migrere det, organisationen stadig har brug for. Gamle apps udfyldte ofte et hul, som produktet siden har lukket.

Hver app får et af tre svar: migrér, erstat med noget understøttet, eller udfas. At udfase er et legitimt resultat. Atlassian anbefaler, at hvis I dropper en app, så fortæller I brugerne det og planlægger fjernelsen før 31. januar 2027 i stedet for at lade den fejle af sig selv.

Hvad flytningen til Forge indebærer

Forge er ikke Connect under et nyt navn. Hostingmodellen, sikkerhedsmodellen og UI-modellen er alle anderledes, og derfor råder Atlassian selv ejere af enkle apps til at starte et proof of concept tidligt.

Hosting

En Connect-app er en webtjeneste, I selv driver. En Forge-app kører på Atlassians infrastruktur som funktioner med hårde grænser: 25 sekunder for en funktion, som en bruger udløser, og op til 900 sekunder for asynkrone hændelser og planlagte triggere. En Connect-app, der kører en synkronisering på ti minutter, mens brugeren venter, skal flytte det arbejde over i asynkrone hændelser, og alt, der varer længere end femten minutter, skal deles op i trin. Udgående kald er også begrænset: ethvert domæne, der ikke er erklæret i appens manifest, afvises.

Behold den backend, I har

Forge Remote lader en Forge-app kalde tjenester, som I hoster andre steder, lader jeres server tjekke, at en anmodning virkelig kom fra Forge, og giver jeres backend tokens til at kalde Atlassians API'er. For en privat app med mange års forretningslogik på serveren er det ofte den korteste vej: brugergrænsefladen og integrationspunkterne flytter til Forge, logikken bliver, hvor den er.

Prisen: Forge Remote kan gøre en app uberettiget til Atlassians program Runs on Atlassian. For et internt værktøj betyder det mindre, men jeres sikkerhedsteam bør acceptere det bevidst.

Autentificering og rettigheder

Connect-apps autentificerer med JWT signeret med en delt hemmelighed. Forge erstatter det med OAuth 2.0-scopes, der erklæres i manifestet, og for eksterne backends med et Forge Invocation Token, som jeres server validerer i stedet for en JWT.

Hvert autentificeret kald til Jiras eller Confluences API foretages derefter enten asUser, med rettighederne for den person, der bruger appen, eller asApp, som med Atlassians ord virker »uanset hvem der bruger appen«. At gå hvert kald igennem og vælge med vilje er den vigtigste sikkerhedsgennemgang i hele migreringen.

Én forskel overrasker teams. Connect-moduler vises som standard for brugere uden licens og anonyme brugere; Forge-moduler gør ikke, medmindre manifestet slår det til med unlicensedAccess. Viser jeres app noget for kunder i service desk eller anonyme Confluence-læsere, så test den vej for sig.

Brugergrænsefladen

Connect-sider er iframes, der taler med Jira eller Confluence gennem Atlassians JavaScript-API. Forge giver jer to muligheder:

UI Kit: et React-baseret framework, der gengiver Atlassians egne komponenter. Hurtigt og ensartet, men I bygger med Atlassians komponenter: egen HTML virker måske ikke, og de eneste statiske ressourcer, det accepterer, er billeder.
Custom UI: jeres egen HTML, CSS og JavaScript i en iframe, der taler med produktet gennem @forge/bridge.

En eksisterende iframe-frontend flytter som regel til Custom UI med færrest ændringer. Små paneler og indstillingsskærme er ofte hurtigere at lave om i UI Kit.

Data

Det er her, migreringer går galt. Forge har sin egen hostede lagring: et key-value-lager, et lager til custom entities, Forge SQL og et objektlager i preview. Data er afgrænset pr. installation og opbevares samme sted som det tilhørende Jira- eller Confluence-site, så dataresidens følger med uden ekstra konfiguration.

Hvad det betyder for en privat app:

Data i Connect-appens egen database flyttes enten til Forge-lagring med et engangsjob til migrering eller bliver, hvor de er, og nås via Forge Remote.
Alt, hvad Connect-appen har gemt på Atlassians side under sin egen app-nøgle, bør eksporteres, mens den gamle app stadig kører. Test tidligt, om den nye app kan læse det; gå ikke ud fra det.
Forge beholder hostede data i 28 dage efter en afinstallation, men en geninstallation gendanner dem ikke automatisk.

Skriv migreringen som et gentageligt script med optællinger, I kan kontrollere, øv den på et testsite, og gem eksporten.

Den gradvise vej, og hvorfor den nok ikke er jeres

Atlassian har bygget en blidere vej for Connect-apps: indfør Forge gradvist, behold eksisterende installationer, konvertér descriptoren til et Forge-manifest, og flyt én modulfamilie ad gangen, med indbygget datamigrering for visse moduler som makroer, egne felter og workflowvalidatorer.

Hagen står i vejledningens første afsnit: »Den gradvise indførelse af Forge er kun tilgængelig for Confluence- og Jira-Connect-apps, der allerede er opført på Marketplace.«

For en privat app skal I planlægge efter en ny Forge-app. I udruller den til produktionsmiljøet, deler den med jeres site via et installationslink fra udviklerkonsollen, kører den ved siden af den gamle Connect-app, mens data migreres og brugerne tester, og fjerner derefter Connect-appen.

Vejledningerne til indførelse er stadig nyttige for deres mapping af moduler, og det samme er listen over Connect-funktioner, der ikke findes i Forge: flere moduler til Jira Service Management og understøttelse af mobilappen er markeret som ikke planlagt, og jiraReports er stadig under overvejelse. Tjek jeres descriptor mod den liste i første uge. Et hul dér ændrer designet.

En plan baglæns fra 31. januar 2027

Fra begyndelsen af oktober 2026 er der omkring sytten uger tilbage, og december er kort for alle. En plan, der holder:

Denne uge: list hver LEGACY-app med de fem oplysninger ovenfor. Bekræft, hvem der kontrollerer kildekoden og hostingkontoen.
Inden midten af oktober: beslut migrér, erstat eller udfas for hver app. Fortæl brugerne af det, der udfases.
Inden udgangen af oktober: et proof of concept i Forge for den sværeste del af den sværeste app. Som regel er det et modul uden direkte modstykke i Forge, eller det, der indeholder flest data.
November: byg, og kør datamigreringen mod et testsite mere end én gang.
Begyndelsen af december: installér Forge-appen ved siden af Connect-appen, migrér en kopi af data, og lad de mennesker, der bruger den hver dag, tjekke den.
Januar 2027: endelig migrering, flyt brugerne over, og fjern først Connect-appen, når den nye har kørt problemfrit et stykke tid.

Et enkelt panel, der læser Jira-data og ikke gemmer noget, er en lille opgave. En app med egen database, workflowregler og koblinger til andre systemer har brug for hver eneste af de uger.

Overskrider I datoen, siger intet af det, Atlassian har offentliggjort, at appen holder op den dag. Men så kører I en forretningsproces på en platform, som ejeren er holdt op med at rette. Betragt den tid som lånt, og gør flytningen færdig.

Når den oprindelige udvikler er væk

Atlassian forholder sig direkte til det tilfælde. Kan I ikke identificere eller kontakte appens oprindelige ejer, eller har I ikke længere udviklingskapaciteten, foreslår Atlassian at inddrage en Solution Partner. Atlassian er lige så klar over, at uden kildekoden »kan det være nødvendigt at bygge forfra på Forge«.

Selv uden kildekode starter I ikke i blinde. Descriptoren oplister alt, hvad appen kobler sig på, dens adfærd kan observeres på et testsite, og betaler jeres virksomhed for serveren, kan I se, hvad der faktisk er udrullet. En genopbygning ud fra de brikker er langsommere end en portering, men den er en kendt størrelse.

Hvor I kan få hjælp

Vi overtager kode, som ingen i det nuværende team har skrevet, finder ud af, hvad den reelt gør, og flytter den: for en Connect-app betyder det at læse descriptoren og serveren, bygge Forge-appen og skrive og øve datamigreringen. Vores arbejde med vedligeholdelse af ældre systemer er som regel der, hvor det starter, og har I udviklere, men ikke nok, tilføjer teamforstærkning folk til jeres team i perioden. Fortæl os, hvad appen gør, og hvor den kører: skriv til office@c9group.dev.