Einde ondersteuning van Atlassian Connect op 31 januari 2027: eigen Jira- en Confluence-apps overzetten naar Forge

Op 31 januari 2027 beëindigt Atlassian de ondersteuning voor Connect, het framework waarop de meeste oudere apps voor Jira en Confluence Cloud zijn gebouwd. Vanaf die dag zal Atlassian, zo zegt het bedrijf, “alleen nog kritieke beveiligingskwetsbaarheden in Connect aanpakken”, en een private app die nog op Connect draait “wordt niet langer ondersteund en werkt mogelijk niet meer goed”.

Komt elke app op uw site uit de Atlassian Marketplace, dan is dit het werk van uw leveranciers, en de meesten hebben het gedaan: Atlassian meldde in augustus 2026 dat “meer dan 95% van de betaalde app-seats naar Forge is gemigreerd”.

Dit artikel is voor het andere geval. Uw bedrijf heeft een app voor Jira of Confluence die iemand voor u heeft gebouwd: een interne ontwikkelaar, een freelancer, een partner. Hij is via een link geïnstalleerd, niet gekocht. Niemand buiten uw bedrijf gaat hem verhuizen, en wie hem schreef, is er misschien niet meer.

Wat einde ondersteuning betekent, en wat niet

Er is geen gepubliceerde uitschakeldatum. Atlassian heeft niet gezegd dat Connect-apps op 1 februari 2027 stoppen met draaien, en de oorspronkelijke aankondiging van de tijdlijn zei dat “klanten die Connect-apps hebben geïnstalleerd de toegang tot de app niet verliezen”.

Lees dat niet als zekerheid. Wat verandert, is dat niemand bij Atlassian nog voor Connect zorgt:

• Alleen kritieke beveiligingskwetsbaarheden worden gerepareerd. Niet-kritieke bugs blijven.
• “Functies van Connect worden met weinig aankondiging uitgefaseerd.”
• Atlassian Support “kan geen problemen oplossen die door die verouderde technologie worden veroorzaakt”.
• In de eigen woorden van Atlassian: “Connect blijft na het einde van de ondersteuning niet stabiel. Er zal steeds meer stukgaan en de compatibiliteitsgaten worden groter.”

Het risico is dus geleidelijk, geen afgrond. Een aannemelijk scenario: Jira verandert een pagina, een Connect-paneel wordt niet meer weergegeven, en er is niemand bij wie u een ticket kunt indienen. Zit die app in een financiële goedkeuringsstroom of in een servicedesk voor klanten, dan hoort u het van de mensen die ervan afhankelijk zijn.

Wat er al is gebeurd

De datum in januari is de laatste stap van een reeks die in 2025 begon.

• September 2025: de Marketplace accepteerde geen nieuwe Connect-apps meer.
• 31 maart 2026: updates werden bevroren. De richtlijnen van Atlassian voor eigen apps zeiden het zonder omwegen: na die datum “kunt u geen updates meer naar Connect-apps pushen”. Code op uw eigen server kunt u nog steeds wijzigen, maar wat de app aan Jira of Confluence declareert (de modules, scopes en webhooks), ligt vast.
• Maart 2026: de tijdlijn zei ook dat “de mogelijkheid om nieuwe private Connect-apps via Connected Apps te installeren niet meer beschikbaar is”. Behandel een de-installatie als onomkeerbaar: verwijder een private Connect-app niet om te kijken wat er stukgaat.
• Augustus 2026: Atlassian verschoof het einde van de ondersteuning van december 2026 naar 31 januari 2027. Dat is één maand extra. Reken niet op nog een.
• Nu: Atlassian rolt waarschuwingen uit in Atlassian Administration, waar private apps die nog op Connect draaien “worden gemarkeerd met de status LEGACY”.

Uw private apps vinden

Begin in Atlassian Administration, op de pagina Connected Apps. Alles met het label LEGACY draait op Connect. De checklist van Atlassian om een private app te herkennen: is het meeste hiervan waar, dan is het aan u om hem te verhuizen:

• geïnstalleerd via een directe link of in developer mode, niet via de Marketplace;
• niet zichtbaar in de zoekresultaten van de Marketplace;
• uw organisatie onderhoudt de broncode;
• geen licentie-informatie, en uw organisatie is de enige die onder installaties staat;
• geen zijbalk met gerelateerde links op de pagina in Connected Apps (Marketplace-apps hebben die wel).

Atlassian voegt een vuistregel toe: een eigen cloudapp die meer dan vijf jaar geleden is gebouwd, is waarschijnlijk een Connect-app, en Connect-apps worden buiten Atlassian gehost, “meestal op een dienst als Heroku, AWS, Azure of Google Cloud Platform”. De link View app details van de app toont wie de ontwikkelaar is, voor zover Atlassian dat weet.

Noteer per app vijf dingen voordat iemand de code aanraakt:

1. Wat de app doet en wie hem gebruikt, in een zin die een eigenaar in het bedrijf herkent.
2. Waar de broncode staat. Een repository die u beheert, de laptop van een freelancer, of nergens.
3. Waar de app draait, en welk account de hosting betaalt. Staat de server op het cloudaccount van een voormalige freelancer, dan is dat vandaag al een risico, niet pas in januari.
4. De descriptor. Elke Connect-app serveert een bestand atlassian-connect.json op een URL. Daarin staan alle modules, scopes en webhooks die de app gebruikt, en dat maakt het de betrouwbaarste inventaris die u krijgt.
5. Welke gegevens de app bewaart, en waar: in een eigen database, of in properties die op Jira-issues en Confluence-pagina's zijn opgeslagen.

Beslis voordat u bouwt

Niet elke private app verdient een migratie. Het eigen advies van Atlassian is na te gaan of een standaardfunctie van Jira of Confluence het werk nu doet, en alleen te migreren wat de organisatie nog nodig heeft. Oude apps vulden vaak een gat dat het product inmiddels heeft gedicht.

Elke app krijgt een van drie antwoorden: migreren, vervangen door iets wat wordt ondersteund, of uitfaseren. Uitfaseren is een legitieme uitkomst. Atlassian raadt aan om, als u een app laat vallen, de gebruikers in te lichten en de verwijdering vóór 31 januari 2027 in te plannen, in plaats van hem vanzelf te laten falen.

Wat de overstap naar Forge inhoudt

Forge is geen Connect onder een nieuwe naam. Het hostingmodel, het beveiligingsmodel en het UI-model verschillen allemaal, en daarom zegt Atlassian zelfs tegen eigenaren van eenvoudige apps dat ze vroeg met een proof of concept moeten beginnen.

Hosting

Een Connect-app is een webdienst die u zelf draait. Een Forge-app draait op de infrastructuur van Atlassian als functies met harde limieten: 25 seconden voor een functie die een gebruiker start, tot 900 seconden voor async events en geplande triggers. Een Connect-app die een synchronisatie van tien minuten draait terwijl de gebruiker wacht, moet dat werk naar async events verplaatsen, en alles wat langer duurt dan een kwartier moet in stappen worden opgesplitst. Ook uitgaande aanroepen zijn beperkt: elk domein dat niet in het manifest van de app is gedeclareerd, wordt geweigerd.

De backend houden die u hebt

Met Forge Remote kan een Forge-app diensten aanroepen die u elders host, kan uw server controleren of een verzoek echt van Forge komt, en krijgt uw backend tokens om API's van Atlassian aan te roepen. Voor een private app met jaren aan bedrijfslogica op de server is dat vaak de kortere route: de UI en de integratiepunten gaan naar Forge, de logica blijft waar ze is.

De keerzijde: door Forge Remote kan een app buiten het programma Runs on Atlassian vallen. Voor een interne tool maakt dat minder uit, maar uw securityteam moet het bewust accepteren.

Authenticatie en machtigingen

Connect-apps authenticeren met JWT, ondertekend met een gedeeld geheim. Forge vervangt dat door OAuth 2.0-scopes die in het manifest worden gedeclareerd en, voor backends op afstand, door een Forge Invocation Token dat uw server valideert in plaats van een JWT.

Elke geauthenticeerde aanroep van de API van Jira of Confluence gebeurt dan asUser, met de machtigingen van de persoon die de app gebruikt, of asApp, wat volgens Atlassian werkt “ongeacht wie de app gebruikt”. Elke aanroep langslopen en bewust kiezen, is de belangrijkste beveiligingsreview van de hele migratie.

Eén verschil overvalt teams. Connect-modules worden standaard weergegeven voor gebruikers zonder licentie en anonieme gebruikers; Forge-modules niet, tenzij het manifest daarvoor kiest met unlicensedAccess. Toont uw app iets aan klanten van de servicedesk of aan anonieme lezers in Confluence, test dat pad dan apart.

De gebruikersinterface

Connect-pagina's zijn iframes die via de JavaScript-API van Atlassian met Jira of Confluence praten. Forge biedt twee opties:

• UI Kit: een op React gebaseerd framework dat native Atlassian-componenten weergeeft. Snel en consistent, maar u bouwt met de componenten van Atlassian: eigen HTML werkt mogelijk niet, en de enige statische resources die het accepteert, zijn afbeeldingen.
• Custom UI: uw eigen HTML, CSS en JavaScript in een iframe, dat via @forge/bridge met het product praat.

Een bestaande frontend in een iframe gaat meestal met de minste wijzigingen naar Custom UI. Kleine panelen en instellingenschermen zijn vaak sneller opnieuw te maken in UI Kit.

Gegevens

Hier gaan migraties mis. Forge heeft eigen gehoste opslag: een key-value store, een store voor eigen entiteiten, Forge SQL, en een object store in preview. Gegevens zijn per installatie afgebakend en worden op dezelfde locatie bewaard als de Jira- of Confluence-site waarop de app draait, dus dataresidentie krijgt u zonder extra configuratie.

Wat dat betekent voor een private app:

• Gegevens in de eigen database van de Connect-app worden ofwel met een eenmalige migratietaak naar Forge-opslag verplaatst, ofwel laat u ze staan en benadert u ze via Forge Remote.
• Alles wat de Connect-app onder haar eigen app-key aan de kant van Atlassian heeft opgeslagen, exporteert u zolang de oude app nog draait. Test vroeg of de nieuwe app het kan lezen; ga er niet van uit.
• Forge bewaart gehoste gegevens 28 dagen na een de-installatie, maar een herinstallatie zet ze niet automatisch terug.

Schrijf de migratie als herhaalbaar script met tellingen die u kunt controleren, repeteer haar op een testsite, en bewaar de export.

Het geleidelijke pad, en waarom dat waarschijnlijk niet het uwe is

Atlassian bouwde een zachtere route voor Connect-apps: Forge geleidelijk invoeren, bestaande installaties houden, de descriptor omzetten naar een Forge-manifest en per moduletype verhuizen, met ingebouwde datamigratie voor sommige modules, zoals macro's, eigen velden en workflowvalidators.

Het addertje staat in de eerste alinea van de gids: “Geleidelijke invoering van Forge is alleen beschikbaar voor Connect-apps voor Confluence en Jira die al in de Marketplace staan.”

Reken voor een private app op een nieuwe Forge-app. U rolt hem uit naar de productieomgeving, deelt hem met uw site via een installatielink uit de developer console, draait hem naast de oude Connect-app terwijl de gegevens worden gemigreerd en gebruikers testen, en verwijdert daarna de Connect-app.

De adoptiegidsen blijven nuttig vanwege hun modulemapping, en dat geldt ook voor de lijst van Connect-mogelijkheden die in Forge niet beschikbaar zijn: verschillende Jira Service Management-modules en ondersteuning voor de mobiele app staan als niet gepland gemarkeerd, en jiraReports wordt nog overwogen. Leg uw descriptor in de eerste week naast die lijst. Een gat daarin verandert het ontwerp.

Een plan terug vanaf 31 januari 2027

Begin oktober 2026 zijn er nog ongeveer zeventien weken, en december is voor iedereen kort. Een plan dat standhoudt:

1. Deze week: maak een lijst van elke LEGACY-app met de vijf feiten hierboven. Bevestig wie de broncode en het hostingaccount beheert.
2. Uiterlijk half oktober: beslis per app of u migreert, vervangt of uitfaseert. Licht de gebruikers in van alles wat wordt uitgefaseerd.
3. Uiterlijk eind oktober: een Forge-proof of concept voor het moeilijkste deel van de moeilijkste app. Meestal is dat een module zonder directe tegenhanger in Forge, of de module met de meeste gegevens.
4. November: bouwen, en de datamigratie meer dan eens tegen een testsite draaien.
5. Begin december: installeer de Forge-app naast de Connect-app, migreer een kopie van de gegevens, en laat de mensen die hem elke dag gebruiken hem controleren.
6. Januari 2027: laatste migratie, gebruikers overzetten, en de Connect-app pas verwijderen als de nieuwe een tijdje zonder problemen heeft gedraaid.

Eén paneel dat Jira-gegevens leest en niets opslaat, is een kleine klus. Een app met een eigen database, workflowregels en koppelingen met andere systemen heeft al die weken nodig.

Haalt u de datum niet, dan zegt niets wat Atlassian heeft gepubliceerd dat de app die dag stopt. Maar u draait dan een bedrijfsproces op een platform dat de eigenaar niet meer repareert. Behandel die tijd als geleend, en maak de verhuizing af.

Als de oorspronkelijke ontwikkelaar weg is

Atlassian gaat rechtstreeks op dit geval in. Kunt u de oorspronkelijke eigenaar van de app niet achterhalen of bereiken, of hebt u niet meer de ontwikkelcapaciteit, dan raadt Atlassian aan een Solution Partner in te schakelen. Het bedrijf is even duidelijk dat het zonder de broncode “nodig kan zijn de app vanaf nul opnieuw op Forge te bouwen”.

Ook zonder broncode begint u niet blind. De descriptor somt alles op waarop de app aansluit, het gedrag kunt u op een testsite observeren, en betaalt uw bedrijf de server, dan kunt u zien wat er werkelijk is uitgerold. Herbouwen vanuit die stukken gaat langzamer dan overzetten, maar het is een bekende grootheid.

Waar u hulp krijgt

Wij nemen code over die niemand in het huidige team heeft geschreven, zoeken uit wat ze werkelijk doet en verhuizen haar: bij een Connect-app betekent dat de descriptor en de server lezen, de Forge-app bouwen, en de datamigratie schrijven en repeteren. Ons werk voor onderhoud van legacysystemen is meestal waar dit begint, en hebt u ontwikkelaars maar niet genoeg, dan voegt staff augmentation voor de duur van het project mensen aan uw team toe. Vertel ons wat de app doet en waar hij draait: schrijf naar office@c9group.dev.