Azure Database Migration Service: dalla migrazione alla modernizzazione

Introduzione

L’obiettivo di questo articolo è introdurre Azure Database Migration Service (Azure DMS), un servizio fully-managed che consente di migrare database da origini multiple verso le piattaforme dati Azure in modo guidato e con downtime minimo.

L’articolo segue questo ordine:

• sfide tipiche delle migrazioni di database;
• panoramica dei servizi Azure dedicati;
• deep-dive su DMS (architettura e componenti);
• differenze tra modalità online e offline;
• scenari di migrazione supportati;
• opzioni di connettività verso Azure;
• una demo in cui viene eseguita una migrazione offline da SQL Server su Azure VM verso Azure SQL Database, utilizzando i cmdlet PowerShell di Azure DMS.

Perché migrare un database

Le organizzazioni decidono di migrare i propri database per diverse ragioni strategiche:

• modernizzazione dell’infrastruttura;
• riduzione dei costi operativi;
• miglioramento di performance e disponibilità;
• conformità ai requisiti di sicurezza.

Cosa comporta davvero una migrazione

Migrare un database non significa “copiare i dati da A a B”, è un’operazione che coinvolge contemporaneamente dati, sicurezza, applicazioni e operatività. I database hanno spesso dipendenze nascoste — job pianificati, linked server, applicazioni che li consumano in modi non documentati — e per istanze da centinaia di GB o TB il trasferimento può richiedere giorni mentre i dati continuano a crescere. A questo si aggiungono feature non sempre portabili tra versioni e piattaforme diverse. Va inoltre considerato che le applicazioni moderne operano in regime 24/7: ogni ora di downtime ha un costo e le finestre di manutenzione sono spesso ridotte a pochi minuti.

Aree di intervento di una migrazione di database

Una migrazione completa interessa quattro aree di intervento distinte: dati, sicurezza, applicazioni e operations. Ciascuna area richiede attività di pianificazione, configurazione e validazione specifiche, eseguite da ruoli diversi del team di progetto.

Dati. Migrazione di tabelle, viste, stored procedure e funzioni definite dall’utente; ricreazione di indici, constraint e trigger sul target; verifica della consistenza dei dati e della preservazione delle relazioni di integrità referenziale.

Sicurezza. Migrazione di login, utenti e ruoli del database; riassegnazione di permessi e ownership degli oggetti; configurazione di firewall, regole di Network Security Group e identità Microsoft Entra ID sul nuovo perimetro Azure.

Applicazioni. Aggiornamento delle connection string verso il nuovo endpoint; adeguamento del codice applicativo per gestire eventuali differenze di sintassi T-SQL o feature non supportate sul target; esecuzione di test funzionali e di regressione end-to-end.

Operations. Configurazione di backup e di disaster recovery secondo l’RPO e l’RTO richiesti; abilitazione di monitoring e alerting; aggiornamento di script di automazione e documentazione operativa in linea con la piattaforma di destinazione.

I rischi più frequenti sono: incompatibilità T-SQL e feature deprecate, degrado prestazionale dovuto a indici non ottimizzati per il target, problemi di encoding e di precisione numerica durante il trasferimento dei dati, complessità di coordinamento tra team eterogenei (DBA, sviluppatori, networking, security, business) e gap di competenze sulla piattaforma di destinazione, che rende necessario un piano di formazione preventivo.

Il costo del fai-da-te

Affrontare una migrazione senza strumenti dedicati comporta tempi prolungati, rischi elevati e costi nascosti: re-work, downtime imprevisto, ore-uomo per il troubleshooting di errori che un tool specializzato avrebbe intercettato in fase di assessment.

La necessità di un approccio strutturato

Quel che serve è un mix di tool specializzati, metodologie validate basate su best practice, assessment preliminari in grado di identificare i problemi prima del cutover, supporto e documentazione e flessibilità per coprire scenari diversi (versioni sorgente diverse, target diversi, finestre di downtime diverse).

I servizi Azure a disposizione

Azure non offre un unico strumento per migrare i database, bensì una famiglia complementare. È utile mappare gli strumenti per scenario, perché ognuno ha un punto di forza specifico:

Scenario	Strumenti disponibili
Discovery e assessment	Azure Migrate (con limitazioni), Azure Arc, DMS
Migrazione → Azure SQL Managed Instance	Azure Arc (SQL Server Migration Experience), DMS
Migrazione → SQL Server su Azure VM	Azure Migrate, Azure Arc (SQL Server Migration Experience), DMS, SQL Server Management Studio (migration component)
Migrazione → Azure SQL Database	DMS

Azure Migrate

Azure Migrate è l’hub centralizzato per valutare l’intera infrastruttura on-premises, non solo i database: è pensato per fornire una visione olistica della migrazione aziendale (server, applicazioni, dati). Risponde a domande del tipo “quanti SQL Server abbiamo in totale?”, “quali applicazioni dipendono da quale database?”, “quanto costerà migrare tutto in Azure?”, “qual è il target Azure più appropriato per ogni workload?”.

È utilizzabile su data center virtualizzati (VMware vSphere, Microsoft Hyper-V), server fisici, GCP e AWS, ma richiede l’installazione di un’appliance Azure Migrate nel datacenter — vincolo non sempre praticabile in contesti enterprise con policy restrittive. Risulta utile per discovery e assessment generali; per l’assessment più approfondito (compatibilità di feature) e per la migrazione effettiva verso Azure SQL Database o Azure SQL Managed Instance rimanda comunque ad Azure DMS.

Invece, nel caso di una migrazione lift and shift, è possibile utilizzare Azure Migrate per migrare l’intera macchina virtuale (VMWare VMs, Hyper-V VMs e server fisici), incluso il database installato. In questo scenario Azure Migrate è in grado di replicare dischi, sistema operativo e applicazioni AS-IS. Il risultato è una VM su Azure con SQL Server/MySQL o PostgreSQL identico all’on-prem.

Nota: questo articolo non tratta la migrazione lift and shift dei database server mediante Azure Migrate.

Azure Migrate: assessment e readiness

L’output di readiness elenca i database scoperti, segnala blocker e warning di compatibilità con il target Azure e produce un punteggio sintetico che permette di stimare lo sforzo di rimedio prima ancora di intervenire sul database.

Azure Migrate — readiness assessment

Azure Migrate: stima dei costi

L’altra metà dell’assessment è la stima dei costi: per ogni database (o gruppo) Azure Migrate propone uno SKU target adeguato a CPU, memoria, IOPS e dimensione, accompagnato dal prezzo mensile stimato. Consente quindi di costruire il business case della migrazione senza dover stimare a sentimento la dimensione dello SKU PaaS.

Azure Migrate — stima dei costi

SQL Server Migration Experience in Azure Arc

Azure Arc consente di gestire risorse non-Azure (on-premises o di altri cloud) come se fossero in Azure, abilitando assessment, governance e automazione centralizzati. Con SQL Server abilitato da Azure Arc è possibile valutare automaticamente la prontezza alla migrazione e spostare i database verso i target Azure SQL direttamente dal portale Azure, con dashboard dedicate e assistenza Copilot.

Il target attualmente supportato dall’esperienza di migrazione integrata in Azure Arc è Azure SQL Managed Instance —, indicata per scenari di modernizzazione verso un servizio PaaS gestito con elevata compatibilità con SQL Server.

Dalla schermata principale è possibile attraversare tutte le fasi del migration journey: assessment di readiness, scelta o provisioning del target Azure SQL MI, selezione del metodo di migrazione, monitoraggio e cutover finale.

Aggiornamento 05/05/2026: è disponibile in preview l’esperienza di migrazione verso SQL Server su Azure Virtual Machines, pensata per scenari di lift & shift in cui si desidera mantenere il controllo completo sull’istanza SQL Server, eseguendola però su infrastruttura Azure.

Cosa è Azure Database Migration Service

Azure Database Migration Service (DMS) è un servizio fully-managed pensato per semplificare la migrazione di database da origini multiple verso piattaforme dati Azure. Le caratteristiche chiave sono le seguenti:

Semplicità. Interfaccia guidata che riduce la complessità dei singoli passaggi.

Affidabilità e scalabilità. Servizio enterprise-grade con monitoraggio integrato e resilienza nativa.

Flessibilità. Supporto a migrazioni offline e online (con downtime minimo) e disponibilità di PowerShell e Azure CLI per scenari di automazione end-to-end.

Architettura di DMS

DMS è un servizio Azure che orchestra pipeline di migrazione per spostare dati da un ambiente on-premises (e non solo) verso Azure. Quando si crea un’istanza di DMS nella propria sottoscrizione, dietro le quinte viene associata a una pipeline di Azure Data Factory ospitata in una sottoscrizione Microsoft. L’invocazione avviene dal portale Azure o tramite PowerShell e Azure CLI. Vale la pena ricordare che DMS è il motore utilizzato dall’estensione Azure SQL Migration per Azure Data Studio, prodotto che verrà ritirato il 28 febbraio 2026: una ragione ulteriore per imparare a usare DMS direttamente.

Componenti della soluzione

Architettura di Azure Database Migration Service

Source: MS Tech Community - Architecture of Azure Database Migration Service

I componenti principali dell’architettura sono i seguenti:

• Source SQL Server. Istanza SQL Server on-premises (private cloud) o ospitata su VM in cloud pubblico. Sono supportate SQL Server 2008 e versioni successive, su Windows o Linux.
• Target Azure SQL. I target supportati sono Azure SQL Managed Instance, SQL Server on Azure Virtual Machines (registrato con la SQL IaaS extension in full management mode) e Azure SQL Database.
• SMB file share per i backup. Un fileshare SMB nel quale risiedono i file di backup dei database da migrare. Sono supportati anche Azure Storage blob container e Azure Files.
• Client tool. Estensione “Azure SQL Migration” per Azure Data Studio (in via di ritiro), portale Azure, PowerShell, Azure CLI.
• Azure Storage Account. Storage nella sottoscrizione del cliente, su cui vengono scritti i backup della sorgente e dal quale il target li legge per il restore.
• Azure Data Factory. DMS è associato alla pipeline ADF che funge da contenitore delle attività innescate dal workflow di migrazione e che gestisce la registrazione e il monitoraggio del Self-hosted Integration Runtime.
• Self-hosted Integration Runtime (SHIR). Componente da installare su una macchina che ha visibilità sia sul SQL Server sorgente sia sulla file share dei backup. Deve inoltre disporre di connettività verso Azure (storage e risorse target). DMS rilascia chiavi di autenticazione utilizzate per registrare lo SHIR. Lo SHIR funge da compute del data movement di DMS e può scalare fino a 4 nodi. Quando i backup risiedono su SMB locale o si esegue una migrazione logica verso Azure SQL Database, lo SHIR è obbligatorio.
• Target resource provider e Restore Service. Sul target Azure SQL VM o MI opera un servizio di restore che scansiona i backup nel container blob, ne valida il contenuto, costruisce il piano di restore e lo applica. Su Azure SQL VM è parte della SQL Server IaaS Agent extension; su Azure SQL MI corrisponde al Log Replay Service (LRS).

Il pattern adottato per l’architettura di rete è outbound-first, in netto contrasto con il modello del vecchio DMS classic in cui il servizio Azure dove essere deploiato nella rete del cliente.

• Lo SHIR “vive” all’interno della rete privata del cliente (on-premises o VNet Azure) e ha accesso diretto al SQL Server sorgente e alle share di backup, senza esporre nulla pubblicamente.
• È lo SHIR ad aprire una connessione outbound verso il servizio DMS in Azure: non è necessario aprire porte in ingresso sui firewall aziendali.
• Per portare in privato anche la comunicazione tra SHIR e servizi Azure (storage account, target database) si utilizzano i Private Endpoint: in questo modo il traffico non lascia mai la backbone Microsoft.
• Per database di grandi dimensioni (nell’ordine dei TB) un singolo SHIR può non essere sufficiente: è possibile scalare fino a 4 nodi registrati con la stessa chiave, ottenendo alta affidabilità (failover tra nodi) e parallelismo del data movement.

Modello di costo

DMS — nella versione attuale, distinta da quella classic — è Data Factory-powered. La voce di costo è quindi quella tipica di ADF: DIU-hours (Data Integration Units) o tempo di esecuzione delle pipeline necessarie a spostare i dati dal sorgente al target. Non è previsto alcun canone fisso per il servizio DMS: il costo è strettamente legato al consumo effettivo della pipeline.

Le quattro fasi della migrazione

Ogni progetto di migrazione si articola in quattro fasi sequenziali.

1. Assessment e pianificazione. Discovery delle istanze, analisi di compatibilità con il target, identificazione di blocker.
2. Sizing e provisioning. Scelta dello SKU target (Azure SQL DB, MI o VM) sulla base dei carichi reali misurati.
3. Migrazione e cutover. Trasferimento dei dati e switch dell’applicazione sul nuovo target.
4. Monitoraggio e ottimizzazione. Validazione delle performance post-migrazione e tuning di SKU e indici quando necessario.

Migrazione fisica vs migrazione logica

DMS supporta due tecniche di trasferimento dati profondamente diverse.

Migrazione fisica. Il backup del database sorgente viene ripristinato sul database target. È la modalità impiegata verso Azure SQL VM e Azure SQL Managed Instance, dove il restore di un backup nativo SQL Server è supportato.

Source: MS Tech Community - Architecture of Azure Database Migration Service

Migrazione logica. I record vengono letti dalle tabelle del database sorgente e inseriti nelle tabelle corrispondenti sul target. È la modalità impiegata verso Azure SQL Database, che non accetta restore di file di backup ma opera a livello di schema e di dati logici.

Source: MS Tech Community - Architecture of Azure Database Migration Service

Ricapitolando:

	Migrazione Fisica (online/offline)	Migrazione Logica (solo offline su DMS)
Cosa viene spostato	File di backup	Schema e dati
Target	SQL MI - SQL VM	Azure SQL
Flessibilità	Rigida: sposta tutto il DB così com’è Sorgente offline – Downtime per intera durata migrazione	Alta: posso scegliere quali tabelle migrare - Sorgente offline – Downtime per intera durata migrazione
Versione online	Ripristino continuo dei log di transazione. Sorgente online - downtime minimo durante cutover	N/A

Il cutover

La fase di cutover è il momento in cui si interrompe la connessione delle applicazioni al database sorgente e la si redirige sul target. Costituisce il punto più delicato dell’intera migrazione: dipende dalla modalità adottata (online vs offline), richiede coordinamento applicativo (es.: modifica della connection string) e va sempre accompagnata da un piano di rollback verificato.

Quando usare la migrazione online

La modalità online è indicata quando il sistema non può permettersi una finestra di downtime nell’ordine delle ore. Si applica tipicamente a:

• applicazioni mission-critical;
• database di grandi dimensioni;
• sistemi con requisiti di alta disponibilità;
• contesti in cui le finestre di manutenzione sono limitate a pochi minuti.

DMS replica continuamente le modifiche dal sorgente al target durante la migrazione, fino al momento del cutover, che dura il minimo indispensabile.

Quando usare la migrazione offline

La modalità offline è la scelta corretta quando un certo downtime (minuti o ore) è accettabile. Si applica tipicamente a:

• database di piccole o medie dimensioni;
• ambienti dev/test;
• contesti in cui il downtime pianificato non costituisce un problema.

I vantaggi sono di natura operativa: setup più semplice, minore overhead di rete e meno componenti da gestire.

Modalità supportate per ciascun target

Non tutte le combinazioni source-target supportano sia la modalità online sia quella offline. La compatibilità dipende dal target Azure SQL scelto (Database, Managed Instance o VM) e dalla tecnica di trasferimento (logica vs fisica).

Azure SQL Targets	Migrazione Offline	Migrazione Online
Azure SQL Database	SI	NO
Azure SQL Managed Instance	SI	SI
SQL Server on Azure VM	SI	SI

Scenari comuni di adozione

I quattro scenari più frequenti che giustificano l’adozione di DMS sono:

• Datacenter decommissioning. Migrazione completa dell’infrastruttura database fuori dal proprio datacenter.
• Modernizzazione delle applicazioni. Passaggio da SQL Server gestito su VM a PaaS, con riduzione del carico operativo per il team.
• Disaster recovery. Creazione di una replica in Azure utilizzata come DR site.
• Dev/Test in cloud. Spostamento degli ambienti non-produttivi su Azure per ridurre il footprint on-premises.

Origini e target supportati

DMS copre le combinazioni più comuni nel mondo enterprise.

• SQL Server (on-premises, Azure VM, AWS RDS) → Azure SQL Database, Azure SQL Managed Instance, SQL Server su Azure VM.
• PostgreSQL (on-premises, AWS RDS) → Azure Database for PostgreSQL.
• MySQL (on-premises, AWS RDS) → Azure Database for MySQL.
• Oracle (on-premises) → Azure Database for PostgreSQL, con conversione dello schema.
• MongoDB → Azure Cosmos DB.

Migrare da Azure VM verso PaaS

Una domanda ricorrente: è possibile usare DMS anche se SQL Server è già ospitato su una VM in Azure? Sì. I casi tipici sono due:

• Azure VM → Azure SQL Managed Instance. Si è effettuato un lift & shift iniziale spostando la VM da on-premises ad Azure e si vuole ora modernizzare passando a un servizio gestito per ridurre il carico operativo.
• Azure VM → Azure SQL Database. Si vuole eliminare completamente la gestione dell’infrastruttura.

Best practice operative

Due best practice che fanno la differenza in produzione.

Utilizzare una jumpbox dedicata per lo SHIR. Tre vantaggi concreti:

• Nessun impatto sul SQL Server. Si evita di installare componenti aggiuntivi sul nodo che ospita il motore SQL, riducendo il rischio operativo e la contesa di CPU, RAM e disco durante assessment o copie. È una best practice esplicitata anche nella documentazione di Azure Data Factory: lo SHIR non deve risiedere sulla stessa macchina della sorgente, per evitare competizione sulle risorse.
• Connettività e sicurezza semplificate. La jumpbox può vivere nella stessa subnet/VNet (o rete on-premises) con accesso ai SQL Server e disporre dell’uscita verso Azure necessaria per comunicare con DMS e ADF. Diventa così l’unico punto di contatto con il cloud.
• Gestione centralizzata e automazione. Sulla jumpbox è possibile automatizzare l’installazione e gli aggiornamenti dello SHIR, oltre all’esecuzione degli assessment su più database tramite script PowerShell e Azure CLI (Az.DataMigration).

Quando i backup risiedono su file share locale o si esegue una migrazione logica verso Azure SQL Database, lo SHIR è obbligatorio: è opportuno monitorare l’utilizzo delle risorse del nodo, dato che è il componente che svolge il lavoro pesante del data movement.

Scalare temporaneamente il target a SKU Premium. Durante l’operazione di data migration è consigliabile portare l’Azure SQL Database target a SKU Premium, in modo da minimizzare il throttling sul disco a cui gli SKU inferiori sono soggetti durante un import massivo. A migrazione completata si torna allo SKU previsto. Riferimento ufficiale: Improving SQL DB Migration Performance nella documentazione di Azure DMS.

Perché la connettività è critica

I quattro fattori che possono trasformare la rete in collo di bottiglia (o in punto di rottura) di una migrazione sono volume di dati trasferiti, latenza di rete, stabilità della connessione e sicurezza del transito. Sottostimare anche uno solo di questi quattro elementi è il modo più semplice per trasformare una migrazione di una settimana in una di un mese.

Volume di dati. Per un database da 500 GB il solo trasferimento iniziale richiede circa 11 ore a 100 Mbps, circa 1 ora a 1 Gbps o pochi minuti su ExpressRoute a 10 Gbps. Una banda insufficiente trasforma una migrazione da ore in giorni.

Latenza. Per le migrazioni online (con replica continua) la soglia conta:

• < 50 ms — ideale per replica in tempo reale.
• 50–100 ms — accettabile, ma può causare ritardi nella sincronizzazione.
• > 100 ms — problematico, con rischio di lag crescente. Il target sarà sempre “indietro” rispetto alla sorgente, rendendo difficile chiudere il gap al cutover.

Stabilità. Le interruzioni durante la migrazione possono causare il fallimento dell’operazione, costringere a ripartire da capo o corrompere i dati in transito. Una VPN consumer instabile non è adatta a migrazioni di produzione.

Sicurezza del transito. Crittografia TLS/SSL obbligatoria, nessuna esposizione su Internet pubblica quando possibile, firewall e Network Security Group configurati correttamente.

Database pubblicamente accessibile

Esporre il database sorgente con un endpoint pubblico è un’opzione accettabile soltanto in test o proof-of-concept. Da evitare in produzione: il rischio di esposizione di dati sensibili e i requisiti di compliance la rendono impraticabile.

VPN Site-to-Site

Pro. Soluzione economica e veloce da configurare; sufficiente per database di piccole dimensioni e migrazioni offline.

Contro. Banda limitata e latenza variabile: non è la scelta corretta quando occorre spostare TB di dati in una finestra ridotta.

Azure ExpressRoute

Pro. Connessione dedicata con banda garantita, latenza bassa e prevedibile e traffico fuori dall’Internet pubblico.

Contro. Costo più elevato e tempi di provisioning non trascurabili.

È la connettività consigliata per database di grandi dimensioni e migrazioni online, dove la stabilità di banda e latenza non è negoziabile.

Demo — migrazione offline da SQL Server su Azure VM ad Azure SQL Database

Lo scenario mostrato è una migrazione offline da SQL Server ospitato su una Azure VM verso Azure SQL Database: si tratta quindi di una migrazione logica, in cui lo schema viene creato sul target e i dati vengono trasferiti tabella per tabella, senza replica continua delle modifiche.

La demo ripercorre la sequenza completa di uno scenario reale, dall’assessment iniziale alla data migration finale, eseguita utilizzando gli appositi comandi PowerShell.

Repo Demo: GitHub - Azure Samples - Data Migration SQL

Architettura della demo

L’ambiente è interamente su Azure ed è composto da pochi elementi essenziali, ognuno con un ruolo preciso nel flusso di migrazione:

• pocmigrationservice — istanza di Azure Database Migration Service che orchestra assessment, performance data collection, SKU recommendation, schema migration e data migration.
• sqlvm-001 — Azure VM con SQL Server che fa da sorgente: ospita il database da migrare e simula un tipico SQL Server “legacy” da modernizzare.
• sqldb-{suffixname} — istanza Azure SQL Database (PaaS) che fa da target della migrazione logica.
• jb-migration — jumpbox Windows da cui vengono eseguiti tutti gli script PowerShell (modulo Az.DataMigration): è il punto di controllo unico della pipeline e ha visibilità di rete sia sulla VM sorgente sia sul target.
• vnet-{suffixname} e jumpbox-migration-vnet — le due Virtual Network che ospitano rispettivamente il workload SQL e la jumpbox, con i relativi NSG (sqlvm-001-nsg, jumpbox-migration-nsg) a regolare il traffico.
• myprivateendpoint + Private DNS zone — private endpoint verso Azure SQL Database: il traffico dati verso il target resta su rete privata, senza passare dalla public endpoint del servizio PaaS.

Il flusso logico è semplice: la jumpbox lancia i cmdlet Az.DataMigration che istruiscono l’istanza DMS; DMS legge dalla VM SQL sorgente attraverso la VNet e scrive sul target Azure SQL Database tramite il private endpoint.

Architettura della demo

DMS — Assessment

Si avvia un assessment di compatibilità sul database sorgente: lo strumento identifica le feature SQL non supportate sul target Azure, i breaking change e i warning. È lo stesso assessment disponibile da portale, ma scriptabile e ripetibile in pipeline CI.

Get-AzDataMigrationAssessment `
    -ConnectionString "Data Source=10.0.0.4,1433;Initial Catalog=master;User Id=sqladmin;Password=<password>" `
    -OutputFolder "C:\temp\output" `
    -Overwrite

DMS — assessment di compatibilità

DMS — Performance data collection

Per dimensionare correttamente il target è necessario un campionamento reale del carico: CPU, memoria, IOPS e throughput. Il cmdlet di performance data collection raccoglie le metriche per un periodo definito, da utilizzare come input per la SKU recommendation.

Get-AzDataMigrationPerformanceDataCollection `
    -SqlConnectionStrings "Data Source=10.0.0.4,1433;Initial Catalog=master;User Id=sqladmin;Password=<password>" `
    -OutputFolder "C:\temp\output" `
    -PerfQueryInterval 10 `
    -NumberOfIterations 5 `
    -StaticQueryInterval 120

DMS — performance data collection

DMS — SKU recommendation

Sulla base dei dati di performance raccolti, DMS calcola lo SKU Azure SQL consigliato (DB, MI o VM) in grado di soddisfare i requisiti del workload, evitando sia l’overprovisioning sia il throttling che si verificherebbe pianificando in modo empirico.

Get-AzDataMigrationSkuRecommendation `
    -OutputFolder "C:\temp\output" `
    -DisplayResult `
    -Overwrite `
    -TargetPlatform "AzureSqlDatabase"

DMS — SKU recommendation

DMS — Report di assessment e SKU recommendation

L’output finale è un report unico che combina readiness e dimensionamento: il documento da portare in review prima di approvare la migrazione, in quanto risponde sia alla domanda “si può fare?” sia a “quanto costa?”.

DMS — report di assessment e SKU recommendation

DMS — Migrazione dello schema del database

Prima del trasferimento dei dati, la migrazione dello schema crea sul target la struttura del database (tabelle, indici, constraint, viste, stored procedure). È la fase in cui emergono eventuali oggetti non portabili: meglio scoprirli qui che a metà del data movement.

Estrazione dello schema dal database sorgente in un file .dacpac:

SqlPackage /Action:Extract `
    /TargetFile:"C:\temp\projects\adventureworks2019.dacpac" `
    /p:ExtractAllTableData=false `
    /p:ExtractReferencedServerScopedElements=true `
    /p:VerifyExtraction=true `
    /SourceServerName:"10.0.0.4" `
    /SourceDatabaseName:"AdventureWorks2019" `
    /SourceUser:"sqladmin" `
    /SourcePassword:"<password>" `
    /SourceTrustServerCertificate:true

Pubblicazione dello schema sul database target Azure SQL Database:

SqlPackage /Action:Publish `
    /SourceFile:"C:\temp\projects\adventureworks2019.dacpac" `
    /p:CreateNewDatabase=false `
    /p:AllowIncompatiblePlatform=true `
    /p:ExcludeObjectTypes="Users;RoleMembership" `
    /Diagnostics:false `
    /TargetServerName:"sqldb-fc.database.windows.net" `
    /TargetDatabaseName:"AdventureWorks" `
    /TargetUser:"sqladmin" `
    /TargetPassword:"<password>" `
    /TargetTrustServerCertificate:true

DMS — schema migration: avvio ed esito

Una nota sul Query Store

Query Store è una feature di SQL Server (e di Azure SQL Database / Managed Instance) che funge da flight recorder del motore: registra in modo persistente i piani di esecuzione delle query, le statistiche di runtime (CPU, durata, letture, attese) e la loro evoluzione nel tempo, sopravvivendo a riavvii e failover. È la base su cui poggiano funzionalità come Automatic Plan Correction e Intelligent Query Processing, ed è lo strumento principale per fare troubleshooting delle regressioni di performance dopo una migrazione.

Sulle piattaforme PaaS Azure SQL il Query Store è abilitato di default ed è il prerequisito di molte raccomandazioni automatiche del servizio (tuning, alerting, advisor). Su Azure SQL Database (single database ed elastic pool) il comportamento è ancora più rigido: il Query Store non può essere disabilitato. Eseguire ALTER DATABASE [db] SET QUERY_STORE = OFF restituisce il warning ”'QUERY_STORE=OFF' is not supported in this version of SQL Server” — comportamento documentato in ALTER DATABASE SET options.

Lo si vede proprio nello screenshot del SqlPackage /Action:Publish qui sopra (secondo riquadro della galleria “DMS — schema migration: avvio ed esito”): durante la fase Updating database compare la riga 'QUERY_STORE=OFF' is not supported in this version of SQL Server. perché il .dacpac estratto dalla sorgente contiene un’istruzione di disabilitazione che il target Azure SQL Database rifiuta — emettendo un warning ma proseguendo comunque con il publish.

DMS — Data migration

A schema pronto e SKU dimensionato parte la data migration vera e propria. È la fase più lunga: la durata dipende dal volume, dalla banda di rete e dal tipo di migrazione (online vs offline). Nelle migrazioni online la replica continua delle modifiche prosegue fino al cutover.

New-AzDataMigrationToSqlDb `
    -ResourceGroupName rg-dms-lab `
    -SqlDbInstanceName sqldb-fc `
    -Kind "SqlDb" `
    -TargetDbName AdventureWorks `
    -SourceDatabaseName AdventureWorks2019 `
    -SourceSqlConnectionAuthentication SQLAuthentication `
    -SourceSqlConnectionDataSource 10.0.0.4 `
    -SourceSqlConnectionUserName sqladmin `
    -SourceSqlConnectionPassword $sourcePassword `
    -Scope "/subscriptions/<subscription-id>/resourceGroups/rg-dms-lab/providers/Microsoft.Sql/servers/sqldb-fc" `
    -TargetSqlConnectionAuthentication SQLAuthentication `
    -TargetSqlConnectionDataSource sqldb-fc.database.windows.net `
    -TargetSqlConnectionUserName sqladmin `
    -TargetSqlConnectionPassword $targetPassword `
    -MigrationService "/subscriptions/<subscription-id>/resourceGroups/rg-dms-lab/providers/Microsoft.DataMigration/sqlMigrationServices/PoCMigrationService"

DMS — data migration: avvio e avanzamento

Verifica della migrazione dal portale

Anche quando l’orchestrazione avviene in PowerShell, lo stato di avanzamento rimane osservabile dal portale Azure: pagine dedicate a ciascun job di migrazione mostrano percentuali di completamento, errori e log dettagliati per fase.

DMS — verifica migrazione dal portale Azure

Conclusioni

Azure Database Migration Service affronta la complessità delle migrazioni dei database offrendo un percorso strutturato — assessment, performance data collection, SKU recommendation, schema migration e data migration — che riduce gli spazi di improvvisazione e rende ripetibile ciò che, fatto a mano, sarebbe un esercizio fragile.

Punti chiave da ricordare:

• L’assessment non è un’opzione. Sia che lo si esegua a livello di estate — con Azure Migrate e il suo processo di discovery di server, applicazioni e database — sia che lo si esegua puntualmente sul singolo workload con i cmdlet di DMS (Get-AzDataMigrationAssessment e Get-AzDataMigrationSkuRecommendation), farlo prima di qualunque attività di migrazione riduce drasticamente il rischio di scoperte tardive (incompatibilità, sotto-dimensionamenti, costi inattesi). I due strumenti sono complementari: Azure Migrate dà la visione d’insieme e la stima dei costi, DMS scende nel dettaglio del singolo database e della SKU target.
• La scelta tra migrazione online e offline è una scelta di business, non di tecnologia. La modalità online abbatte il downtime ma allunga e complica il cutover; la modalità offline è più semplice ma richiede una finestra di fermo concordata.
• La connettività verso Azure è parte del progetto. Private endpoint, ExpressRoute o VPN non sono dettagli implementativi: condizionano latenza, banda effettiva e quindi la durata reale della migrazione.

Azure Database Migration Service, in definitiva, non è solo uno strumento di lift-and-shift dei database: è il punto di partenza naturale per un percorso di modernizzazione verso le piattaforme dati gestite di Azure.