Replatforming i kontext: de 6 R:en

AWS populariserade modellen med "6 R" för molnmigrering, och den har blivit branschstandard. Replatforming kallas ibland "lift-tinker-and-shift" — vilket faktiskt beskriver det bättre än många formella definitioner.

Det viktiga att förstå: du behöver inte välja en strategi för hela portföljen. I praktiken tillämpar de flesta organisationer vi arbetar med en mix — kanske 30 % rehost, 40 % replatform och 20 % refaktorering, med resten fördelat på retire/retain. Replatforming fungerar bäst som standardvalet för applikationer som har ett tydligt fortsatt affärsvärde men inte motiverar en total omskrivning.

Varför replatforming slår lift-and-shift i driftskostnad

Lift-and-shift är snabbt och billigt att genomföra, men det löser inga underliggande problem. Vi ser det regelbundet i Opsios NOC: organisationer som har gjort en ren lift-and-shift och sedan undrar varför molnräkningen är högre än den gamla hostingkostnaden.

Anledningen är enkel. En applikation som designades för att köras på en dedikerad server med fast kapacitet vet inte hur den ska bete sig i en elastisk miljö. Den allokerar resurser statiskt, skapar inte health checks, och databasen körs på samma instans som applikationsservern.

Replatforming adresserar precis dessa problem:

Managerade tjänster minskar operativ overhead

Varje självhanterad databas, meddelandekö eller cachingserver kräver patching, övervakning, backup-verifiering och kapacitetsplanering. Enligt Flexeras State of the Cloud-rapporter är kostnadshantering konsekvent den största utmaningen för molnorganisationer — och en stor del av det onödiga slöseriet härstammar från övertung infrastruktur som kunde ersatts av managerade tjänster.

När du byter en självhanterad PostgreSQL-installation mot Amazon RDS eller Azure Database for PostgreSQL försvinner inte bara driftsarbetet — du får automatiska backups, replikering, point-in-time recovery och automatisk failover utan att skriva en rad driftkod.

Automatisk skalning kräver minimal anpassning

De flesta applikationer kan göras skalningsbara med relativt små ändringar: externalisera sessionshantering (flytta till Redis/ElastiCache), se till att fillagring använder objektlagring (S3/Azure Blob) istället för lokal disk, och konfigurera health check-endpoints. Dessa ändringar är typiska replatforming-insatser som tar dagar, inte månader.

Observerbarhet blir inbyggd

Genom att integrera med molnplattformens loggning och metrikhantering (CloudWatch, Azure Monitor, Cloud Logging) redan vid replatforming slipper du bygga observerbarhet i efterhand — något som alltid blir dyrare och svårare.

Praktisk strategi: fem steg för lyckad replatforming

Baserat på vad vi har sett fungera (och misslyckas) i praktiken:

1. Inventera och kartlägg beroenden

Du kan inte replatforma det du inte förstår. Använd verktyg som AWS Application Discovery Service, Azure Migrate eller manuell kartläggning för att dokumentera:

• Alla applikationskomponenter och deras versioner
• Nätverkskommunikation (vilka portar, protokoll, volymer)
• Databeroenden och delad data
• Externa integrationspunkter

Denna fas underskattas nästan alltid. Vi har sett replatforming-projekt försenas med månader för att ett okänt beroende dök upp sent i processen.

2. Definiera mål och baslinje

Mät före du gör något. Svarstider, felfrekvens, driftskostnad per transaktion, time-to-deploy. Utan baslinje kan du inte bevisa att replatformingen faktiskt förbättrade något.

Definiera specifika mål: "Minska databasrelaterade driftsincidenter med 80 %", "Halvera deploy-cykeln", "Sänk infrastrukturkostnaden med 30 % inom 12 månader". Vaga mål som "modernisera" är meningslösa.

3. Välj rätt kandidater

Inte alla applikationer bör replatformas. En enkel statisk webbplats kan bara rehostas. En monolitisk applikation med 15 års teknisk skuld kanske behöver refaktoreras — eller avvecklas. Replatforming ger bäst utdelning för applikationer som:

• Har en sund kodbas men föråldrad infrastruktur
• Använder databaser eller middleware som har managerade molnmotsvarigheter
• Har förutsägbara men varierande belastningsmönster som gynnas av autoskalning
• Ska leva vidare i minst 3–5 år

4. Genomför i avgränsade faser

Byt en komponent i taget. Databasmigrering först, sedan sessionshantering, sedan fillagring. Varje fas bör ha sin egen testcykel och rollback-plan. Molnmigrering

5. Validera och optimera

Efter varje fas: jämför med baslinjen. Fungerar autoskalningen? Sjönk felfrekvensen? Är kostnaden rimlig? Justera instansstorlekar, reservationsmodeller och skalningströsklar. Cloud FinOps

Vanliga misstag vi ser i praktiken

Från Opsios perspektiv — vi hanterar drift dygnet runt för organisationer som har genomfört (eller påbörjat) molnmodernisering — finns det tydliga mönster i vad som går snett:

Underestimering av databasmigrering. Att flytta schemat är det enkla. Datamigration med minimal nedtid, hantering av replikering under övergången och validering av data-integritet efteråt är det svåra. Planera alltid för att databasmigrering tar dubbelt så lång tid som du tror.

Ignorera säkerhetsmodellen. On-prem-applikationer förlitar sig ofta på nätverksperimeter-säkerhet. I molnet behöver du IAM-roller, säkerhetsgrupper, kryptering i transit och at rest, samt hantering av hemligheter via Secrets Manager eller Key Vault. Replatforming är rätt tillfälle att bygga in detta — inte efteråt. Molnsäkerhet

Ingen rollback-plan. Vi har sett organisationer som kört igång produktion på den replatformade versionen utan att ha testat återställning. Om databasmigreringen till RDS visar sig ha problem dag tre i produktion, vad gör du? Planera för det.

Bristande kompetensöverföring. Driftsteamet som ska hantera den replatformade applikationen måste förstå de nya komponenterna. En managerad databas kräver annan felsökningskompetens än en självhanterad. Investera i utbildning parallellt med migreringen.

Replatforming som språngbräda

Ett perspektiv som ofta förbises: replatforming är inte slutdestinationen. Det är ett pragmatiskt mellansteg som ger omedelbart värde och förbereder för djupare modernisering.

En applikation som har replatformats till managerade tjänster, med externaliserad sessionshantering och korrekt health checks, är enormt mycket enklare att containerisera i nästa steg. Och en containeriserad applikation är i sin tur enklare att bryta upp i mikrotjänster om och när affärsbehovet motiverar det.

Denna stegvisa approach — replatform nu, containerisera nästa kvartal, mikrotjänster där det ger värde — är vad vi på Opsio rekommenderar framför "big bang"-modernisering. Den minskar risk, sprider kostnad och ger mätbart värde längs hela vägen. Managerade molntjänster

Regulatoriska aspekter för svenska organisationer

Om du kör arbetsbelastningar som lyder under GDPR eller NIS2-direktivet — vilket de flesta svenska organisationer gör — påverkar replatforming din compliance-situation. Att flytta en databas till en managerad tjänst i eu-north-1 (Stockholm) eller Sweden Central är generellt positivt ur datalokaliseringsperspektiv, men du behöver:

• Verifiera att managerade tjänster stöder kryptering med kundhanterade nycklar om det krävs
• Säkerställa att loggar och backups stannar inom godkänd geografi
• Uppdatera databehandlingsavtal och registerförteckning (artikel 30, GDPR)
• Genomföra en konsekvensanalys om personuppgiftsbehandlingen förändras väsentligt

Managerad DevOps

Vanliga frågor

Vad är skillnaden mellan replatforming och rehosting?

Rehosting (lift-and-shift) flyttar applikationen oförändrad till molnet. Replatforming gör riktade modifieringar — exempelvis byte till en managerad databas eller uppdatering av runtime — för att dra nytta av molnets egenskaper. Replatforming kräver mer arbete men ger bättre prestanda, lägre driftskostnad och en starkare grund för framtida modernisering.

Vilka applikationer lämpar sig bäst för replatforming?

Applikationer som fungerar väl i grunden men är bundna till föråldrad infrastruktur — exempelvis en Java-app på en gammal applikationsserver som kan flyttas till en modern container-runtime, eller en SQL Server-databas som kan migreras till en managerad tjänst. Applikationer med extremt tätt kopplad arkitektur kan behöva refaktorering istället.

Hur lång tid tar ett typiskt replatforming-projekt?

Det beror på applikationens komplexitet och beroenden. En medelstor applikation med välkänd arkitektur tar typiskt 6–14 veckor inklusive testning. Komplexa legacy-system med många integrationer kan kräva 3–6 månader. En noggrann discovery-fas kortar ofta den totala tidslinjen.

Är replatforming dyrare än lift-and-shift?

Initialt ja — du investerar mer i migrationsfasen. Men den löpande driftskostnaden blir nästan alltid lägre tack vare managerade tjänster, bättre resursutnyttjande och automatiserad skalning. Enligt vår erfarenhet betalar sig merinsatsen tillbaka inom 6–12 månader.

Kan vi göra replatforming stegvis?

Absolut, och det rekommenderar vi. Börja med en eller två applikationer med tydligt affärsvärde och hanterbara beroenden. Använd lärdomarna för att bygga en repeterbar process innan du skalar upp. Detta minskar risk och bygger intern kompetens.