De sex migreringsstrategierna – och när de faktiskt fungerar

Branschen talar ofta om "de 6 R:en", ett ramverk som ursprungligen populariserades av Gartner och sedan vidareutvecklats i bland annat AWS:s dokumentation. Verkligheten är att de flesta migreringar använder en kombination, inte en enda strategi.

Rehosting (lift-and-shift)

Ni tar era befintliga servrar och replikerar dem som virtuella maskiner i molnet – ingen kodändring, ingen arkitekturomställning. Det är den snabbaste vägen och fungerar utmärkt när målet är att stänga ett datacenter mot en hård deadline.

Opsio-perspektiv: Vi ser regelbundet att organisationer som stannar vid rehosting utan plan för nästa steg betalar mer i molnet än de gjorde on-premise. En Windows-server som dimensionerades för toppbelastning 2019 körs dygnet runt som en överdimensionerad instans i molnet. Rehosting är ett legitimt första steg – inte slutdestinationen.

Replatforming

Mindre justeringar under flytten: byt ut en lokal SQL Server mot en managerad databastjänst (RDS, Azure SQL Managed Instance, Cloud SQL), men behåll applikationskoden i stort sett oförändrad. Ni får automatisk backup, patchning och skalning utan full omskrivning.

Det här är den strategi som ofta ger bäst avkastning per investerad krona. Insatsen är måttlig, men vinsten i minskad driftsbelastning är betydande.

Refactoring

Applikationen skrivs om, helt eller delvis, för att dra nytta av molnets tjänster: containrar i Kubernetes, serverlösa funktioner (Lambda, Azure Functions), händelsedriven arkitektur. Långsiktigt den starkaste strategin – men också den dyraste och mest resurskrävande.

Refactoring bör reserveras för system med hög affärskritiskhet och lång förväntad livslängd. Att skriva om ett internt rapporteringsverktyg som sex personer använder är sällan motiverat.

Retire och Retain

Ofta förbisedda men avgörande: Retire innebär att ni identifierar system som helt enkelt inte behövs längre. Varje avvecklat system är en eliminerad attackyta och en rad borttagen från driftsbudgeten. Retain innebär att systemet medvetet stannar on-premise – latenskrav, licensmodeller eller regulatoriska hinder kan göra det till rätt val.

Steg-för-steg: så genomför ni migreringen

Steg 1: Inventering och beroendeanalys

Det här steget underskattas systematiskt. Ni behöver en komplett karta över servrar, applikationer, databaser, integrationspunkter och – kritiskt – beroenden mellan dem. Vilka system pratar med vilka? Vilka databaser delar data? Vilka API:er anropas synkront under kontorstid?

Verktyg som AWS Migration Hub, Azure Migrate och open source-alternativ som Cloudamize automatiserar delar av upptäckten. Men vår erfarenhet från Opsios NOC är att automatiska verktyg missar 20–40 % av de faktiska beroendena – de som bara finns dokumenterade i en utvecklares huvud eller i en gammal Wiki-sida som ingen uppdaterat sedan 2021.

Praktiskt tips: Kör nätverksflödesanalys (NetFlow/VPC Flow Logs) i minst 30 dagar innan ni börjar planera vågor. Trafikmönster avslöjar beroenden som ingen minns.

Steg 2: Prioritering och vågindelning

Dela in migreringen i tre till fem vågor. Första vågen ska vara en pilot: system med få beroenden, tydlig ägare och låg affärskritiskhet. Syftet är inte att flytta volym – det är att bygga processkunskap och identifiera friktionspunkter i er CI/CD-pipeline, nätverksarkitektur och change management.

Varje våg avslutas med en formell utvärdering:

• Stämde kostnadsberäkningen?
• Höll tidsplanen?
• Uppstod incidenter som indikerar process- eller kompetensbrister?
• Behöver nätverkstopologin justeras inför nästa våg?

Steg 3: Pilotering och validering

Migrera en eller två applikationer som fullständig pilot. Mät prestanda, kostnad och användarupplevelse under minst två veckor i produktion innan ni fattar beslut om nästa våg. Jämför med baslinjen från on-premise – inte med förhoppningar.

I den här fasen bör ni också verifiera att er Molnsäkerhet konfiguration fungerar i praktiken: brandväggsregler, kryptering i transit och vila, IAM-roller och loggning till ert SIEM.

Steg 4: Fullskalig migrering

Med piloterfarenhet och validerade processer ökar ni tempot. Parallella vågor är möjliga om ni har tillräcklig bemanning och tydlig ansvarsfördelning. Här är det avgörande att ha en etablerad eskaleringsprocess – saker kommer att gå fel, och snabb respons skiljer ett lyckat projekt från ett krisläge.

Steg 5: Optimering och nedstängning

Efter flytten börjar det verkliga arbetet. Rätt-dimensionera instanser, implementera auto-scaling, granska reserverade instanser kontra on-demand, och sätt upp taggningspolicyer för kostnadsallokering. Det är här Cloud FinOps levererar mest värde.

Stäng ned det gamla datacentret eller avveckla era colocations-avtal först efter att alla arbetsbelastningar validerats i produktion under minst 30 dagar.

NIS2 och regelefterlevnad under migrering

NIS2-direktivet påverkar svenska organisationer inom väsentliga och viktiga sektorer – energi, transport, hälso- och sjukvård, digital infrastruktur och en rad andra. Under en migrering är flera NIS2-krav direkt relevanta:

• Riskhantering: Ni måste dokumentera riskbedömning för molnmiljön, inklusive leverantörsberoende och dataflöden över gränser.
• Incidentrapportering: Under dubbelkörning (on-premise och moln parallellt) behöver ni incidentprocesser som täcker båda miljöerna.
• Leverantörskedjegranskning: Molnleverantören är en del av er leverantörskedja. Due diligence på deras säkerhetspraxis, certifieringar (SOC 2, ISO 27001) och databehandlingsavtal krävs.

GDPR-kraven kvarstår naturligtvis. Personuppgifter som lagras i molnet kräver giltiga databehandlingsavtal, och om ni använder regioner utanför EU/EES behöver ni adressera Schrems II-implikationerna. Stockholmsregionen (eu-north-1 för AWS, Sweden Central för Azure) är det naturliga valet för att minimera den komplexiteten.

Vanliga misstag vi ser i produktion

Från Opsios SOC/NOC har vi observerat samma mönster hundratals gånger:

1. Ingen kostnadsstyrning från start. Organisationen migrerar utan taggningspolicy, budgetlarm eller kostnadsansvarig. Tre månader in kommer fakturan – och den är betydligt högre än prognosen. Inför Cloud FinOps innan första arbetsbelastningen går live.

2. Säkerhetskonfiguration som eftertanke. Publika S3-buckets, överprivilegierade IAM-roller, avsaknad av kryptering på databasvolymer. Det låter grundläggande – och det är det – men det inträffar i projekt efter projekt.

3. Underskattade nätverkskostnader. Egress-avgifter (datatrafik ut från molnet) är en av de mest förbisedda kostnadsposterna. Om er arkitektur kräver stora dataöverföringar mellan moln och on-premise, eller mellan regioner, kan nätverkskostnaden bli en betydande del av totalnotan.

4. Brist på rollback-plan. Om migreringen av ett system misslyckas – hur snabbt kan ni gå tillbaka? Utan testad rollback riskerar ni driftstopp som påverkar verksamheten.

När en managerad tjänsteleverantör gör skillnad

Alla organisationer behöver inte en MSP för sin Molnmigrering. Om ni har ett moget molnteam med erfarenhet från tidigare migreringar, väletablerade DevOps-processer och tid att driva projektet – kör själva.

Men om något av följande stämmer bör ni överväga extern hjälp:

• Ert team har begränsad erfarenhet av storskalig molnmigrering
• Ni har en hård deadline (datacenter-avveckling, kontraktsslut)
• Regelverkskraven (NIS2, GDPR) kräver kompetens ni inte har internt
• Ni behöver 24/7 driftsövervakning under och efter migreringen

Det Opsio tillför är inte bara teknisk kompetens – det är driftserfarenhet. Vi vet vad som går fel klockan 03:00 en söndag, för vi har sett det hända. Vårt SOC/NOC i Karlstad och Bangalore ger kontinuerlig övervakning som de flesta organisationer inte kan eller vill bygga upp internt.

Vanliga frågor

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

Räkna med 6–18 månader från inventering till att de sista arbetsbelastningarna är i produktion. Enklare lift-and-shift-projekt kan gå på veckor per applikation, medan refactoring av affärskritiska system tar månader. Den vanligaste fällan är att underskatta beroendeanalys – det är där tiden faktiskt äts upp.

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

AWS (eu-north-1 i Stockholm), Azure (Sweden Central) och Google Cloud har alla svensk eller nordisk närvaro. Valet styrs av era befintliga kompetenser, licensavtal och specifika tjänstebehov snarare än av generella rankningar. Många organisationer landar i en multicloud-strategi – ofta oavsiktligt via förvärv eller skugg-IT.

Hur påverkar NIS2 vår molnmigrering?

NIS2-direktivet kräver att organisationer inom väsentliga och viktiga sektorer har dokumenterad riskhantering för IT-infrastruktur, inklusive molnmiljöer. Det innebär krav på incidentrapportering, leverantörskedjegranskning och kontinuitetsplanering – allt som direkt påverkar hur ni utformar er migreringsstrategi.

Vad kostar det att migrera till molnet?

Själva migreringskostnaden – verktyg, konsulttid, dubbelkörning – är ofta 15–30 % av första årets molnkostnad. Den riktiga risken är dock löpande driftskostnad som skenar. Inför FinOps-rutiner från dag ett: taggning, budgetlarm och regelbundna kostnadsgranskningar.

Kan vi behålla vissa system on-premise?

Absolut – och i många fall bör ni det. System med extremt låga latenskrav, äldre mainframe-applikationer eller arbetsbelastningar med olösta regulatoriska frågor är kandidater för "retain". Hybridarkitektur med säkra förbindelser (AWS Direct Connect, Azure ExpressRoute) är en fullt mogen modell som vi driftar åt flera kunder.

For hands-on delivery in India, see managed azure managed.

For hands-on delivery in India, see managed disaster recovery.