Atlassian Connectin tuki päättyy 31. tammikuuta 2027: omien Jira- ja Confluence-sovellusten siirto Forgeen

Atlassian lopettaa 31. tammikuuta 2027 tuen Connectille, kehykselle, jolla useimmat vanhemmat Jira- ja Confluence Cloud -sovellukset on rakennettu. Siitä päivästä alkaen Atlassian sanoo ”korjaavansa Connectissa vain kriittiset tietoturvahaavoittuvuudet”, ja yksityinen sovellus, joka toimii yhä Connectilla, ”ei ole enää tuettu eikä välttämättä toimi enää oikein”.

Jos jokainen sivustosi sovellus on peräisin Atlassian Marketplacesta, tämä on toimittajiesi työ, ja useimmat ovat tehneet sen: Atlassian kertoi elokuussa 2026, että ”yli 95 % maksullisten sovellusten käyttäjäpaikoista on siirretty Forgeen”.

Tämä artikkeli on toista tapausta varten. Yritykselläsi on Jira- tai Confluence-sovellus, jonka joku rakensi teille: sisäinen kehittäjä, alihankkija tai kumppani. Se asennettiin linkin kautta, ei ostettu. Kukaan yrityksesi ulkopuolella ei siirrä sitä, eikä sen kirjoittaja välttämättä ole enää paikalla.

Mitä tuen päättyminen tarkoittaa ja mitä ei

Julkaistua sammutuspäivää ei ole. Atlassian ei ole sanonut, että Connect-sovellukset lakkaavat toimimasta 1. helmikuuta 2027, ja sen alkuperäinen aikatauluilmoitus totesi, että ”asiakkaat, joilla on Connect-sovelluksia asennettuna, eivät menetä pääsyä sovellukseen”.

Älä lue sitä turvallisuutena. Muuttuu se, että kukaan Atlassianilla ei enää huolehdi Connectista:

• Vain kriittiset tietoturvahaavoittuvuudet korjataan. Ei-kriittiset viat jäävät.
• ”Connectin ominaisuuksia poistetaan käytöstä vähällä varoitusajalla.”
• Atlassianin tuki ”ei pysty korjaamaan tuon vanhan teknologian aiheuttamia ongelmia”.
• Atlassianin omin sanoin: ”Connect ei pysy vakaassa tilassa tuen päättymisen jälkeen. Rikkoutumiset lisääntyvät ja yhteensopivuusaukot laajenevat.”

Riski on siis vähittäinen, ei jyrkänne. Uskottava vikaskenaario: Jira muuttaa sivua, Connect-paneeli lakkaa renderöitymästä, eikä ole ketään, jolle tehdä tukipyyntö. Jos sovellus on osa talouden hyväksyntäprosessia tai asiakkaille näkyvää palvelupistettä, kuulet siitä ihmisiltä, jotka ovat siitä riippuvaisia.

Mitä on jo tapahtunut

Tammikuun päivämäärä on vuonna 2025 alkaneen sarjan viimeinen vaihe.

• Syyskuu 2025: Marketplace lakkasi hyväksymästä uusia Connect-sovelluksia.
• 31. maaliskuuta 2026: päivitykset jäädytettiin. Atlassianin ohje omille sovelluksille sanoi sen suoraan: tuon päivän jälkeen ”et voi enää julkaista päivityksiä Connect-sovelluksiin”. Omalla palvelimellasi olevaa koodia voit yhä muuttaa, mutta se, mitä sovellus ilmoittaa Jiralle tai Confluencelle (sen moduulit, käyttöoikeusalueet ja webhookit), on lukittu.
• Maaliskuu 2026: aikataulussa todettiin myös, että ”mahdollisuus asentaa uusia yksityisiä Connect-sovelluksia Connected Apps -sivun kautta poistuu”. Käsittele asennuksen poistoa peruuttamattomana: älä poista yksityistä Connect-sovellusta vain nähdäksesi, mikä hajoaa.
• Elokuu 2026: Atlassian siirsi tuen päättymisen joulukuusta 2026 31. tammikuuta 2027. Se on yksi lisäkuukausi. Älä suunnittele toisen varaan.
• Nyt: Atlassian ottaa käyttöön varoituksia Atlassian Administrationissa, jossa Connectilla yhä toimivat yksityiset sovellukset ”merkitään LEGACY-tilalla”.

Yksityisten sovellusten löytäminen

Aloita Atlassian Administrationin Connected Apps -sivulta. Kaikki LEGACY-merkityt toimivat Connectilla. Atlassianin tarkistuslista yksityisen sovelluksen tunnistamiseen: jos useimmat näistä pitävät paikkansa, sovelluksen siirtäminen on sinun tehtäväsi:

• asennettu suoralla linkillä tai kehittäjätilassa, ei Marketplacesta;
• ei näy Marketplacen haussa;
• organisaatiosi ylläpitää lähdekoodia;
• ei lisenssitietoja, ja organisaatiosi on ainoa asennuksissa listattu;
• Connected Apps -sivulla ei ole aiheeseen liittyvien linkkien sivupalkkia (Marketplace-sovelluksilla on).

Atlassian lisää nyrkkisäännön: yli viisi vuotta sitten rakennettu oma pilvisovellus on todennäköisesti Connect-sovellus, ja Connect-sovelluksia isännöidään Atlassianin ulkopuolella, ”tyypillisesti palvelussa kuten Heroku, AWS, Azure tai Google Cloud Platform”. Sovelluksen View app details -linkki näyttää kehittäjän sikäli kuin Atlassian sen tietää.

Kirjaa jokaisesta sovelluksesta viisi asiaa ennen kuin kukaan koskee koodiin:

1. Mitä se tekee ja kuka sitä käyttää, lauseella, jonka liiketoiminnan omistaja tunnistaa.
2. Missä lähdekoodi on. Hallitsemassasi koodivarastossa, alihankkijan kannettavalla vai ei missään.
3. Missä se toimii ja kenen tili maksaa isännöinnin. Jos palvelin on entisen alihankkijan pilvitilillä, se on riski jo tänään, ei tammikuussa.
4. Kuvaustiedosto. Jokainen Connect-sovellus tarjoaa atlassian-connect.json-tiedoston URL-osoitteessa. Se luettelee jokaisen sovelluksen käyttämän moduulin, käyttöoikeusalueen ja webhookin, mikä tekee siitä luotettavimman luettelon, jonka saat.
5. Mitä dataa se säilyttää ja missä: omassa tietokannassaan vai Jira-tiketteihin ja Confluence-sivuihin tallennetuissa ominaisuuksissa.

Päätä ennen kuin rakennat

Kaikki yksityiset sovellukset eivät ansaitse siirtoa. Atlassianin oma neuvo on tarkistaa, hoitaako jokin Jiran tai Confluencen natiivi ominaisuus nyt saman tehtävän, ja siirtää vain se, mitä organisaatio yhä tarvitsee. Vanhat sovellukset täyttivät usein aukon, jonka tuote on sittemmin sulkenut.

Jokainen sovellus saa yhden kolmesta vastauksesta: siirto, korvaaminen tuetulla ratkaisulla tai käytöstä poisto. Käytöstä poisto on oikeutettu lopputulos. Atlassian suosittelee, että jos luovut sovelluksesta, kerrot siitä sen käyttäjille ja ajoitat poiston ennen 31. tammikuuta 2027 sen sijaan, että jätät sen hajoamaan itsestään.

Mitä Forgeen siirtyminen sisältää

Forge ei ole Connect uudella nimellä. Isännöintimalli, tietoturvamalli ja käyttöliittymämalli eroavat kaikki, minkä vuoksi Atlassian kehottaa yksinkertaistenkin sovellusten omistajia aloittamaan konseptitodistuksen ajoissa.

Isännöinti

Connect-sovellus on verkkopalvelu, jota sinä ylläpidät. Forge-sovellus toimii Atlassianin infrastruktuurissa funktioina, joilla on tiukat rajat: 25 sekuntia käyttäjän käynnistämälle funktiolle ja enintään 900 sekuntia asynkronisille tapahtumille ja ajastetuille käynnistimille. Connect-sovelluksen, joka ajaa kymmenen minuutin synkronoinnin käyttäjän odottaessa, on siirrettävä tuo työ asynkronisiin tapahtumiin, ja kaikki yli viisitoista minuuttia kestävä on pilkottava vaiheisiin. Myös lähtevät kutsut on rajoitettu: jokainen verkkotunnus, jota ei ole ilmoitettu sovelluksen manifestissa, hylätään.

Nykyisen taustajärjestelmän säilyttäminen

Forge Remote antaa Forge-sovelluksen kutsua muualla isännöimiäsi palveluja, antaa palvelimesi tarkistaa, että pyyntö todella tuli Forgesta, ja antaa taustajärjestelmällesi tunnisteet Atlassianin API-kutsuihin. Yksityiselle sovellukselle, jonka palvelimella on vuosien liiketoimintalogiikka, tämä on usein lyhyempi reitti: käyttöliittymä ja integraatiopisteet siirtyvät Forgeen, logiikka pysyy paikallaan.

Kompromissi: Forge Remote voi tehdä sovelluksesta kelpaamattoman Atlassianin Runs on Atlassian -ohjelmaan. Sisäiselle työkalulle se merkitsee vähemmän, mutta tietoturvatiimisi pitäisi hyväksyä se tietoisesti.

Tunnistautuminen ja käyttöoikeudet

Connect-sovellukset tunnistautuvat jaetulla salaisuudella allekirjoitetulla JWT:llä. Forge korvaa sen manifestissa ilmoitetuilla OAuth 2.0 -käyttöoikeusalueilla ja etätaustajärjestelmissä Forge Invocation Tokenilla, jonka palvelimesi validoi JWT:n sijaan.

Jokainen tunnistautunut kutsu Jiran tai Confluencen API:in tehdään sitten joko asUser, sovellusta käyttävän henkilön oikeuksin, tai asApp, joka Atlassianin sanoin toimii ”riippumatta siitä, kuka sovellusta käyttää”. Jokaisen kutsun läpikäynti ja tietoinen valinta on koko siirron tärkein tietoturvakatselmus.

Yksi ero yllättää tiimit. Connect-moduulit renderöityvät oletuksena lisensoimattomille ja anonyymeille käyttäjille; Forge-moduulit eivät, ellei manifesti salli sitä unlicensedAccess-asetuksella. Jos sovelluksesi näyttää jotain palvelupisteen asiakkaille tai anonyymeille Confluencen lukijoille, testaa tuo polku erikseen.

Käyttöliittymä

Connect-sivut ovat iframeja, jotka viestivät Jiran tai Confluencen kanssa Atlassianin JavaScript-API:n kautta. Forge tarjoaa kaksi vaihtoehtoa:

• UI Kit: React-pohjainen kehys, joka renderöi natiiveja Atlassian-komponentteja. Nopea ja yhtenäinen, mutta rakennat Atlassianin komponenteista: oma HTML ei välttämättä toimi, ja ainoat sen hyväksymät staattiset resurssit ovat kuvia.
• Custom UI: oma HTML, CSS ja JavaScript iframessa, ja viestintä tuotteen kanssa @forge/bridge-kirjaston kautta.

Olemassa oleva iframe-käyttöliittymä siirtyy yleensä Custom UI:hin vähimmin muutoksin. Pienet paneelit ja asetusnäkymät on usein nopeampi tehdä uudelleen UI Kitillä.

Data

Tässä siirrot menevät pieleen. Forgella on oma isännöity tallennustilansa: avain-arvo-säilö, omien entiteettien säilö, Forge SQL ja esikatseluvaiheessa oleva objektisäilö. Data rajataan asennuskohtaisesti ja säilytetään samassa sijainnissa kuin isäntänä toimiva Jira- tai Confluence-sivusto, joten datan sijainti hoituu ilman lisäkonfiguraatiota.

Mitä se tarkoittaa yksityiselle sovellukselle:

• Connect-sovelluksen omassa tietokannassa oleva data joko siirretään Forgen tallennustilaan kertaluonteisella siirtoajolla tai jätetään paikalleen ja tavoitetaan Forge Remoten kautta.
• Kaikki, minkä Connect-sovellus tallensi Atlassianin puolelle oman sovellusavaimensa alle, kannattaa viedä ulos, kun vanha sovellus vielä toimii. Testaa ajoissa, pystyykö uusi sovellus lukemaan sen; älä oleta.
• Forge säilyttää isännöidyn datan 28 päivää asennuksen poistamisen jälkeen, mutta uudelleenasennus ei palauta sitä automaattisesti.

Kirjoita siirto toistettavaksi skriptiksi, jonka määrät voi tarkistaa, harjoittele sitä testisivustolla ja säilytä vienti.

Vaiheittainen polku ja miksi se tuskin on sinun

Atlassian rakensi Connect-sovelluksille lempeämmän reitin: Forgen vaiheittaisen käyttöönoton, jossa olemassa olevat asennukset säilyvät, kuvaustiedosto muunnetaan Forge-manifestiksi ja siirretään yksi moduuliperhe kerrallaan, osalle moduuleista (kuten makroille, mukautetuille kentille ja työnkulun validaattoreille) sisäänrakennetun datansiirron kanssa.

Ansa on oppaan ensimmäisessä kappaleessa: ”Forgen vaiheittainen käyttöönotto on saatavilla vain Confluencen ja Jiran Connect-sovelluksille, jotka on jo listattu Marketplacessa.”

Yksityiselle sovellukselle suunnittele uusi Forge-sovellus. Otat sen käyttöön tuotantoympäristössä, jaat sen sivustollesi kehittäjäkonsolin asennuslinkillä, ajat sitä vanhan Connect-sovelluksen rinnalla datan siirron ja käyttäjätestauksen ajan ja poistat sitten Connect-sovelluksen.

Käyttöönotto-oppaat ovat silti hyödyllisiä moduulivastaavuuksiensa vuoksi, samoin luettelo Connectin ominaisuuksista, joita Forgessa ei ole: useat Jira Service Managementin moduulit ja mobiilisovellustuki on merkitty ei suunnitelluiksi, ja jiraReports on yhä harkinnassa. Tarkista kuvaustiedostosi tätä luetteloa vasten ensimmäisellä viikolla. Siellä oleva aukko muuttaa suunnitelmaa.

Suunnitelma taaksepäin 31. tammikuuta 2027 alkaen

Lokakuun 2026 alusta aikaa on noin seitsemäntoista viikkoa, ja joulukuu on kaikille lyhyt. Suunnitelma, joka pitää:

1. Tällä viikolla: listaa jokainen LEGACY-sovellus yllä mainittuine viitenä tietona. Varmista, kuka hallitsee lähdekoodia ja isännöintitiliä.
2. Lokakuun puoliväliin mennessä: päätä jokaisesta sovelluksesta siirto, korvaaminen tai käytöstä poisto. Kerro poistettavien sovellusten käyttäjille.
3. Lokakuun loppuun mennessä: Forge-konseptitodistus vaikeimman sovelluksen vaikeimmasta osasta. Yleensä se on moduuli, jolla ei ole suoraa Forge-vastinetta, tai se, jossa on eniten dataa.
4. Marraskuu: rakentaminen ja datansiirron ajaminen testisivustoa vasten useammin kuin kerran.
5. Joulukuun alku: asenna Forge-sovellus Connect-sovelluksen rinnalle, siirrä kopio datasta ja anna sitä päivittäin käyttävien ihmisten tarkistaa se.
6. Tammikuu 2027: lopullinen siirto, käyttäjien siirtäminen ja Connect-sovelluksen poisto vasta, kun uusi on toiminut jonkin aikaa moitteettomasti.

Yksittäinen paneeli, joka lukee Jiran dataa eikä tallenna mitään, on pieni työ. Sovellus, jolla on oma tietokanta, työnkulkusääntöjä ja linkkejä muihin järjestelmiin, tarvitsee jokaisen noista viikoista.

Jos myöhästyt, mikään Atlassianin julkaisemista ei sano, että sovellus lakkaa toimimasta sinä päivänä. Mutta silloin pyörität liiketoimintaprosessia alustalla, jonka omistaja on lakannut korjaamasta sitä. Pidä sitä aikaa lainattuna ja vie siirto loppuun.

Kun alkuperäinen kehittäjä on poissa

Atlassian käsittelee tätä tapausta suoraan. Jos et pysty tunnistamaan sovelluksen alkuperäistä omistajaa tai tavoittamaan sitä tai sinulla ei enää ole kehityskapasiteettia, se ehdottaa Solution Partnerin käyttämistä. Se sanoo yhtä selvästi, että ilman lähdekoodia ”voi olla tarpeen rakentaa sovellus Forgella alusta alkaen”.

Ilman lähdekoodiakaan et aloita sokkona. Kuvaustiedosto luettelee kaiken, mihin sovellus kytkeytyy, sen toimintaa voi tarkkailla testisivustolla, ja jos yrityksesi maksaa palvelimen, näet, mitä sinne on todellisuudessa asennettu. Uudelleenrakentaminen näistä paloista on hitaampaa kuin siirto, mutta se on tunnettu suure.

Mistä saat apua

Otamme haltuumme koodia, jota kukaan nykyisestä tiimistä ei kirjoittanut, selvitämme, mitä se todella tekee, ja siirrämme sen: Connect-sovelluksessa se tarkoittaa kuvaustiedoston ja palvelimen lukemista, Forge-sovelluksen rakentamista sekä datansiirron kirjoittamista ja harjoittelemista. Vanhojen järjestelmien ylläpitotyömme on yleensä se, mistä tämä alkaa, ja jos sinulla on kehittäjiä mutta ei tarpeeksi, henkilöstövuokraus tuo tiimiisi lisää ihmisiä projektin ajaksi. Kerro, mitä sovellus tekee ja missä se toimii: kirjoita osoitteeseen office@c9group.dev.