Migrering till Atlassian Cloud: därför lönar sig partnerstöd
Att flytta från Atlassian Data Center till Cloud är mer än en teknisk flytt. Läs om de vanligaste fallgroparna och varför rätt partner gör skillnad från dag ett.
Migrering till Atlassian Cloud är inte ett tekniskt projekt som råkar beröra verksamheten. Det är ett verksamhetsprojekt som råkar innehålla teknik. Den distinktionen avgör om ni lyckas.
De flesta organisationer som stöter på problem i en Cloud-migrering gör det inte för att tekniken är svår. De gör det för att de underskattat vad som faktiskt behöver hanteras utöver dataöverföringen.
Vad som faktiskt ingår i en migrering
Atlassians egna verktyg, Jira Cloud Migration Assistant (JCMA), är ett bra verktyg. Men det är precis vad det är: ett verktyg, inte en process. JCMA tar hand om dataflytten. Den tar inte hand om allt annat.
Det som typiskt faller utanför JCMA:
Automationer behöver granskas och i många fall skrivas om. Regelstrukturen i Jira Automation på Cloud skiljer sig från Server/DC-varianten. Det är inte ett fel utan en förbättring, men det tar tid och kräver att någon faktiskt går igenom er regel-för-regel.
Appar och tillägg har inte alltid Cloud-ekvivalenter. Några saknas helt. Några har begränsad funktionalitet i Cloud-versionen. Det behöver inventeras och beslutas i god tid, inte veckan före cutover.
ScriptRunner-logik (Groovy-scripts) lever inte vidare i Cloud. Den logiken behöver kartläggas och skrivas om i Jira Automation eller Atlassian Forge. Hur mycket arbete det är beror helt på hur mycket scripting ni byggt upp över åren.
Integrationer mot externa system behöver ny autentisering. Basic Auth och server-URL:er slutar fungera. OAuth 2.0 och API tokens gäller i Cloud, vilket innebär att varje integration behöver ses över innan cutover.
Varför en partner gör skillnad konkret
Det är inte för att ni inte klarar det själva. Det är för att ni förmodligen inte gjort det förut.
En erfaren partner har sett de hundratals platser där saker kan gå fel i en Atlassian-migrering. Det innebär bland annat:
En rollback-plan som faktiskt fungerar. Varje migrering vi genomför inkluderar en definierad rollback-trigger: ett specifikt tidsfönster och en kriterielista. Om kritiska funktioner inte kan verifieras inom fönstret rullar vi tillbaka. Det har hänt. Det är inte ett misslyckande; det är planen som fungerar.
Testmigreringar som faktisk förberedelse. Inte som en formell checkpoint utan som ett reellt tillfälle att hitta problem i en säker miljö. En testmigrering som avslöjar ett appkompatibilitetsproblem är värd tio gånger sin tid.
Atlassian Support på standby vid cutover. En partner med rätt certifieringsnivå kan eskalera direkt till Atlassians support under cutover-fönstret. Det är inte något ni kan ordna på egen hand med normalt support-SLA.
Migreringen öppnar nästa kapitel
Det finns ett skäl till att DC→Cloud-migrationer ökat i takt markant de senaste 18 månaderna: Rovo.
Rovo, Atlassians AI-plattform med Search, Agents och Studio, är exklusivt för Cloud Standard, Premium och Enterprise. Data Center-kunder har inte tillgång till det. Det innebär att varje kvartal ni dröjer med migreringen är ett kvartal ni betalar för en licens utan att ha tillgång till de AI-kapaciteter som ingår i den.
Migreringen är inte ett mål i sig. Den är ingångspunkten till vad Cloud faktiskt erbjuder.
Vad händer efter migreringen?
En lyckad migrering är en som slutar med att organisationen faktiskt landar rätt, inte bara att data finns på rätt ställe. Det innebär hypercare-stöd de första veckorna, verifiering av integrationer och automationer, och en tydlig plan för vad som händer sedan.
Vill ni se hur en strukturerad migrering ser ut i praktiken? Vi har dokumenterat hela vår 10-fas-metodik, från pre-migration assessment till knowledge transfer, i vår DC→Cloud-migreringstjänst.
Och är ni nyfikna på vad Rovo faktiskt innebär när ni väl är i Cloud: läs om hur vi arbetar med Rovo-aktivering och optimering.
