Opsios migreringsmetodik i fyra faser

Vi har genomfört hundratals databasmigreringar till Azure, och mönstret är tydligt: projekt som misslyckas har nästan alltid hoppat över bedömningsfasen. Här är vår beprövade metodik.

Fas 1: Inventering och dataklassificering

Innan du rör ett enda migreringsverktyg behöver du veta vad du flyttar. Det låter trivialt, men i praktiken ser vi ofta att organisationer har databaser som ingen äger, dataflöden som inte är dokumenterade och personuppgifter som hamnat i kolumner de inte förväntade sig.

Konkreta steg:

• Kör en fullständig inventering med Azure Migrate eller manuell kartläggning
• Klassificera data enligt GDPR-kategorier (personuppgifter, känsliga personuppgifter, affärsdata)
• Identifiera beroenden: vilka applikationer ansluter till vilka databaser, och via vilka anslutningssträngar?
• Dokumentera dataresidens-krav — för svenska verksamheter innebär detta ofta att Sweden Central (Gävle/Sandviken) är den primära regionen

Den här fasen tar typiskt 1–3 veckor beroende på miljöns komplexitet, men den sparar veckor längre fram.

Fas 2: Kompatibilitetsanalys och målarkitektur

Nu kör du Data Migration Assistant (DMA) mot varje källdatabas. DMA genererar en rapport som visar:

• Funktioner som inte stöds i målplattformen
• Prestandarekommendationer
• Kompatibilitetsnivåer som behöver justeras

Parallellt väljer du målarkitektur. Det är här FinOps-perspektivet kommer in — valet mellan Azure SQL Database, SQL Managed Instance och SQL Server på Azure VM har dramatisk inverkan på både kostnad och driftskomplexitet.

Cloud FinOps

Fas 3: Testmigrering och prestandavalidering

Här gör vi en fullständig migrering till en icke-produktionsmiljö. Det är inte en formalitet — det är den fas där vi upptäcker att:

• Stored procedures som fungerade i SQL Server 2016 beter sig annorlunda i Azure SQL
• Nätverkslatens mellan applikationsservern och den nya databasen påverkar specifika arbetsflöden
• Indexeringsstrategin behöver justeras för Azure SQL:s query optimizer
• Backup-policyer och retention-perioder måste konfigureras korrekt

Vi mäter migreringstid, validerar dataintegritet (radräkning, checksummor på kritiska tabeller) och kör applikationens regressionstester mot den nya databasen. Först när alla kvalitetsgrindar är godkända planerar vi produktionscutover.

Fas 4: Produktionsmigrering och cutover

För online-migrering ser flödet ut så här:

1. Starta kontinuerlig replikering via DMS — data börjar synkroniseras i bakgrunden

2. Övervaka replikeringseftersläpningen tills den stabiliserat sig på nära noll

3. Planerad cutover-tidpunkt — stoppa skrivningar till källan, vänta på att replikeringen hinner ikapp

4. Verifiera dataintegritet i måldatabasen

5. Peka om applikationens anslutningssträngar till Azure-målet

6. Övervaka intensivt de första 24–72 timmarna

Cutover-fönstret för en online-migrering är typiskt 5–30 minuter. Det förutsätter att replikeringen har körts stabilt och att du har testat ompekningen i förväg.

Molnmigrering

Säkerhet och regelefterlevnad under migrering

Migreringsfasen är en av de mest sårbara perioderna ur säkerhetsperspektiv. Data är i rörelse, tillfälliga kopior existerar, och åtkomstkontroller kanske inte är lika strikta i en övergångsmiljö.

Krav vi bygger in i varje migreringsprojekt:

• Kryptering i transit: TLS 1.2 minimum mellan källa, DMS-instans och Azure-mål
• Kryptering i vila: Transparent Data Encryption (TDE) aktiverat på måldatabasen
• Åtkomstloggning: Alla åtgärder under migreringen loggas i Azure Monitor och lagras i minst 90 dagar
• Nätverksisolering: DMS-instansen körs i ett dedikerat VNet med Network Security Groups (NSG) som begränsar trafik
• GDPR-dokumentation: Data Processing Impact Assessment (DPIA) uppdateras med den nya datalagringsplatsen

NIS2-direktivet, som nu är implementerat i svensk lag, ställer ytterligare krav på incidentrapportering och riskhantering för organisationer som omfattas. En migrering till Azure bör ses som en möjlighet att stärka säkerhetsposturen — inte bara flytta befintliga brister till en ny plattform.

Molnsäkerhet

Vanliga fallgropar vi ser i produktion

Opsios NOC/SOC i Karlstad och Bangalore övervakar Azure-miljöer dygnet runt. De vanligaste problemen efter en databasmigrering:

1. Överdimensionerade tjänstnivåer. Många väljer Premium eller Business Critical "för säkerhets skull" utan att ha prestandadata som motiverar det. Enligt Flexeras State of the Cloud-rapport är kostnadsoptimering konsekvent den största utmaningen för molnanvändare. Börja med en lägre nivå och skala upp baserat på faktisk belastning.

2. Saknade index efter migrering. DMS migrerar schema och data, men prestandaoptimering i Azure SQL kan kräva andra index än i on-premises SQL Server. Kör Query Performance Insight i Azure Portal under de första veckorna.

3. Applikationer med hårdkodade anslutningssträngar. Använd Azure Key Vault för anslutningssträngar och konfigurera applikationer att läsa därifrån. Det gör framtida failover och regionbyten avsevärt enklare.

4. Glömd kostnad för egress-trafik. Data som lämnar Azure kostar pengar. Om applikationsservrar fortfarande körs on-premises och gör tunga queries mot Azure SQL, kan egress-kostnaden bli en obehaglig överraskning.

När DMS inte räcker — alternativa verktyg

Azure DMS är utmärkt för databasmigrering, men det täcker inte alla scenarier:

Managerade molntjänster

Så kommer du igång

En Azure-datamigrering är inte ett IT-projekt som bör styras av verktygets begränsningar — det är ett affärsbeslut som kräver tydliga mål, en realistisk tidsplan och rätt kompetens. Opsios migreringsteam arbetar med en iterativ metodik där varje fas har definierade kvalitetsgrindar och tydligt ägarskap. Vi ser till att migreringen inte bara lyckas tekniskt utan att den resulterande Azure-miljön är kostnadsoptimerad, säker och redo att skalas.

Managerad DevOps

Det viktigaste du kan göra just nu: kör Data Migration Assistant mot dina produktionsdatabaser. Rapporten ger dig en konkret bild av vad migreringen faktiskt innebär — inte gissningar, utan data.

Vanliga frågor

Vilka databaser stödjer Azure Database Migration Service?

DMS hanterar migrering från SQL Server, MySQL, PostgreSQL, Oracle och MongoDB till Azure SQL Database, Azure SQL Managed Instance, Azure Database for MySQL/PostgreSQL och Cosmos DB. Både on-premises-källor och andra molnplattformar som AWS RDS stöds.

Hur lång stilleståndstid kräver en Azure-datamigrering?

Med online-migrering (kontinuerlig replikering) kan stilleståndstiden reduceras till minuter. Offlinemigrering kräver att källdatabasen är otillgänglig under hela överföringen, vilket kan ta timmar beroende på datavolym. Valet beror på verksamhetens tolerans för avbrott.

Vad kostar Azure Database Migration Service?

Själva DMS-tjänsten är kostnadsfri i standardnivån. Du betalar för beräkningsresurser (den DMS-instans som körs under migreringen) och för målresursen i Azure. Den stora kostnadsposten är måldatabasens tjänstnivå — en FinOps-analys i planeringsfasen kan spara stora belopp långsiktigt.

Hur hanterar vi GDPR-krav under migreringen?

Klassificera data innan migrering, säkerställ att överföringen sker krypterad (TLS 1.2+), logga all åtkomst och verifiera att målmiljön i Azure uppfyller samma eller strängare skyddsnivå. För svenska verksamheter rekommenderar vi Sweden Central som primär region.

Kan vi migrera från AWS RDS till Azure SQL?

Ja. DMS stödjer migrering från AWS RDS for SQL Server och MySQL. Processen kräver att du aktiverar binärloggning (MySQL) eller använder backup/restore-flöde (SQL Server) och konfigurerar nätverksåtkomst mellan källan och DMS-instansen.

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

For hands-on delivery in India, see how Opsio delivers disaster recovery.