Varför intern kompetens sällan räcker

De flesta IT-avdelningar har kompetenta ingenjörer som kan konfigurera en VPC, sätta upp en Kubernetes-kluster eller skriva CI/CD-pipelines. Problemet är inte individuell teknisk förmåga – det är skalbar migreringserfarenhet.

Ett internt team som aldrig har migrerat 200 arbetsbelastningar vet inte vilka problem som dyker upp vid belastning nummer 137. De har inte sett hur en databasmigreringssekvens som fungerar perfekt i staging havererar i produktion på grund av latens mot en tredjeparts-API. De har inte byggt rollback-rutiner som testas mot klockan kl. 03:00 en söndagnatt.

Flexeras State of the Cloud har konsekvent visat att kostnadshantering och migreringskomplexitet är de största utmaningarna för organisationer i molnet. Det stöder vad vi ser i praktiken: företag som försöker migrera enbart med intern kompetens hamnar i genomsnitt flera månader efter sin tidsplan och överskrider budgeten.

Det betyder inte att det interna teamet ska sitta på bänken. Tvärtom – de bästa migreringsprojekten bygger blandade team där konsulterna bidrar med migrationsspecifik erfarenhet och det interna teamet bidrar med verksamhetskännedom.

Molnmigrering

De sex R:en – migreringsstrategier som faktiskt styr beslut

Gartners migrationsramverk med de sex R:en (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) används av de flesta seriösa konsulter som beslutsmodell. Men ramverket är bara användbart om man fyller det med verklig analys.

Rehost ("lift and shift")

Snabbast och billigast kortsiktigt. Flyttar arbetsbelastningen som den är. Fungerar för system som ska avvecklas inom 12–24 månader eller har extremt låg risk.

Replatform

Mindre justeringar – exempelvis att byta från en lokalt installerad databas till en managerad databasinstans (RDS, Cloud SQL, Azure SQL). Ger snabb prestandavinst utan fullständig omskrivning.

Refactor / Re-architect

Omskrivning för molnbaserad arkitektur: containrar, serverless, event-driven design. Dyrt uppströms men ger lägst driftkostnad och högst skalbarhet. Reservera för affärskritiska system med lång förväntad livslängd.

Repurchase

Byt till SaaS. CRM-systemet som körs på en egen server? Ofta billigare och säkrare att gå till en SaaS-lösning med SSO-integrering.

Retire och Retain

Stäng ner det som inte behövs och låt det som inte passar i molnet stanna kvar – åtminstone tills det finns en plan. Att tvinga in en legacy-mainframe i molnet bara för att "allting ska vara i molnet" är sällan en bra idé.

En kvalificerad molnmigreringskonsult hjälper er kategorisera varje arbetsbelastning enligt denna modell och – det som är viktigast – motivera varje beslut ekonomiskt och tekniskt.

Regelefterlevnad: NIS2 och GDPR som arkitekturkriterier

Sedan NIS2-direktivet trädde i kraft ställs skärpta krav på incidentrapportering, riskhantering och leverantörskedjan för organisationer som klassas som väsentliga eller viktiga entiteter. Om ni migrerar till molnet utan att ha mappat era NIS2-skyldigheter mot målarkitekturen riskerar ni att bygga en miljö som inte klarar en tillsynsgranskning.

Konkret innebär det:

• Dataresidenskrav: Personuppgifter och känsliga verksamhetsdata måste kunna isoleras geografiskt. AWS eu-north-1 (Stockholm) och Azure Sweden Central är naturliga val, men ni behöver verifiera att alla tjänster (inklusive stödtjänster som loggar och backuper) faktiskt stannar i rätt region.
• Incidentrapportering: NIS2 kräver initial rapportering inom 24 timmar. Er molnmiljö behöver automatiserad detektion och larmkedja som kopplar in SOC från minut ett.
• Leverantörsbedömning: Molnleverantören är en del av er leverantörskedja. GDPR kräver databehandlaravtal (DPA), och NIS2 kräver löpande riskbedömning av kritiska leverantörer.

Integritetsskyddsmyndigheten (IMY) har de senaste åren visat att de inte tvekar att utfärda sanktionsavgifter vid bristande datahantering i molnmiljöer. Regelefterlevnad är inte en checkbox – det är ett arkitekturkriterium.

Molnsäkerhet

FinOps: kostnadshantering som del av migreringen

Enligt Flexeras State of the Cloud-rapporter är molnkostnadshantering den största utmaningen organisationer rapporterar, år efter år. Det är ingen slump – molnets förbrukningsbaserade modell gör det trivialt enkelt att spendera mer än planerat.

En migreringskonsult som inte har FinOps-kompetens levererar bara halva jobbet. Kostnadsoptimering ska byggas in i arkitekturen från start:

• Rightsizing före lansering: Analysera faktisk resursanvändning i on-prem-miljön och dimensionera molnresurser därefter – inte baserat på vad som stod i den ursprungliga beställningen för fem år sedan.
• Reserverade instanser och savings plans: Committed use-rabatter kan minska beräkningskostnader med uppåt 40–60 %, men kräver noggrann planering.
• Tagging-policy: Utan konsekvent tagging kan ni inte allokera kostnader till affärsenheter, och utan kostnadsallokering kan ni inte fatta informerade beslut.
• Automatisk avskalning: Utvecklings- och testmiljöer som körs dygnet runt kostar lika mycket som produktion men levererar noll värde nattetid.

Cloud FinOps

Hur ni väljer rätt migrationspartner

Marknaden svämmar inte direkt över av dåliga konsulter – den svämmar över av generiska konsulter. Här är vad som skiljer en partner som levererar från en som producerar PowerPoint-presentationer:

Fråga alltid efter en specifik referens från ett likvärdigt migreringsprojekt. Om konsulten inte kan ge det bör ni gå vidare.

Managerade molntjänster

Vad händer efter migreringen?

Migreringsprojektet slutar inte när den sista arbetsbelastningen kör i produktion. De första 90 dagarna efter migrering är kritiska – det är då prestandaproblem, säkerhetsbrister och kostnadsöverraskningar visar sig.

En seriös migrationspartner erbjuder en stabiliseringsperiod med förstärkt övervakning, veckovisa optimeringsgenomgångar och tydlig eskaleringsväg. Opsios SOC/NOC kör 24/7 övervakning just för att problem inte respekterar kontorstider.

Efter stabiliseringsfasen bör fokus skifta till kontinuerlig optimering: nya tjänster från molnleverantören som kan ersätta dyra lösningar, arkitekturförbättringar baserade på faktisk användningsdata och löpande säkerhetsgenomgångar.

Managerad DevOps

Vanliga frågor

Hur lång tid tar en typisk molnmigrering för ett medelstort företag?

Det beror helt på omfattningen, men en organisation med 50–200 arbetsbelastningar bör räkna med 6–18 månader från bedömning till att sista applikationen är migrerad. Kritiska system kräver längre testfaser. Nyckeln är att inte rusa – en välplanerad migrering i vågor ger bättre resultat än big bang.

Vad kostar det att anlita molnmigreringskonsulter?

Kostnaden varierar kraftigt beroende på komplexitet, men en genomsnittlig migrering för ett medelstort företag hamnar ofta mellan 500 000 och 3 miljoner SEK. Det inkluderar bedömning, arkitektur, genomförande och initialt driftstöd. Investeringen betalar sig vanligtvis genom lägre driftkostnader och färre incidenter.

Kan vi migrera till molnet utan extern hjälp?

Tekniskt ja, men det är sällan klokt. Flexeras State of the Cloud visar konsekvent att organisationer underskattar komplexiteten i molnmigreringar. Interna team saknar ofta erfarenhet av storskaliga migreringar, och misstag i arkitekturen kostar mer att åtgärda än att förebygga.

Hur väljer vi rätt molnplattform – AWS, Azure eller Google Cloud?

Valet bör baseras på era specifika arbetsbelastningar, kompetenser i teamet, regulatoriska krav och prissättning. Många svenska företag väljer AWS (eu-north-1 i Stockholm) eller Azure (Sweden Central) för dataresidenskrav. En bra konsult hjälper er göra en objektiv bedömning istället för att sälja en enda plattform.

Hur hanterar vi GDPR och NIS2 vid molnmigrering?

GDPR kräver att ni vet exakt var personuppgifter lagras och bearbetas, att ni har rätt rättslig grund och att databehandlaravtal finns med molnleverantören. NIS2 tillför krav på incidentrapportering inom 24 timmar och riskhantering i leverantörskedjan. Båda regelverken måste vara inbyggda i migrationsarkitekturen, inte påklistrade efteråt.