Tre migreringsstrategier — och när du väljer vilken

Gartner har etablerat sin "7 R"-modell för migreringsstrategier, men i praktiken kokar de flesta beslut ner till tre huvudvägar. Valet bör göras per arbetsbelastning, inte som ett globalt beslut för hela IT-miljön.

Lift-and-shift (rehosting)

Du flyttar befintliga system till molnet utan kodändringar. En virtuell maskin blir en EC2-instans i AWS eu-north-1 eller en VM i Azure Sweden Central. Fördelen är hastighet — en migrering kan vara klar på veckor. Nackdelen är att du betalar molnpriser för en arkitektur som designades för fysisk hårdvara, utan att få molnets autoskalning, managed services eller elasticitet.

När det passar: Datacenteravveckling med hård deadline. Legacy-system som snart ska avvecklas. Arbetsbelastningar med förutsägbar, stabil last.

Opsios erfarenhet: Vi rekommenderar lift-and-shift som steg ett för system som sedan ska optimeras. Att stanna i rehosting-läge permanent är den dyraste långsiktiga strategin.

Replatform (lift-tinker-and-shift)

Du gör riktade justeringar under flytten: byter till en managerad databastjänst (RDS, Azure SQL), lägger till lastbalansering, eller flyttar till containers utan att skriva om applikationslogiken. Investeringen är begränsad, men avkastningen märkbar.

När det passar: Medelstora organisationer som vill ha bättre prestanda och kostnadskontroll utan att starta ett ombyggnadsprojekt. Applikationer med 3–7 års förväntad livslängd.

Opsios erfarenhet: Det här är den strategi vi oftast ser ge bäst förhållande mellan insats och resultat för svenska medelstora företag. En databasmigrering till managed service minskar operativt underhåll omedelbart.

Refactor (rearchitect)

Du bygger om applikationen för att dra full nytta av molnplattformens kapacitet: mikrotjänster, containers i Kubernetes, serverlösa funktioner (Lambda, Azure Functions), event-driven arkitektur. Det är den dyraste och mest tidskrävande vägen, men ger lägst driftskostnad och högst skalbarhet på sikt.

När det passar: Affärskritiska system med lång förväntad livslängd. Applikationer där skalbarhet är en konkurrensfördel. Organisationer med mogen DevOps-kultur.

Strategijämförelse

Migreringsprocessen steg för steg

1. Discovery och inventering

Kartlägg alla arbetsbelastningar, beroenden, dataflöden och licensvillkor. Verktyg som AWS Application Discovery Service eller Azure Migrate ger en utgångspunkt, men räkna med manuellt arbete för att verifiera beroenden som inte syns i nätverkstrafik. Dokumentera vilka system som kommunicerar med varandra — det här steget avslöjar nästan alltid överraskningar.

2. Strategi per arbetsbelastning

Tilldela varje arbetsbelastning en strategi baserat på teknisk komplexitet, affärskritikalitet och framtida roadmap. Inte alla system förtjänar en refactoring — och inte alla klarar en ren lift-and-shift.

3. Landing zone och säkerhetsarkitektur

Bygg en välarkitekterad landningszon innan första arbetsbelastningen flyttas. Det innebär: nätverkstopologi (VPC/VNet-design), IAM-struktur, loggning och övervakning, efterlevnadskontroller och kostnadsbudgetar. AWS Well-Architected Framework och Azure Architecture Center ger solida referensarkitekturer.

För svenska organisationer: konfigurera dataresidenskontroller från start. Det är enormt mycket enklare att göra rätt från början än att flytta data mellan regioner i efterhand.

4. Wave-baserad migrering

Gruppera arbetsbelastningar i vågor (waves) baserat på beroenden och komplexitet. Börja med lågrisk-system för att bygga erfarenhet. Använd insikterna från varje våg för att justera process och verktyg inför nästa.

5. Validering och optimering

Efter varje våg: verifiera funktionalitet, prestanda och säkerhet. Jämför faktisk molnkostnad mot prognos. Här börjar FinOps-arbetet på riktigt — rightsizing av instanser, val av reserverade eller sparplansinstanser, och eliminering av oanvända resurser.

Cloud FinOps med Opsio

Vanliga misstag vi ser i produktion

Underskattad bandbredd vid dataflytt. Att flytta tiotals terabyte tar längre än de flesta räknar med. Överväg AWS Snowball eller Azure Data Box för stora volymer, alternativt dedikerade Direct Connect/ExpressRoute-kopplingar.

Licensfällor. Många programvarulicenser — särskilt Oracle och Microsoft — har villkor som förändras i molnet. En Windows Server-licens som fungerar i ditt datacenter kan kräva en annan licensmodell i AWS. Kartlägg detta i discovery-fasen.

Ingen exitstrategi. Molnmigrering bör inte innebära total leverantörsinlåsning. Dokumentera hur ni kan flytta tillbaka eller till en annan leverantör. Det handlar inte om att ni ska flytta — utan om att ni kan. Det ger förhandlingskraft och minskar strategisk risk.

Driftsmodellen glöms bort. Att flytta till molnet utan att anpassa driftsorganisationen är som att köpa en ny bil och insistera på att tanka den med hästfoder. Incidenthantering, change management och on-call-rutiner behöver designas för en molnvärld med API-driven infrastruktur.

Managerade molntjänster

GDPR, NIS2 och svenska kravbilder

NIS2-direktivet, som gäller sedan oktober 2024, skärper kraven på riskhantering och incidentrapportering för organisationer inom kritisk infrastruktur. Det påverkar direkt hur migreringen planeras: loggning, åtkomstkontroll och förmågan att detektera och rapportera incidenter inom 24 timmar måste byggas in i molnarkitekturen.

GDPR kräver inte datalagring i Sverige, men inom EU/EES (eller med godkänd överföringsmekanism). Integritetsskyddsmyndigheten (IMY) har i tillsynsärenden tydliggjort att molntjänster kräver dokumenterad konsekvensbedömning (DPIA) och tydliga personuppgiftsbiträdesavtal.

Vår rekommendation: behandla regelefterlevnad som en arkitekturfråga, inte som en juridisk efterhandskonstruktion. Det sparar både tid och pengar.

Molnsäkerhet

Att välja migrationspartner

Marknaden svämmar över av konsultbolag som erbjuder molnmigrering. Här är vad som faktiskt skiljer en kompetent partner från en som läst leverantörens snabbkurs:

Verifierad driftserfarenhet. Fråga inte bara om certifieringar — fråga hur många produktionsmiljöer de driver just nu och hur deras incidentprocess ser ut. En partner med 24/7 SOC/NOC har en fundamentalt annan förståelse för migrationsrisker än en som enbart gör projekt.

Erfarenhet av er bransch. Migreringsutmaningarna skiljer sig väsentligt mellan en e-handlare, en kommun och ett fintech-bolag. Branscherfarenhet minskar risken.

Transparens om begränsningar. En seriös partner säger nej till tidsplaner som är orealistiska och identifierar risker tidigt. Om allt låter enkelt i försäljningsfasen — var skeptisk.

FinOps-kompetens inbyggd. Migrering utan kostnadsövervakning leder förutsägbart till budgetöverdrag. Partnern bör ha verifierad FinOps-praxis, inte bara erbjuda det som tillägg.

Molnmigrering med Opsio

Vanliga frågor

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

Tidsramen varierar enormt beroende på strategi och komplexitet. En lift-and-shift av 20–50 servrar kan vara klar på 8–12 veckor. En fullständig refactoring av affärskritiska system tar vanligtvis 6–18 månader. Avgörande är att discovery-fasen (inventering och beroendeanalys) inte kortas ner — det är där de flesta tidsöverskridanden har sin rot.

Vilken molnleverantör passar bäst för svenska företag?

Det beror på befintlig teknikstack och kravbild. AWS har bredast tjänstekatalog och eu-north-1 (Stockholm) som region. Azure integreras naturligt med Microsoft 365-miljöer och erbjuder Sweden Central. Google Cloud är starkt inom data och AI. Många organisationer landar i en multicloud-strategi — men det kräver mognare drift.

Vad kostar molnmigrering?

Kostnaden beror på antal arbetsbelastningar, vald strategi och hur mycket omstrukturering som krävs. Räkna med att discovery och planering utgör 15–25 % av totalbudgeten. Det vanligaste misstaget är att underbudgetera just den fasen, vilket leder till dyrare korrigeringar senare.

Måste vi lagra data i Sverige för att uppfylla GDPR?

GDPR kräver inte datalagring i Sverige, men inom EU/EES. Dock ställer vissa branschregelverk och myndighetskrav (exempelvis inom vård och offentlig sektor) strängare krav på dataresiden. NIS2-direktivet skärper dessutom kraven på riskhantering och incidentrapportering. Kartlägg era specifika krav innan ni väljer region.

Kan vi migrera stegvis eller måste allt flyttas samtidigt?

Stegvis migrering (en så kallad wave-baserad approach) är nästan alltid att rekommendera. Det minskar risken, ger teamet tid att lära sig plattformen och gör det möjligt att justera strategin baserat på verkliga erfarenheter från de första arbetsbelastningarna.

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