Hyperscalarnas egna migreringsverktyg

AWS: Application Migration Service (MGN)

AWS MGN är det enda officiella verktyget för lift-and-shift-migrering till AWS sedan SMS och CloudEndure fasades ut. Det fungerar genom att installera en lättviktig replikeringsagent på källservrarna som kontinuerligt replikerar data till eu-north-1 (Stockholm) eller valfri region.

Vad det gör bra: Agentbaserad blockreplikering med låg bandbreddsförbrukning, automatiserade lanseringsmallar, inbyggd testfunktion där du kan starta testinstanser utan att påverka produktionen, och stöd för cutover med minimal driftstörning.

Var det brister: MGN hanterar servrar, inte applikationer. Det förstår inte beroenden mellan system. Du behöver AWS Application Discovery Service eller ett tredjepartsverktyg för att kartlägga hur dina applikationer faktiskt hänger ihop innan du börjar flytta.

Opsio-perspektiv: Vi ser regelbundet kunder som hoppar över discovery-fasen och börjar replikera direkt. Det fungerar tekniskt, men leder till kaotiska cutover-helger där ingen vet i vilken ordning servrarna ska slås om. Investera tiden i bedömning först.

Azure: Azure Migrate

Azure Migrate är Microsofts hub för alla migreringsaktiviteter och har mognat betydligt. Det samlar bedömning, servermigrering, databasmigrering och webbappsmigrering under ett paraply.

Vad det gör bra: Agentlös discovery av VMware-miljöer (ingen installation krävs på varje VM), beroendeanalys med visualisering, kostnadsuppskattning mot Azure-prislistan, och inbyggd integration med Azure Database Migration Service.

Var det brister: Agentlös replikering fungerar bara för VMware. Hyper-V och fysiska servrar kräver agenter. Beroendeanalysen behöver ofta Log Analytics-agenten för att ge verkligt värde, vilket ökar komplexiteten.

Opsio-perspektiv: Azure Migrate är det bästa bedömningsverktyget av de tre hyperscalarna, även om slutdestinationen inte är Azure. Vi använder det ibland enbart för att ta fram en inventering och beroendeanalys som sedan ligger till grund för en multicloud-strategi.

Google Cloud: Migrate to Virtual Machines

Google Clouds migreringstjänst har genomgått flera namnbyten. Det som idag heter Migrate to Virtual Machines hanterar flytt av VM-arbetsbelastningar från VMware, AWS och Azure till Google Compute Engine.

Vad det gör bra: Stödjer migrering direkt från andra molnleverantörer (inte bara on-prem), erbjuder strömmande migrering som minimerar driftstörning, och integrerar med Fit Assessment för att bedöma VM-kompatibilitet.

Var det brister: Mindre mogen ekosystemintegration jämfört med AWS MGN och Azure Migrate. Dokumentationen antar ofta att du redan är bekant med Google Clouds nätverksmodell, vilket skapar en brantare inlärningskurva.

Jämförelse: Hyperscalarnas migreringsverktyg

Databasmigreringsverktyg — en egen kategori

Databasmigrering förtjänar separat behandling. Att flytta en SQL Server-databas är fundamentalt annorlunda från att flytta en VM. Schemakonvertering, datatypsinkompatibiliteter och replikeringsfördröjning kräver specialiserade verktyg.

AWS Database Migration Service (DMS) med Schema Conversion Tool hanterar både homogena (Oracle → Oracle) och heterogena (Oracle → Aurora PostgreSQL) migreringar. DMS stödjer kontinuerlig replikering, vilket möjliggör near-zero-downtime-cutover.

Azure Database Migration Service har liknande funktionalitet och är särskilt stark för SQL Server-migreringar av uppenbara skäl — Microsoft kontrollerar båda ändarna.

Google Database Migration Service fokuserar på PostgreSQL, MySQL och SQL Server till Cloud SQL eller AlloyDB.

Opsio-perspektiv: Heterogena databasmigreringar (byta databasmotor under flytten) är den vanligaste orsaken till att migreringstidplaner spricker. Räkna med 2–3× längre tid än för homogena migreringar och budgetera för applikationstestning efter flytten. Molnmigrering

Tredjepartsverktyg: När behövs de?

Hyperscalarnas verktyg är gratis och täcker huvuddelen av behoven. Men det finns scenarier där tredjepartsverktyg tillför verkligt värde:

Stora och komplexa migreringar (1 000+ servrar)

Verktyg som Flexera One (tidigare RightScale) och Lakeside SysTrack erbjuder djupare analyser av applikationsportföljer och kan automatisera rationaliseringsbeslut (behålla, flytta, modernisera, avveckla). Flexeras State of the Cloud-rapport har konsekvent visat att kostnadshantering och rätt dimensionering är organisationers största molnutmaningar — och det börjar redan vid migreringen.

Hybridmoln och multicloud-strategier

Zerto (nu en del av HPE) erbjuder plattformsoberoende replikering som fungerar lika bra för migrering som för disaster recovery. Om din strategi innebär att arbetsbelastningar ska kunna flyttas mellan molnleverantörer är det värt att utvärdera.

Containerisering och applikationsmodernisering

Om målet inte är lift-and-shift utan faktisk modernisering, titta på AWS App2Container, Azure Migrate: App Containerization och Migrate to Containers (GCP). Dessa verktyg analyserar befintliga applikationer och genererar container-images och Kubernetes-manifest. Managerad DevOps

Bedömningsfasen: Där migreringar vinns eller förloras

Vi kan inte betona detta tillräckligt. I Opsios SOC/NOC ser vi efterdyningarna av migreringar som hoppade över bedömningsfasen. Symptomen är förutsägbara: felaktigt dimensionerade instanser (oftast överdimensionerade med 40–60 %), okartlagda beroenden som ger oväntade avbrott vid cutover, och säkerhetsluckor där brandväggsregler inte översatts korrekt till molnets säkerhetsgrupper.

En gedigen bedömning innehåller:

1. Inventering — Vilka servrar, databaser, applikationer och mellanprogram finns?

2. Beroendeanalys — Vad pratar med vad, på vilka portar, med vilken frekvens?

3. Rationaliseringsbeslut — De sju R:en (Rehost, Replatform, Refactor, Repurchase, Retain, Retire, Relocate) för varje arbetsbelastning

4. Kostnadsprojektion — Vad kostar det att driva detta i molnet med realistiska antaganden?

5. Säkerhets- och regelefterlevnadskrav — NIS2, GDPR-artikel 28 (databehandlaravtal), eventuella sektorsspecifika krav

Cloud FinOps

Säkerhet och regelefterlevnad under migreringen

Migreringen i sig skapar en attackyta. Data replikeras över nätverk, tillfälliga konton skapas, brandväggsregler öppnas för replikeringstrafik. NIS2-direktivet ställer explicita krav på riskhantering under förändringar — en molnmigrering är en av de största förändringar en IT-organisation genomför.

Konkreta åtgärder:

• Kryptera all replikeringstrafik — AWS MGN, Azure Migrate och GCP Migrate gör detta som standard, men verifiera att konfigurationen är korrekt
• Använd dedikerade migreringskontor med tidsbegränsade behörigheter — inte administrativa root-/ägarkonton
• Dokumentera alla ändringar — IMY och sektorsmyndigheter förväntar sig spårbarhet
• Testa säkerhetskonfigurationen i målmiljön före cutover — inte efter

Molnsäkerhet

Så planerar du verktygsvalet

Verktygsvalet bör följa en enkel logik:

1. Definiera målplattform(ar) — AWS, Azure, GCP eller en kombination

2. Inventera källmiljön — VMware, Hyper-V, fysiska servrar, databaser

3. Bestäm migreringsstrategin per arbetsbelastning — lift-and-shift kräver andra verktyg än containerisering

4. Börja med hyperscalarnas egna verktyg — de är gratis och väl integrerade

5. Lägg till tredjepartsverktyg bara där de fyller ett verkligt gap — storskalig portföljanalys, cross-cloud, eller specifika databasscenarier

Om du saknar intern kompetens för bedömnings- och planeringsfasen är det där en managerad tjänsteleverantör tillför mest värde — inte i att trycka på startknappen i migreringsverktyget. Managerade molntjänster

Vanliga frågor

Vilket migreringsverktyg ska jag välja om vi kör blandad miljö med både AWS och Azure?

Börja med respektive leverantörs eget bedömningsverktyg — Azure Migrate och AWS Application Discovery Service. De kostar inget extra och ger en solid bild av din arbetsbelastning. För själva flytten använder du sedan leverantörens migreringsverktyg för respektive målplattform. Tredjepartslösningar som Zerto eller Carbonite behövs främst vid komplexa databas- eller SAP-migreringar.

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

Det beror på komplexiteten, men en migration av 50–200 servrar tar normalt 3–9 månader inklusive bedömning, pilotfas och produktionsflyttning. Den vanligaste orsaken till förseningar är bristfällig inventering i bedömningsfasen, inte teknikproblem. Räkna med minst 4–6 veckor enbart för discovery.

Är CloudEndure Migration fortfarande relevant?

Nej. AWS fasade ut CloudEndure Migration i slutet av 2024 till förmån för AWS Application Migration Service (AWS MGN). Om du har dokumentation eller planer som refererar till CloudEndure bör du uppdatera dem. AWS MGN erbjuder samma kärnfunktionalitet med bättre integration i AWS-ekosystemet.

Behöver vi ett migreringsverktyg om vi bara ska flytta några databaser?

För databasmigrering är dedikerade tjänster bättre än generella migreringsverktyg. AWS Database Migration Service (DMS), Azure Database Migration Service och Google Database Migration Service hanterar schema-konvertering, kontinuerlig replikering och validering. De klarar även heterogena migreringar, exempelvis Oracle till PostgreSQL.

Hur påverkar NIS2 vår molnmigrering?

NIS2-direktivet ställer krav på riskhantering och incidentrapportering som direkt påverkar hur du planerar migreringen. Du måste kunna visa att säkerheten inte försämras under flytten, att du har kontroll på datalokaliseringskrav och att du har incidenthanteringsprocesser som fungerar även under övergångsperioden. Dokumentera allt — IMY och sektorsmyndigheter förväntar sig det.

For hands-on delivery in India, see zero-downtime gcp managed.

For hands-on delivery in India, see zero-downtime drift.