Fine del supporto di Atlassian Connect il 31 gennaio 2027: portare su Forge le app personalizzate di Jira e Confluence

Un pezzo di puzzle rosso tra pezzi verdi

Il 31 gennaio 2027 Atlassian termina il supporto di Connect, il framework su cui è costruita la maggior parte delle app più vecchie per Jira e Confluence Cloud. Da quel giorno, dice Atlassian, «interverrà solo sulle vulnerabilità di sicurezza critiche di Connect», e un'app privata che gira ancora su Connect «non sarà più supportata e potrebbe smettere di funzionare correttamente».

Se tutte le app del vostro sito vengono dall'Atlassian Marketplace, il lavoro spetta ai vostri fornitori, e la maggior parte l'ha già fatto: ad agosto 2026 Atlassian ha comunicato che «oltre il 95% delle licenze di app a pagamento è stato migrato su Forge».

Questo articolo è per l'altro caso. La vostra azienda ha un'app per Jira o Confluence che qualcuno ha costruito per voi: uno sviluppatore interno, un collaboratore esterno, un partner. È stata installata tramite link, non acquistata. Nessuno fuori dalla vostra azienda la sposterà, e chi l'ha scritta potrebbe non esserci più.

Cosa significa la fine del supporto, e cosa no

Non c'è una data di spegnimento pubblicata. Atlassian non ha detto che le app Connect smetteranno di funzionare il 1° febbraio 2027, e il suo annuncio originale del calendario diceva che «i clienti che hanno app Connect installate non perderanno l'accesso all'app».

Non leggetela come una garanzia. Quello che cambia è che in Atlassian nessuno si occupa più di Connect:

Si correggono solo le vulnerabilità di sicurezza critiche. I bug non critici restano.
«Le funzionalità di Connect verranno deprecate con poco preavviso.»
Il supporto di Atlassian «non potrà risolvere problemi causati da quella tecnologia legacy».
Con le parole di Atlassian: «Connect non resterà stabile dopo la fine del supporto. I malfunzionamenti aumenteranno e le incompatibilità si allargheranno.»

Quindi il rischio è graduale, non un precipizio. Un guasto plausibile: Jira cambia una pagina, un pannello Connect smette di comparire e non c'è nessuno a cui aprire un ticket. Se quell'app sta dentro un'approvazione amministrativa o un service desk rivolto ai clienti, lo verrete a sapere da chi ne dipende.

Cosa è già successo

La data di gennaio è l'ultimo passo di una sequenza iniziata nel 2025.

Settembre 2025: il Marketplace ha smesso di accettare nuove app Connect.
31 marzo 2026: aggiornamenti congelati. Le indicazioni di Atlassian per le app personalizzate lo dicevano chiaramente: dopo quella data «non potrete più pubblicare aggiornamenti delle app Connect». Il codice sul vostro server potete ancora modificarlo, ma ciò che l'app dichiara a Jira o Confluence (moduli, scope e webhook) è fisso.
Marzo 2026: il calendario diceva anche che «la possibilità di installare nuove app private Connect tramite Connected Apps non sarà più disponibile». Considerate una disinstallazione come irreversibile: non rimuovete un'app privata Connect solo per vedere cosa si rompe.
Agosto 2026: Atlassian ha spostato la fine del supporto da dicembre 2026 al 31 gennaio 2027. È un mese in più. Non contate su un altro.
Adesso: Atlassian sta introducendo avvisi in Atlassian Administration, dove le app private ancora su Connect sono «contrassegnate con lo stato LEGACY».

Trovare le vostre app private

Partite da Atlassian Administration, nella pagina Connected Apps. Tutto ciò che è contrassegnato come LEGACY gira su Connect. La lista di controllo di Atlassian per riconoscere un'app privata: se la maggior parte di queste condizioni è vera, spostarla tocca a voi:

è stata installata tramite link diretto o modalità sviluppatore, non dal Marketplace;
non compare nelle ricerche del Marketplace;
il codice sorgente lo mantiene la vostra organizzazione;
non ha informazioni di licenza, e la vostra organizzazione è l'unica elencata tra le installazioni;
nella sua pagina Connected Apps non c'è la barra laterale dei link correlati (le app del Marketplace ce l'hanno).

Atlassian aggiunge una regola empirica: un'app cloud personalizzata costruita più di cinque anni fa è probabilmente un'app Connect, e le app Connect sono ospitate fuori da Atlassian, «di solito su un servizio come Heroku, AWS, Azure o Google Cloud Platform». Il link View app details dell'app mostra chi ne è lo sviluppatore, per quanto ne sa Atlassian.

Per ogni app, annotate cinque cose prima che qualcuno tocchi il codice:

Cosa fa e chi la usa, in una frase che un responsabile di business riconoscerebbe.
Dove si trova il codice sorgente. Un repository che controllate voi, il portatile di un collaboratore esterno, o da nessuna parte.
Dove gira, e quale account paga l'hosting. Se il server sta sull'account cloud di un ex collaboratore, è un rischio oggi, non a gennaio.
Il descrittore. Ogni app Connect espone un file atlassian-connect.json a un URL. Elenca ogni modulo, scope e webhook che l'app usa, ed è quindi l'inventario più affidabile che otterrete.
Quali dati conserva, e dove: nel proprio database, oppure in proprietà salvate su issue di Jira e pagine di Confluence.

Decidere prima di sviluppare

Non tutte le app private meritano una migrazione. Il consiglio della stessa Atlassian è verificare se una funzionalità nativa di Jira o Confluence ora fa già il lavoro, e migrare solo ciò che serve ancora all'organizzazione. Le app vecchie spesso colmavano una lacuna che nel frattempo il prodotto ha chiuso.

Ogni app riceve una di tre risposte: migrarla, sostituirla con qualcosa di supportato, o dismetterla. Dismettere è un esito legittimo. Atlassian consiglia, se abbandonate un'app, di avvisarne gli utenti e di pianificarne la rimozione prima del 31 gennaio 2027, invece di lasciarla rompersi da sola.

Cosa comporta il passaggio a Forge

Forge non è Connect con un nome nuovo. Il modello di hosting, il modello di sicurezza e il modello di interfaccia sono tutti diversi, ed è per questo che Atlassian dice anche ai proprietari di app semplici di avviare presto una proof of concept.

Hosting

Un'app Connect è un servizio web che gestite voi. Un'app Forge gira sull'infrastruttura di Atlassian come funzioni con limiti rigidi: 25 secondi per una funzione attivata da un utente, fino a 900 secondi per gli eventi asincroni e i trigger pianificati. Un'app Connect che esegue una sincronizzazione di dieci minuti mentre l'utente aspetta deve spostare quel lavoro in eventi asincroni, e tutto ciò che dura più di quindici minuti va spezzato in passaggi. Anche le chiamate in uscita sono limitate: qualsiasi dominio non dichiarato nel manifest dell'app viene rifiutato.

Tenere il backend che avete

Forge Remote permette a un'app Forge di chiamare servizi che ospitate altrove, permette al vostro server di verificare che una richiesta arrivi davvero da Forge e dà al vostro backend i token per chiamare le API di Atlassian. Per un'app privata con anni di logica di business sul proprio server, spesso è la strada più breve: interfaccia e punti di integrazione passano a Forge, la logica resta dov'è.

Il compromesso: Forge Remote può rendere un'app non idonea al programma Runs on Atlassian. Per uno strumento interno conta meno, ma il vostro team di sicurezza dovrebbe accettarlo con cognizione di causa.

Autenticazione e permessi

Le app Connect si autenticano con JWT firmati con un segreto condiviso. Forge li sostituisce con scope OAuth 2.0 dichiarati nel manifest e, per i backend remoti, con un Forge Invocation Token che il vostro server valida al posto di un JWT.

Ogni chiamata autenticata alle API di Jira o Confluence avviene poi asUser, con i permessi della persona che usa l'app, oppure asApp, che con le parole di Atlassian funziona «indipendentemente da chi usa l'app». Passare in rassegna ogni chiamata e scegliere consapevolmente è la revisione di sicurezza più importante dell'intera migrazione.

Una differenza coglie di sorpresa i team. I moduli Connect vengono mostrati per impostazione predefinita agli utenti senza licenza e anonimi; i moduli Forge no, a meno che il manifest non lo preveda con unlicensedAccess. Se la vostra app mostra qualcosa ai clienti del service desk o ai lettori anonimi di Confluence, testate quel percorso a parte.

L'interfaccia utente

Le pagine Connect sono iframe che parlano con Jira o Confluence tramite l'API JavaScript di Atlassian. Forge offre due opzioni:

UI Kit: un framework basato su React che visualizza componenti nativi di Atlassian. Rapido e coerente, ma si costruisce con i componenti di Atlassian: l'HTML personalizzato potrebbe non funzionare, e le uniche risorse statiche accettate sono le immagini.
Custom UI: HTML, CSS e JavaScript vostri in un iframe, che parlano con il prodotto tramite @forge/bridge.

Un front end esistente basato su iframe di solito passa a Custom UI con meno modifiche. Piccoli pannelli e schermate di impostazioni spesso si rifanno prima in UI Kit.

Dati

È qui che le migrazioni vanno storte. Forge ha un proprio archivio ospitato: un archivio chiave-valore, un archivio di entità personalizzate, Forge SQL e un archivio di oggetti in anteprima. I dati sono separati per installazione e conservati nella stessa località del sito Jira o Confluence ospitante, quindi la residenza dei dati arriva senza configurazioni aggiuntive.

Cosa significa per un'app privata:

I dati nel database dell'app Connect si spostano nell'archivio Forge con un job di migrazione una tantum, oppure restano dove sono e si raggiungono tramite Forge Remote.
Tutto ciò che l'app Connect ha salvato sul lato Atlassian sotto la propria chiave dell'app va esportato finché la vecchia app gira ancora. Verificate presto se la nuova app riesce a leggerlo; non datelo per scontato.
Forge conserva i dati ospitati per 28 giorni dopo una disinstallazione, ma una reinstallazione non li ripristina in automatico.

Scrivete la migrazione come uno script ripetibile con conteggi verificabili, provatela su un sito di test e conservate l'esportazione.

Il percorso incrementale, e perché probabilmente non è il vostro

Atlassian ha costruito una strada più morbida per le app Connect: adottare Forge in modo incrementale, mantenere le installazioni esistenti, convertire il descrittore in un manifest Forge e spostare una famiglia di moduli alla volta, con una migrazione dei dati integrata per alcuni moduli come macro, campi personalizzati e validatori di workflow.

Il problema sta nel primo paragrafo della guida: «L'adozione incrementale di Forge è disponibile solo per le app Connect di Confluence e Jira già presenti sul Marketplace.»

Per un'app privata, prevedete una nuova app Forge. La distribuite nell'ambiente di produzione, la condividete con il vostro sito tramite un link di installazione dalla console per sviluppatori, la fate girare accanto alla vecchia app Connect mentre i dati vengono migrati e gli utenti la provano, poi rimuovete l'app Connect.

Le guide all'adozione restano utili per la corrispondenza dei moduli, e lo è anche l'elenco delle funzionalità di Connect non disponibili in Forge: diversi moduli di Jira Service Management e il supporto per l'app mobile sono indicati come non previsti, e jiraReports è ancora in valutazione. Confrontate il vostro descrittore con quell'elenco nella prima settimana. Una lacuna lì cambia il progetto.

Un piano a ritroso dal 31 gennaio 2027

Da inizio ottobre 2026 restano circa diciassette settimane, e dicembre è corto per tutti. Un piano che regge:

Questa settimana: elencate ogni app LEGACY con le cinque informazioni indicate sopra. Verificate chi controlla il codice sorgente e l'account di hosting.
Entro metà ottobre: decidete per ogni app se migrarla, sostituirla o dismetterla. Avvisate gli utenti di tutto ciò che viene dismesso.
Entro la fine di ottobre: una proof of concept su Forge per la parte più difficile dell'app più difficile. Di solito è un modulo senza un equivalente diretto in Forge, oppure quello che contiene più dati.
Novembre: sviluppo, ed esecuzione della migrazione dei dati su un sito di test più di una volta.
Inizio dicembre: installate l'app Forge accanto all'app Connect, migrate una copia dei dati e fatela verificare da chi la usa ogni giorno.
Gennaio 2027: migrazione finale, spostamento degli utenti, e rimozione dell'app Connect solo dopo che la nuova ha funzionato senza problemi per un po'.

Un singolo pannello che legge dati di Jira e non salva nulla è un lavoro piccolo. Un'app con un proprio database, regole di workflow e collegamenti ad altri sistemi ha bisogno di ognuna di quelle settimane.

Se mancate la data, nulla di quanto pubblicato da Atlassian dice che l'app si ferma quel giorno. Ma a quel punto state facendo girare un processo aziendale su una piattaforma che il suo proprietario ha smesso di correggere. Considerate quel tempo come preso in prestito, e completate il passaggio.

Quando lo sviluppatore originale non c'è più

Atlassian affronta questo caso direttamente. Se non riuscite a identificare o contattare il proprietario originale dell'app, o non avete più la capacità di sviluppo, suggerisce di rivolgersi a un Solution Partner. È altrettanto chiara sul fatto che senza il codice sorgente «potrebbe essere necessario ricostruire da zero su Forge».

Anche senza codice sorgente non partite alla cieca. Il descrittore elenca tutto ciò a cui l'app si aggancia, il suo comportamento si può osservare su un sito di test e, se il server lo paga la vostra azienda, potete vedere cosa è effettivamente distribuito. Una ricostruzione a partire da questi elementi è più lenta di un porting, ma è una quantità nota.

Dove trovare aiuto

Prendiamo in carico codice che nessuno del team attuale ha scritto, capiamo cosa fa davvero e lo spostiamo: per un'app Connect significa leggere il descrittore e il server, costruire l'app Forge, e scrivere e provare la migrazione dei dati. Il nostro lavoro di manutenzione dei sistemi legacy è di solito il punto di partenza, e se avete sviluppatori ma non abbastanza, la staff augmentation aggiunge persone al vostro team per tutta la durata. Diteci cosa fa l'app e dove gira: scrivete a office@c9group.dev.