6R-modellen: välj rätt strategi per arbetsbelastning

Det finns inte en migreringsstrategi – det finns minst sex, och de flesta företag behöver en kombination. AWS populariserade 6R-modellen, och den har blivit branschstandard av goda skäl:

Det vanligaste misstaget vi ser är att företag kör lift-and-shift på allt och sedan undrar varför molnkostnaderna överstiger den gamla serverhallens prislapp. Lift-and-shift är ett utmärkt första steg för att lämna ett datacenter snabbt – men det är ingen slutstation. Utan en plan för efterföljande optimering (replatforming eller refactoring) betalar ni premiumpriser för molnresurser ni inte utnyttjar.

Molnmigrering

Kostnadsverkligheten: varför besparingarna inte kommer automatiskt

Flexeras State of the Cloud-rapporter har år efter år visat att kostnadsoptimering är den absolut högst prioriterade molnutmaningen för organisationer. Det är ingen tillfällighet. Molnet kan vara billigare – men det kräver aktiv styrning.

Tre vanliga kostnadsfällor

1. Överdimensionerade instanser. Företag som migrerar från fasta servrar tenderar att välja instanstyper som matchar den gamla hårdvaran. Problemet? Den gamla hårdvaran var också överdimensionerad – den köptes med marginal för att hålla i fem år. I molnet betalar ni per timme för kapacitet ni inte använder.

2. Glömda resurser. Testmiljöer som aldrig stängs av, snapshots som ackumuleras, load balancers utan trafik. I Opsios FinOps-granskningar hittar vi konsekvent outnyttjade resurser som genererar onödiga kostnader varje månad.

3. Dataöverföringskostnader. Egress-avgifter är molnleverantörernas dolda intäktskälla. Arkitektur som skickar stora datamängder mellan regioner eller ut från molnet kan generera förvånansvärt höga kostnader.

Cloud FinOps

Så bygger ni en realistisk kostnadsmodell

Innan migreringen ska ni ha en TCO-analys (Total Cost of Ownership) som inkluderar:

• Beräkningskostnader – instanser, containrar, serverless-exekvering
• Lagring – block, objekt, arkiv, snapshots
• Nätverk – egress, VPN/interconnect, CDN
• Licenser – särskilt Microsoft-licenser som kan bli dyrare i molnet (BYOL vs. inkluderade licenser)
• Driftkompetens – behöver ni anställa, utbilda eller outsourca?
• Migrationskostnaden – projektledning, testning, parallellkörning

Utan den analysen är varje besparingsuppskattning gissning.

Säkerhet och regelefterlevnad: designa in det från start

Delat ansvar – en modell som fortfarande missförstås

Alla tre stora molnleverantörer (AWS, Azure, GCP) arbetar med modellen delat ansvar: leverantören ansvarar för säkerheten av molnet (fysiska datacenter, hypervisor, nätverk), medan kunden ansvarar för säkerheten i molnet (konfiguration, åtkomstkontroll, kryptering, dataklassificering).

I Opsios SOC ser vi att majoriteten av säkerhetsincidenter i molnmiljöer beror på felkonfigurationer – öppna S3-buckets, alltför generösa IAM-policyer, avsaknad av MFA. Inget av detta är leverantörens ansvar.

GDPR och NIS2 i migreringsplanen

För svenska företag tillkommer regulatoriska dimensioner som måste adresseras innan migreringen:

• GDPR: Var lagras personuppgifter? Använder ni EU-regioner (eu-north-1 i AWS, Sweden Central i Azure)? Hur hanteras tredjelandsöverföringar efter Schrems II?
• NIS2-direktivet: Från och med implementeringen ställs skärpta krav på incidentrapportering och riskhantering för väsentliga och viktiga entiteter. Er molnarkitektur måste stödja dessa krav.
• IMY (Integritetsskyddsmyndigheten): Har utfärdat vägledningar som påverkar hur svenska organisationer får använda molntjänster, särskilt gällande dataöverföring till tredjeland.

En seriös migrationspartner tar upp dessa frågor i discovery-fasen, inte som en efterkontroll.

Molnsäkerhet

Vad en managerad tjänsteleverantör (MSP) faktiskt tillför

Det finns en utbredd missuppfattning att en MSP bara är ett annat ord för "outsourcad drift". En kompetent MSP – och här är vi naturligtvis partiska – tillför värde i tre faser:

Före migreringen

• Applikationsinventering och beroendemappning
• Strategi per arbetsbelastning (6R-klassificering)
• TCO-analys och arkitekturdesign
• Regelefterlevnadsanalys

Under migreringen

• Vågplanering och genomförande
• Parallellkörning och testning
• Cutover-hantering med definierade rollback-planer
• 24/7-stöd under kritiska migreringsfönster

Efter migreringen

• Kontinuerlig övervakning via SOC/NOC
• Kostnadsoptimering (FinOps)
• Incidenthantering och problemlösning
• Kapacitetsplanering och arkitekturutveckling

Den sista fasen – efter migreringen – är där de flesta interna team tappar momentum. Flytten är klar, projektet avslutas, och den löpande optimeringen faller mellan stolarna. Det är precis där en MSP med 24/7-drift gör störst skillnad.

Managerade molntjänster

Migreringens vanligaste misstag – och hur ni undviker dem

Bristfällig discovery. Ni kan inte migrera det ni inte förstår. Investera tid i att kartlägga alla beroenden, inklusive de inofficiella integrationer som aldrig dokumenterats.

Avsaknad av rollback-plan. Varje migreringsvåg behöver en dokumenterad plan B. "Vi löser det om det händer" är inte en plan.

Underskattad kompetenslucka. Molndrift kräver annan kompetens än traditionell serverdrift. Antingen investerar ni i utbildning eller tar in en partner – men gapet måste adresseras.

Ignorerad nätverksarkitektur. Latens, bandbredd och DNS-hantering är tråkiga ämnen som orsakar spektakulära driftstörningar om de inte planeras ordentligt.

Ingen FinOps-process. Utan kontinuerlig kostnadsuppföljning från dag ett normaliseras slöseri snabbt. Sätt upp budgetlarm och reservationsstrategier innan arbetsbelastningarna går live.

Så ser en realistisk migreringsplan ut

En typisk molnmigrering för ett medelstort svenskt företag följer ungefär denna tidslinje:

Tiderna varierar kraftigt beroende på portföljens storlek och komplexitet, men principen är densamma: börja smått, lär er snabbt, skala metodiskt.

Managerad DevOps

Vanliga frågor

Hur lång tid tar en molnmigrering?

Det varierar enormt beroende på komplexitet. En enkel lift-and-shift av ett tiotal servrar kan ta 4–8 veckor, medan en fullständig migrering av en komplex applikationsportfölj med refaktorisering kan sträcka sig över 12–18 månader. Den kritiska faktorn är inte teknisk hastighet utan kvaliteten på förarbetet: inventering, beroendemappning och riskanalys.

Vad kostar molnmigrering?

Migrationskostnaden består av tre delar: konsulttid och projektledning, eventuella licensändringar samt den löpande driftkostnaden i molnet. Många företag underskattar den tredje delen. En seriös MSP börjar alltid med en kostnadsanalys och TCO-jämförelse innan första arbetsbelastningen flyttas.

Är molnet säkrare än vår egen serverhall?

Molnleverantörer som AWS, Azure och GCP investerar mångmiljardbelopp i fysisk och logisk säkerhet – långt mer än de flesta enskilda företag kan. Men säkerhet i molnet är ett delat ansvar: leverantören skyddar infrastrukturen, medan ni ansvarar för konfiguration, åtkomstkontroll och data. Felkonfigurerade miljöer är den vanligaste orsaken till incidenter.

Vilken molnleverantör ska vi välja?

Det beror på er applikationsportfölj, kompetensprofil och regulatoriska krav. AWS har bredast tjänsteutbud, Azure integreras bäst med Microsoft-ekosystemet och GCP utmärker sig inom data och AI. Många svenska företag kör multi-cloud. En leverantörsoberoende MSP kan hjälpa er att göra ett faktabaserat val.

Måste vi migrera allt på en gång?

Nej, och det bör ni inte heller göra. De flesta lyckade migreringar följer en vågbaserad modell där man börjar med mindre kritiska arbetsbelastningar, lär sig av erfarenheterna och successivt flyttar mer komplexa system. Vissa äldre system kan dessutom vara mer kostnadseffektiva att behålla on-premise eller avveckla helt.

For hands-on delivery in India, see konsult consulting for enterprise.