Migrering till Jira Cloud: välj rätt verktyg för uppgiften

Atlassian meddelade nyligen att deras Server-produkter skulle fasas ut senast i februari 2024. Det innebär att många företag står inför ett val: att flytta till Data Center eller till Cloud. Om du ännu inte har bestämt vilket alternativ som passar dig bäst bör du läsa vår blogg om de viktigaste skillnaderna mellan de två: Är du redo för Jira Cloud eller Data Center?

Den här bloggen fokuserar på migrering från Jira Server till Cloud och behandlar olika migreringsalternativ och processer utifrån mina egna erfarenheter och verkliga kundfall.

Som nämnts är detta dock långt ifrån en process som passar alla – det finns många variabler som kan påverka din väg till Cloud. Det innebär att du kan stöta på andra problem under migreringen än de som tas upp i den här bloggen.

Före migreringen

Det finns mycket att göra före en migrering.

Först måste du säkerställa att din Server-instans är redo för migreringen. Exakt vad detta innebär beror på vilket migreringsalternativ du väljer. Olika alternativ har olika begränsningar som du behöver känna till, och vi går igenom dem längre fram.

Oavsett vilket alternativ du väljer är en migrering alltid ett bra tillfälle att städa upp i Jira. Det kan förenkla migreringsprocessen och göra livet enklare för administratörerna även efteråt.

Vanliga saker att tänka på

Atlassian har mycket dokumentation om migrering till Cloud utspridd på sin webbplats. En bra startpunkt är deras checklista före migrering.

Atlassian erbjuder tre olika migreringsalternativ:

• Jira Cloud Migration Assistant

• Site Import

• CSV Import

E-postadresser och användarkataloger

Oavsett vilket alternativ du väljer måste du säkerställa att dina användare har unika e-postadresser, eftersom detta är ett krav i Cloud. I Server går det att använda samma e-postadress för flera olika användare – vilket ofta görs för testanvändare – men det fungerar inte i Cloud.

Om du vill integrera med en extern användarkatalog eller konfigurera single sign-on (SSO) behöver du även konfigurera Atlassian Access. Detta bör vara klart före migreringen för att förenkla onboardingprocessen för dina användare.

Användarmedvetenhet

Du bör ha användarnas behov i åtanke redan från början av planeringen. Före varje migrering bör du informera användarna om följande:

• När migreringen sker.

• Hur de loggar in på den nya Cloud-instansen, eftersom det kan kännas väldigt annorlunda jämfört med vad de är vana vid.

• Om du gör ändringar i de appar som är installerade i dag – till exempel lägger till eller tar bort appar, eller om vissa appar förväntas fungera annorlunda.

• Eventuell driftstörning under migreringen.

• När de ska börja använda Cloud-webbplatsen.

Du bör också skapa en reservplan ifall migreringen misslyckas och behöver skjutas upp.

Löpande kommunikation är avgörande för en smidig onboarding till Cloud och kan bespara dig många frågor efter migreringen. Skapa även guider för vanliga användningsfall och vanliga frågor för att erbjuda en högre grad av självservice.

Appar

Oavsett vilket migreringsalternativ du väljer behöver du hantera migrering av appar separat – inget av migreringsalternativen hanterar appdata åt dig.

Vissa appar finns faktiskt fortfarande inte ens i Cloud. Om du använder en sådan app måste du bestämma vad du ska göra med den.

Kanske finns det en annan app du kan använda i stället? I så fall, hur migrerar du befintliga data till den nya appen? Eller kanske behöver du inte appen längre – i så fall kan migreringen vara ett bra tillfälle att göra dig av med den.

Vissa populära appar som finns både för Server och Cloud har tagit fram ett separat verktyg som hjälper till att migrera appdata till Cloud. Många andra appar har åtminstone dokumentation om processen. Ett exempel är EazyBI, som har ett integrerat verktyg för databasmigrering. Det fungerar utmärkt för att migrera alla dina BI-rapporter till EazyBI Cloud.

Ett motsatt exempel är Scriptrunner, som kan ha en mer besvärlig migreringsprocess. Scriptrunner har inte tillgång till Java API:t i Cloud, vilket innebär att vissa funktioner måste skrivas om för att fungera i Cloud. Andra funktioner, som Behaviors, finns inte i Scriptrunner för Cloud.

Exempel: appmigrering

För att tydliggöra vilka problem du kan stöta på vid appmigrering vill jag dela med mig av en dålig erfarenhet från verkligheten.

Appen i fråga kan visa HTML-formatering i ärenden. Appen behövdes inte längre – vilket var tur, eftersom den inte finns i Cloud – men problemet var att när den togs bort skulle all HTML-formatering bli synlig i varje ärende, vilket gjorde dem nästan oläsliga. Som tur var hade appleverantören skapat skript för att ta bort HTML-formateringen, men alla skript behövde köras mot Jira-databasen före migreringen för att rensa bort HTML-formateringen. Det var nödvändigt för att ärendena skulle vara läsbara när de fördes in på Cloud-sajten.

Skapa en plan för migrering av användare och appar

Oavsett vilket migreringsalternativ du väljer rekommenderar jag starkt att du tar fram en tydlig plan för migrering av användare och appar.

Före migreringen behöver du bestämma hur allt ska fungera när den är klar. Annars blir det besvärligt att reda ut allt samtidigt som du släpper in användarna på Cloud-sajten.

Beslutsträd för migreringsalternativ. Inspirerat av Atlassian: jämförelse av migreringsmetoder

Jira Cloud Migration Assistant

Jira Cloud Migration Assistant är Atlassians rekommenderade metod. Men fatta inga förhastade beslut – läs vidare, eftersom Migration Assistant fortfarande saknar funktioner som kan göra det till ett dåligt val för dig.

Fördelarna med Jira Cloud Migration Assistant

Det bästa med Migration Assistant är att det är mycket enkelt att använda. Installera appen precis som vilken annan app som helst och låt den guida dig genom migreringen. Migration Assistant låter dig också migrera ett enskilt projekt som testmigrering i stället för hela instansen, vilket sparar mycket tid. Det är även en smidig funktion om du vill samla projekt från flera instanser, eller bara en delmängd av projekten från en instans, i samma Cloud-instans. Det gör Jira Cloud Migration Assistant till ett utmärkt verktyg för att migrera enkla projekt.

Det hjälper dig också att skapa en plan för appmigrering, även om den är ganska grundläggande. I huvudsak får du bara veta om dina installerade appar finns i Cloud eller inte, och i vissa fall föreslås att du kontaktar utvecklaren för att klargöra migreringsalternativen.

Du kan också göra anteckningar och markera varje app som behövd eller inte i Cloud. Det kan ge en bra överblick över dina appar, men personligen tycker jag inte att det är särskilt användbart eftersom du enkelt kan kontrollera kompatibiliteten själv och ändå behöver undersöka alternativen för appmigrering separat.

Atlassian planerar att lägga till stöd för vissa appar i Migration Assistant. När det händer tror jag att verktyget blir betydligt mer användbart.

Begränsningarna i Jira Cloud Migration Assistant

Tyvärr har Migration Assistant också vissa begränsningar. Den första du behöver känna till är versionsgränsen. Den lägsta Jira-version som krävs är 7.6.0 – förhoppningsvis använder du redan denna eller en nyare version, eftersom versionen nådde end of life den 14 november 2019. Annars behöver du genomföra en uppgradering innan migreringen.

Jag har använt Migration Assistant från Jira-versioner 8.X, där det har fungerat stabilt, bortsett från begränsningarna.

På tal om begränsningar finns det många saker som Migration Assistant för närvarande inte migrerar. Atlassian har en lista över vad som migreras och inte migreras här. Som du ser är listan ganska lång, så jag vill lyfta fram några vanliga funktioner som inte migreras:

• Många workflow-funktioner

• Vissa anpassade fält

• E-posthanterare

• Globala behörigheter

• Jira Service Desk-projekt

• Dashboards

• Confluence-länkar

Observera att Confluence-länkar från Jira-ärenden inte migreras. Det innebär att om du länkar ditt Confluence-innehåll till Jira-ärenden (vilket du bör göra) passar det här alternativet troligen inte dig.

Jag kan tänka mig att dessa problem kan bli avgörande för många företag när de ska välja om de vill använda Migration Assistant eller inte.

Det här behöver du tänka på

Migration Assistant är ännu ingen komplett lösning. Appen är fortfarande under utveckling och uppdateras regelbundet. Du måste alltid ha den senaste versionen av appen installerad för att kunna använda den.

Var därför beredd på att fortsätta uppgradera appen under hela migreringsprocessen. Förhoppningsvis går inget sönder – men det har hänt!

Site Import

Ett annat alternativ för att hantera migreringen är site import. Du skapar en XML-säkerhetskopia från din Server och laddar upp den samt dina zippade bilagemappar till din Cloud-webbplats. Processen är ganska enkel och verkar stabil, även om även detta alternativ har vissa begränsningar att ta hänsyn till.

Site import hanterar nästan allt åt dig, inklusive alla funktioner som saknar stöd i appen Migration Assistant. Bara detta kan göra det till det självklara valet för många företag som migrerar till en ny Cloud-webbplats.

Det här alternativet kräver också en lägsta version av Jira Server som stöds, även om kraven är något otydliga. Site import kan fungera mellan v7.0 och v7.13, med vissa kända problem. Den rekommenderade versionen är 7.13.1 eller senare.

Du måste också vara medveten om att detta är en allt-eller-inget-lösning. All befintlig data på din Cloud-webbplats skrivs över (förutom användarna). Det innebär också att du inte kan välja vilka data från din Server som ska migreras.

Processen i sig tar tid, särskilt om dina zippade bilagor överstiger 10 GB. Då måste du dela upp dem i två eller fler bilagemappar för att undvika tidsgränser vid import till Cloud. Om din XML-säkerhetskopia överstiger 10 GB måste du också kontakta Atlassian support för hjälp med importen.

Förutsatt att du har förberett din användarbas i förväg är site import åtminstone inte särskilt felbenägen.

CSV-import

Det sista migreringsalternativet är CSV-import. Med det här alternativet kan du välja enskilda ärenden att migrera, men du kan inte migrera hela projekt eller andra saker. Det gör alternativet användbart för att konsolidera data från olika projekt eller olika Jira-instanser.

Det är en mer grundläggande lösning och kanske inte det främsta alternativet om du migrerar till en ny Cloud-webbplats. Men eftersom det inte har samma versionskrav som de andra alternativen kan det vara ett gångbart alternativ för grundläggande instanser från äldre Jira-versioner.

Du kan också se detta som ett kompletterande alternativ till någon av de andra migreringsmetoderna.

Migrering – våra viktigaste rekommendationer

Jag rekommenderar att du skapar ett supportärende hos Atlassian Migration före migreringen. Så snart du har ett exakt datum för produktionsmigreringen bör du meddela Atlassian, så att de snabbt kan hjälpa dig om du behöver assistans. De svarar vanligtvis snabbt och kan hjälpa dig att övervinna hinder.

Genomför alla testmigreringar du behöver för att känna dig trygg med processen och slutresultatet. Om du använder Jira Cloud Migration Assistant är det enkelt eftersom du inte behöver migrera allt varje gång.

Kom ihåg att testa datamigreringarna för apparna. Om Atlassian behöver åtgärda något på din Cloud-webbplats efter migreringen, se till att de gör det även i samband med din testmigrering. Du vill säkerställa att åtgärden löser problemet på ett tillfredsställande sätt.

Var också beredd på det oväntade. Enligt min erfarenhet är det mer regel än undantag att stöta på problem under testmigreringarna. Förhoppningsvis kan du undvika de flesta problemen genom att planera i god tid, men du kommer ändå oundvikligen att stöta på vissa problem. Det är just därför du genomför testmigreringar.

Du kanske provar Migration Assistant men upptäcker att vissa av dina arbetsflöden använder arbetsflödesfunktioner som inte migreras. Kanske fungerar en app annorlunda i Cloud än du förväntat dig. Eller så har vissa användare inloggningsproblem på grund av en ny Atlassian Access-konfiguration.

Problemen kan variera, men en sak är säker: du vill åtgärda dem alla före den slutliga migreringen.

Kom också ihåg att noggrant dokumentera vilka steg du tar under testmigreringarna – under produktionsmigreringen vill du bara följa rätt steg. Beroende på hur komplexa din Server-miljö och organisation är kan en migreringsprocess lätt ta upp till sex månader, och du kommer inte att komma ihåg de små teststeg du provade flera månader tidigare.

Efter migreringen – vad kan du förvänta dig?

Räkna med frågor och önskemål från användarna när de börjar använda Cloud-webbplatsen. Vissa frågor kommer oundvikligen att handla om de olika användargränssnitt som användarna behöver vänja sig vid, medan andra gäller förändrad funktionalitet. Kom ihåg att dokumentera svaren på vanliga frågor så slipper du svara på samma frågor om och om igen.

Förhoppningsvis handlar bara ett fåtal önskemål om sådant som har gått sönder eller misslyckats under migreringen. Kom bara ihåg att använda supporten från Atlassian och appleverantörerna vid behov.

När allt är klart återstår bara en sak att säga: välkommen till Cloud och grattis till en lyckad migrering!

Nu kan du njuta av att slippa underhålla servrar eller planera uppdateringar. Tänk bara på att du fortfarande bör hålla en hög nivå av Jira-hygien för att förenkla vardagen för administratörer och användare.

Atlassian arbetar hårt för att göra migreringsprocessen så smidig som möjligt. Ny funktionalitet och nya verktyg lanseras ofta, så tänk på att vissa punkter i den här bloggen kan vara inaktuella när du läser den.

Om du har frågor om migreringar till Atlassian Jira Cloud, eller vill att jag utvecklar något som tas upp i den här bloggen, är du välkommen att kontakta oss eller läsa mer om hur vi kan hjälpa dig med Atlassian Cloud.