Atlassianin ilmoitettua Jira ja Confluence -palvelintuotteidensa tulleen tiensä päähän moni yritys harkitsee pilveen siirtymistä. Vaikka tuen päättymiseen on vielä pari vuotta aikaa, siirtymisen suunnittelu kannattaa aloittaa hyvissä ajoin ennen itse siirtymää. 

Mitä isompi ja monimutkaisempi ympäristö pyritään siirtämään, sitä haastavampi siirtymä tulee olemaan. Siirron suunnittelussa onkin hyvä ottaa huomioon rajoitukset ja niiden tuomat haasteet. Myös nykyisen palvelinympäristön projektien ja historiatietojen kriittinen arviointi kannattaa, tarvitseeko kaikkea siirtää?

Siirron suunnittelu ja siirtotavat

Siirtoa suunnitellessa voi käyttää hyödyksi Atlassianin tarjoamaa 12 kuukauden testijaksoa: https://www.atlassian.com/migration/cloud/free-license. Tuotantoon siirtoa voi myös harkita tehtäväksi osissa, jolloin pilviympäristön käyttö voidaan aloittaa pienemmällä lisenssillä. 

Isoimmat yhtenevät haasteet liittyvät käyttäjien ja sovellusten siirtoon:

• Käyttäjien osalta pitää arvioida, halutaanko siirtää kaikki käyttäjät vai vain osa ja toisaalta onko käyttäjätietokantana käytetty palvelintuotteen sisäistä hakemistoa vai onko käytössä joku ulkoinen hakemisto. 
• Pilviympäristön sovellusvalikoima on huomattavasti suppeampi. Toisaalta pilviympäristön natiivit ominaisuudet saattavat jo hoitaa tehtäviä, joihin palvelinympäristössä tarvittiin sovellus. Tästä esimerkkinä Single Sign On ja API -rajapinnan avaimet
• Sovellusten osalta on syytä myös huomioida, että niiden toiminta saattaa erota merkittävästi pilviympäristössä.

1. Cloud Migration Assistant

Cloud Migration Assistant on Atlassianin luoma sovellus, joka tulee sekä Jira että Confluence -asennusten mukana ja tarjoaa yksinkertaisimman lähtöpisteen siirtoa varten. Työkalu tarjoaa mahdollisuuden tarkastella mitkä käytössä olevista sovelluksista on tarjolla pilviympäristöön ja mahdollistaa myös projektien ja käyttäjien siirtämisen pilveen. Siirtovaiheessa on mahdollista valita vain osa projekteista siirrettäviksi ja käyttäjien osalta on mahdollista valita joko kaikki käyttäjät tai vain siirrettäviin projekteihin liittyvät käyttäjät. 

Hyvät puolet

• Mahdollistaa osittaisen palautuksen myös olemassaoleviin pilviympäristöihin
• Tarjoaa mahdollisuuden tarkistaa sovellusten yhteensopivuuden. Tätä ominaisuutta kannattaa hyödyntää, vaikka siirron tekisikin jollain toisella tavalla.

Rajoitteet ja ongelmat

• Jos käyttäjätietokantana on käytetty jotain ulkoista tietokantaa, kuten Active Directory, käyttäjät on tuotava Atlassianin pilviympäristöön ennen projektien siirtoa.
• Siirrettävällä käyttäjällä pitää olla toimiva ja uniikki sähköpostiosoite
• Cloud Migration Assistant ei tällä hetkellä tue Jira Service Management (ent. Service Desk) -projektien siirtoa.
• Ei välttämättä siirrä kaikkia muutoksia, kuten kaikkia custom field määrityksiä ja workflow -funktioita.
• Migraatiota ei ole mahdollista keskeyttää kun sen on kerran aloittanut

2. Tiedostojen siirtäminen varmuuskopiosta

Palvelinympäristöstä otetun XML -muotoisen varmuuskopion palauttaminen pilviympäristöön on mahdollista ja tämä lähestyminen tukee myös Jira Service Management -projektien palauttamista. Varmuuskopion palauttaminen ei tarjoa mahdollisuuksia vaikuttaa palautettavaan tietoon vaan pyrkii palauttamaan kaiken.

Hyvät puolet

• Pyrkii palauttamaan kaiken datan vanhasta ympäristöstä
• Yksinkertaisin vaihtoehto tyhjään ympäristöön siirryttäessä

Rajoitteet ja ongelmat

• Varmuuskopiosta ei voi tällä hetkellä tehdä osittaista palautusta, vaan varmuuskopion palauttaminen ylikirjoittaa kaikki ympäristössä olevat projekteihin liittyvät tiedot.
• Varmuuskopiossa ei saa olla käyttäjiä jotka on tuotu ulkopuolisesta käyttäjätietokannasta, vaan kaikki käyttäjät pitää ensin siirtää palvelintuotteen sisäiseen käyttäjätietokantaan
• Jos on tarkoitus palauttaa sekä Jira että Confluence, Confluence ympäristö täytyy luoda ja palauttaa ennen Jiran luontia. Jos pilviympäristössä on molemmat tuotteet, Confluence tukee ainoastaan Space Import -palautuksia.

3. Tietojen siirtäminen käsityönä

Jos siirrettävänä on vain muutama projekti, on mahdollista harkita myös tietojen palauttamista käsityönä. Confluencen osalta tämä tarkoittaa yksittäisen Spacen vientiä ja tuontia. Jirassa käsityötä on enemmän, mutta esimerkiksi Jira Service Management projektien siirtäminen onnistuu tällä lähestymistavalla.

Hyvät puolet

• Mahdollistaa osittaisen palauttamisen jo olemassa olevaan ympäristöön. Erityisen hyödyllinen esimerkiksi täydentämään Cloud Migration Assistant -palautusta
• Erityisen joustava, palautettaessa voi valita myös projektin sisältä vain osan tiedoista. Voi myös palauttaa vain muutaman tiketin.
• Tämä lähestyminen toimii myös Cloud-2-Cloud migraatioissa

Rajoitteet ja ongelmat

• Projektit pitää luoda ensin kohdeympäristöön. Muista tarkistaa nämä:
  • Issue -tyypit ja issue -tyyppi skeemat
  • Workflow -skeemat
  • Screens & Screen -skeemat
  • Fields & Field -skeemat
  • Permissions & Permission -skeemat
  • Notifications & Notification -skeemat
• Sprintit eivät siirry issue importissa
• Käyttäjätunnukset saattavat olla “väärässä” muodossa.
• Sub-task -tyyppisten tikettien linkitys emotikettiin tarvitsee muuttaa käyttämään tiketin avainta ID:n sijaan
• Liitetiedostot eivät siirry tikettien mukana, vaan vaativat erillistä työtä. Pienen määrän liitetiedostoja voi siirtää käsin, mutta suuren määrän siirtämiseen on parempi harkita erillisen skriptin kirjoittamista.
• Jos halutaan pitää Jira Service Management -projektien asiakaskäyttäjät projektikohtaisina, nämä pitää luoda ennen issue importtia.

Harjoitus tekee mestarin

Palvelimesta pilveen siirtymistä ei ole syytä tehdä hätiköidysti. On tärkeää että odotukset ja tarpeet on kartoitettu kunnolla ja testaamiselle varataan riittävästi aikaa. Ei myöskään kannata etukäteen valita tiettyä siirtotapaa vaan kannattaa rohkeasti kokeilla vaikka kaikkia ja vertailla lopputulosta.

Siirron kanssa ei liioin tarvitse jäädä yksin, ota rohkeasti yhteyttä, autamme mielellämme.