Il SOC incontra il GitOpsCon l’aggiornamento di luglio 2026, Microsoft Sentinel porta la logica DevOps fin dentro il cuore del rilevamento delle minacce: le regole di detection personalizzate entrano ufficialmente tra i contenuti gestibili come Detections-as-Code (DaC) tramite le Sentinel Repositories, mentre un nuovo pannello Table Insights rende finalmente leggibile a colpo d’occhio lo stato di salute dell’ingestion. Sono due funzionalità distinte ma complementari, ed entrambe parlano direttamente a chi in azienda gestisce SIEM e pipeline CI/CD con lo stesso approccio.Detections-as-Code: le regole di rilevamento come contenuto versionatoMicrosoft Sentinel Repositories esisteva già per contenuti come analytics rules, automation rules, hunting queries, parser, playbook e workbook: la novità è che ora anche le regole di detection personalizzate (custom detection rules) rientrano in questo flusso, gestibili tramite la Microsoft Security Bicep extension. Il repository esterno — GitHub o Azure DevOps — diventa la single source of truth: qualunque modifica fatta manualmente dal portale di Sentinel viene sovrascritta alla successiva sincronizzazione dal repository.Per collegare un repository servono permessi precisi, spesso motivo di attrito nei team più strutturati:ruolo Owner sul resource group che contiene il workspace Sentinel, per creare la connessione;accesso Collaborator sul repository GitHub, oppure Project Administrator su Azure DevOps;GitHub Actions abilitate (o Pipelines per Azure DevOps);per Azure DevOps, la connessione deve risiedere nello stesso tenant del workspace Sentinel.Ogni workspace Sentinel è limitato a cinque connessioni repository, e ogni resource group a 800 deployment nella sua history — un limite da tenere presente se si pianifica una struttura multi-repo per team o ambienti diversi.Bicep, non ARM JSON: la scelta consigliataMicrosoft consiglia esplicitamente Bicep rispetto ai template ARM JSON grezzi per descrivere le regole. Un paio di dettagli tecnici da non sottovalutare in fase di migrazione:i file Bicep non supportano la proprietà id: le regole esportate da Sentinel la includono, e va rimossa manualmente prima della decompilazione;per una decompilazione pulita da ARM JSON a Bicep conviene forzare lo schema alla versione 2019-04-01;le connessioni create prima del 1° novembre 2024 non supportano Bicep e vanno rimosse e ricreate per abilitarlo.Per chi parte da zero, il repository ufficiale SentinelCICD/RepositoriesSampleContent fornisce template di esempio per ogni tipo di contenuto, comprese le funzionalità avanzate delle connessioni repository.Smart deployments: non ridistribuire ciò che non è cambiatoUna delle frizioni tipiche del content-as-code applicato a un SIEM è il rischio di ridistribuire regole invariate a ogni deploy, resettando ad esempio schedule dinamici delle analytics rule. Sentinel risolve il problema con gli smart deployments: un file CSV nella cartella .sentinel del repository tiene traccia dei commit e il workflow evita di ridistribuire contenuti non modificati dall’ultimo deploy. È abilitato di default sulle nuove connessioni; per disattivarlo (e forzare sempre il deploy completo) si interviene sul file YAML del workflow o della pipeline.Il flusso operativo tipico diventa quindi: un analista propone una nuova regola di detection in una pull request, il team la revisiona come farebbe con codice applicativo, al merge la pipeline CI/CD (GitHub Actions o Azure Pipelines) distribuisce automaticamente solo le modifiche nel workspace Sentinel collegato — con audit trail completo su chi ha cambiato cosa e quando, cosa che il portale da solo non garantisce con la stessa granularità.Table Insights: capire l’ingestion senza scrivere KQLLa seconda novità rilevante del mese è Table Insights, un nuovo pannello nella pagina Tables della configurazione di Sentinel (Defender portal → Microsoft Sentinel → Configuration → Tables). Mostra, senza bisogno di query KQL manuali:il volume di ingestion degli ultimi 30 giorni, suddiviso per tier (Analytics vs Auxiliary/Data Lake);le variazioni giorno su giorno e settimana su settimana, utili per individuare picchi o cali anomali;le tabelle che consumano più ingestion, per stimare rapidamente i costi;i connettori che hanno smesso di inviare dati — spesso il primo sintomo di un problema di raccolta che altrimenti si scopre solo durante un’investigazione, quando è troppo tardi.Chi preferisce restare in KQL può ottenere una vista equivalente sfruttando il campo Plan della tabella Usage, che permette di scomporre l’ingestion per Analytics, Basic e Auxiliary direttamente in query native — utile per costruire dashboard personalizzate o alert di costo oltre al pannello grafico.Nuovi connettori datiL’aggiornamento di luglio amplia anche la copertura dei data connector con il supporto nativo per GitHub Enterprise, Agari, Airlock Digital e Gigamon — un’estensione che si allinea bene proprio con l’adozione di Detections-as-Code, dato che GitHub Enterprise diventa ora sia sorgente di log di audit sia repository di regole.Perché conviene iniziare oraPer un SOC maturo, la combinazione di queste due funzionalità è più significativa della somma delle parti: Detections-as-Code porta revisione tra pari, versionamento e rollback affidabile sulle regole di rilevamento, mentre Table Insights riduce il tempo necessario per accorgersi che una sorgente di log si è interrotta silenziosamente — un problema che, senza query dedicate, spesso passa inosservato per settimane. Chi gestisce già Infrastructure-as-Code su Azure con Bicep o Terraform troverà il modello concettuale familiare; la parte più delicata resta la migrazione delle regole esistenti dal portale al repository, che conviene pianificare per gruppi di severità o per data source, non tutta insieme.Fonte: Petri IT Knowledgebase – Microsoft Sentinel Adds Detections-As-Code, Table Insights, and New Data Connectors, con approfondimenti dalla documentazione ufficiale Microsoft Learn su Sentinel Repositories.

Chi amministra Microsoft Entra ID conosce bene il problema dei “gruppi nidificati”: per anni non è stato possibile costruire un gruppo dinamico che includesse automaticamente i membri di un altro gruppo. La regola preview memberOf, introdotta proprio per colmare questa lacuna, sta però per essere ritirata. Dal 3 novembre 2026 tutte le configurazioni che la usano smetteranno di aggiornarsi, restando congelate all’ultimo stato elaborato correttamente. Se gestite gruppi dinamici, unità amministrative dinamiche o policy di entitlement management basate su memberOf, è il momento di pianificare la migrazione.Cos’è (stato) l’operatore memberOfIn anteprima pubblica, memberOf ha permesso di creare gruppi a membership dinamica popolati a partire dall’appartenenza ad altri gruppi, di sicurezza, Microsoft 365 o sincronizzati da Active Directory on-premises. La regola si scriveva nella sintassi avanzata del rule editor, non essendo mai stata supportata dal rule builder grafico:// Regola per un gruppo dinamico di utenti user.memberof -any (group.objectId -in ['<groupObjectId>']) // Regola per un gruppo dinamico di device device.memberof -any (group.objectId -in ['<groupObjectId>']) // Più gruppi sorgente contemporaneamente user.memberof -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>'])Era possibile usarla per gruppi dinamici veri e propri, per unità amministrative dinamiche e per policy di auto-assignment in Entra ID Governance, con limiti già stringenti in preview: 500 gruppi memberOf per tenant, massimo 50 gruppi sorgente per regola, nessuna combinazione con altri operatori o con altre regole memberOf annidate.Perché Microsoft la ritiraDurante la preview, Microsoft ha osservato che l’uso di memberOf può rallentare l’elaborazione della membership dinamica per tutti i gruppi del tenant, non solo per quelli che la utilizzano: un singolo gruppo configurato con questo operatore può introdurre ritardi di elaborazione a livello di tenant. Per questo motivo Microsoft ha deciso di ritirare l’operatore dalla preview, pur riconoscendo la validità dello scenario d’uso, e sta sviluppando una soluzione alternativa più scalabile, senza però fornire ancora una data di disponibilità.Cosa succede dopo il 3 novembre 2026Le configurazioni che usano ancora memberOf non genereranno errori visibili: semplicemente smetteranno di aggiungere o rimuovere membri quando cambia l’appartenenza ai gruppi sorgente, restando congelate all’ultimo stato noto. È un comportamento subdolo perché non c’è un evento di rottura evidente, solo un progressivo disallineamento tra la realtà organizzativa e ciò che Entra ID applica. Gli effetti possono includere:Accessi Teams e SharePoint non più aggiornati per utenti entrati o usciti da un gruppo sorgenteTargeting delle policy di Conditional Access basato su appartenenze obsoleteLicenze assegnate tramite group-based licensing non più coerenti con l’organico realeAmbiti amministrativi (administrative unit) che non riflettono più la struttura correnteAssegnazioni di access package in Entra ID Governance bloccate sullo stato congelatoCome prepararsi: audit prima della deadlineIl primo passo è mappare ogni configurazione che dipende da memberOf. Per i gruppi dinamici, si può esportare l’elenco dall’Entra admin center oppure interrogare Microsoft Graph PowerShell cercando la stringa nella proprietà MembershipRule:Connect-MgGraph -Scopes "Group.Read.All" Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'DynamicMembership')" ` -Property Id, DisplayName, MembershipRule | Where-Object { $_.MembershipRule -match 'memberof' } | Select-Object Id, DisplayName, MembershipRulePer le unità amministrative dinamiche e le policy di auto-assignment dell’entitlement management non esiste (ancora) un filtro diretto lato server sulla regola: occorre enumerare gli oggetti e verificare la proprietà della regola dinamica, ad esempio:# Unità amministrative dinamiche Get-MgDirectoryAdministrativeUnit -All -Property Id, DisplayName, MembershipRule | Where-Object { $_.MembershipRule -match 'memberof' } # Policy di auto-assignment (Entitlement Management) Get-MgEntitlementManagementAccessPackageAssignmentPolicy -All | Where-Object { $_.AutomaticRequestSettings.RequestAccessForAllowedTargets -ne $null }Per le policy di entitlement management è comunque consigliabile incrociare l’output con la revisione manuale in Entra ID Governance, dato che la struttura della regola può variare a seconda di come è stata configurata.Strategie di migrazioneUna volta identificate le configurazioni a rischio, Microsoft indica due strade principali:Sostituire la regola con operatori dinamici supportati (ad esempio basati su attributi utente o dispositivo), quando esiste un equivalente funzionaleConvertire a membership assegnata quando non è possibile replicare la logica di nesting con le regole standard, accettando la gestione manuale o tramite automazione esterna (es. script PowerShell schedulati o Logic App)In entrambi i casi, prima di considerare chiusa la migrazione bisogna validare concretamente: verificare che la membership finale del gruppo coincida con quella attesa, controllare che le assegnazioni di licenza, gli scope di Conditional Access e i pacchetti di accesso continuino a comportarsi correttamente, ed eliminare le configurazioni ormai inutilizzate invece di lasciarle come debito tecnico silente.ConclusioneIl ritiro di memberOf è un promemoria di un principio più generale nel cloud amministrato: le funzionalità in preview non vanno mai considerate stabili in produzione, per quanto risolvano un problema reale. Con circa tre mesi di margine dalla data di scrittura di questo articolo al 3 novembre 2026, il momento giusto per l’audit è ora, prima che il “congelamento” silenzioso della membership diventi un problema di accesso scoperto in produzione da un utente che segnala di aver perso l’accesso a un canale Teams.Fonte: Microsoft Learn – Configure dynamic membership groups with the memberOf operator, con approfondimenti da 4sysops e Petri IT Knowledgebase.

Il problema delle Throughput Unit staticheChi ha già lavorato con Azure Event Grid Namespaces conosce bene il concetto di Throughput Unit (TU): ogni TU definisce una capacità fissa di ingress/egress per gli eventi, di publish MQTT e di connessioni client MQTT. Fino ad oggi, il numero di TU andava impostato in fase di creazione del namespace e poi regolato manualmente ogni volta che il pattern di traffico cambiava — tipicamente sovradimensionando “per sicurezza” durante i picchi, con conseguente spreco di capacità (e di budget) nei periodi di bassa attività.Microsoft ha da poco introdotto in public preview la funzionalità Autoscale per Event Grid Namespaces (tier Standard), che elimina questa gestione manuale: il servizio monitora il carico e regola automaticamente le TU tra un minimo e un massimo configurati dall’amministratore.Come funziona AutoscaleIl funzionamento è deliberatamente semplice, in linea con la filosofia “meno configurazione, più automazione” che Azure sta applicando a diversi servizi PaaS. Event Grid valuta continuamente l’utilizzo su quattro categorie:Event ingress: tasso di eventi in ingresso sui namespace topic HTTP.Event egress: tasso di eventi in uscita verso i sottoscrittori.MQTT publish rate (inbound/outbound): frequenza dei messaggi pubblicati e ricevuti sul broker MQTT.MQTT client count: numero di client MQTT registrati e connessi.Quando una qualunque di queste metriche supera la soglia di scale-up, il servizio aggiunge automaticamente Throughput Unit. Quando tutte le categorie scendono sotto la soglia di scale-down, le TU in eccesso vengono rilasciate. L’amministratore non definisce policy o soglie personalizzate: si limita a impostare i limiti minimo e massimo di TU, e Event Grid gestisce internamente le decisioni di scaling.Un richiamo ai concetti di namespacePer chi non ha ancora familiarità con il modello a namespace di Event Grid (distinto dai topic “classici” di Event Grid Basic), vale la pena ricordare la struttura:Un namespace è un contenitore di gestione che espone un FQDN unico e due endpoint: uno HTTP per i namespace topic, uno MQTT per scenari IoT.I namespace topic supportano sia la pull delivery (il consumer si collega ed estrae i messaggi con semantica queue-like) sia la push delivery (attualmente verso Event Hubs come destinazione).Gli eventi pubblicati devono rispettare lo standard CloudEvents 1.0 del CNCF, con binding HTTP e formato JSON.Autoscale agisce a livello di namespace, quindi tutte le risorse contenute (topic, topic space MQTT, client, client group) beneficiano della stessa capacità elastica senza bisogno di scaling indipendente per ciascuna.Abilitare Autoscale: portale, ARM e REST APILa funzionalità, essendo in preview, va abilitata esplicitamente. Dal portale Azure basta aprire il namespace Event Grid, andare nella sezione di configurazione della capacità e attivare l’opzione Autoscale specificando TU minime e massime.Per chi gestisce l’infrastruttura as code, lo stesso risultato si ottiene via ARM template (o Bicep) impostando le proprietà di scaling sulla risorsa del namespace:{
 "type": "Microsoft.EventGrid/namespaces",
 "apiVersion": "2025-04-01-preview",
 "name": "ns-iot-produzione",
 "location": "westeurope",
 "sku": {
 "name": "Standard",
 "capacity": 4
 },
 "properties": {
 "isZoneRedundant": true,
 "topicsConfiguration": {},
 "publicNetworkAccess": "Enabled",
 "topicSpacesConfiguration": {
 "state": "Enabled"
 }
 }
}Nota: al momento della stesura la configurazione fine di Autoscale (min/max TU) va completata tramite portale o REST API dedicata, poiché lo schema ARM per questa preview è ancora in evoluzione — vale la pena controllare la pagina di supporto ufficiale prima di automatizzare il deployment in pipeline CI/CD.Via REST API, la capacità del namespace si legge e modifica sulla stessa risorsa esposta dall’API di gestione di Event Grid:GET https://management.azure.com/subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.EventGrid/namespaces/{namespaceName}?api-version=2025-04-01-previewQuando ha senso usarloAutoscale è pensato in particolare per due categorie di carico che chi lavora con architetture event-driven conosce bene:Workload IoT con MQTT: il numero di dispositivi connessi e il fan-out delle sottoscrizioni possono variare rapidamente (pensiamo a una flotta di sensori che si riattiva tutta insieme dopo un’interruzione di rete). Dimensionare le TU staticamente per il picco significa pagare capacità inutilizzata per la maggior parte del tempo.Event broker con traffico “a burst”: pipeline di ingestion che ricevono ondate di eventi correlate a batch job, deployment, o processi di business con picchi orari/giornalieri (fine mese, chiusura contabile, campagne marketing).Per i .NET developer che costruiscono microservizi basati su eventi, questo significa poter progettare la sottoscrizione a namespace topic senza dover stimare a priori il traffico di picco con lo stesso margine di sicurezza richiesto finora — riducendo sia il rischio di throttling sotto carico sia i costi nei periodi di quiete.ConclusioneAutoscale per Event Grid Namespaces arriva in un’area, il messaging event-driven, dove il dimensionamento manuale è da sempre un compromesso scomodo tra costo e resilienza. Essendo ancora in public preview, prima di adottarlo su workload di produzione critici vale la pena testarlo su un namespace non critico, verificando i tempi di reazione dello scaling automatico sotto carico reale e monitorando le metriche di throttling durante la fase di transizione tra un livello di TU e l’altro.Fonte: Petri IT Knowledgebase – Azure Event Grid Namespaces Add Autoscale for Dynamic Messaging Workloads; concetti tecnici da Microsoft Learn – Concepts for Event Grid namespace topics

Se la vostra organizzazione ha già spostato la maggior parte dei carichi rivolti agli utenti su Microsoft 365, Intune e Microsoft Entra ID, è lecito chiedersi perché esista ancora un Domain Controller che gira in produzione. La risposta più comune è “così abbiamo sempre fatto”, ed è esattamente la definizione di debito tecnico: un’infrastruttura che continua a costare in manutenzione, superficie di attacco e complessità operativa senza generare più un valore proporzionato. L’identità ibrida, con Entra Connect che sincronizza un Active Directory locale verso il cloud, è diventata per molte aziende proprio questo tipo di debito.Non si tratta di demonizzare l’ibrido: per organizzazioni con applicazioni legacy pesantemente dipendenti da NTLM, LDAP o Kerberos, mantenere un ponte con l’on-premise è spesso l’unica scelta razionale. Il punto è che la decisione va presa consapevolmente, dopo un inventario reale delle dipendenze, e non per inerzia.Perché il cloud-only conviene, quando è applicabilePer un’organizzazione che gira già prevalentemente su Entra ID, Microsoft 365 e client Windows moderni, il modello cloud-only centralizza la gestione IT e accelera l’accesso a nuove funzionalità di sicurezza che spesso arrivano prima, o esclusivamente, sui tenant che non dipendono più da sincronizzazione ibrida. I vantaggi concreti che spingono in questa direzione sono quattro:Riduzione del carico operativo: patching, alta disponibilità e scalabilità dei Domain Controller passano al provider cloud.Postura di sicurezza migliore: funzionalità come Conditional Access granulare, Identity Protection e governance degli accessi privilegiati sono nativamente più semplici da applicare senza il vincolo di compatibilità con AD locale.Costi più prevedibili: si eliminano hardware ridondante, licenze Windows Server per i DC e il tempo ingegneristico dedicato a mantenerli in salute.Velocità di adozione: nuove capacità (passkey, agenti AI con identità propria, automazioni Conditional Access) arrivano più rapidamente su tenant che non devono conciliarsi con un’infrastruttura ibrida.L’errore più comune: migrare l’infrastruttura prima di validare le dipendenzeIl fallimento tipico di un progetto cloud-only non è tecnico, è di sequenza: i team iniziano a spegnere server e migrare workload prima di aver mappato davvero cosa dipende ancora da Active Directory. Un approccio più solido segue queste fasi.1. Mappare i carichi di lavoro che bloccano il cloud-onlyPartite da un audit completo di infrastruttura, applicazioni, dati e dipendenze. Non fermatevi alla lista delle VM: cercate esplicitamente le dipendenze che raramente compaiono nei piani di migrazione di alto livello, perché sono quelle che tengono in vita Entra Connect molto più a lungo del necessario:Applicazioni che richiedono ancora query LDAP diretteService account legacy non documentatiApplicazioni con autenticazione NTLM hard-codedImpostazioni di Group Policy che nessuno ha mai rivistoServizi certificati (ADCS) che presuppongono un Domain Controller sempre raggiungibile2. Definire l’architettura cloud che volete davvero gestireStabilite obiettivi chiari su performance, disponibilità, sicurezza e compliance prima di scegliere gli strumenti. Decidete se una strategia single-cloud o multi-cloud è coerente con la vostra tolleranza al rischio e con le competenze del team, non solo con il marketing del vendor.3. Modernizzare l’identità prima di spegnere Active DirectoryQui sta il cuore del progetto. Rivedere la strategia IAM significa garantire autenticazione robusta, accesso a privilegio minimo e protezione dell’identità sfruttando gli strumenti nativi di Entra ID per unificare la gestione utenti su tutti i servizi, invece di replicare in cloud le stesse logiche pensate per un dominio locale.4. Ridisegnare la connettività attorno all’accesso cloud, non al data centerMolte architetture di rete sono ancora progettate assumendo che il traffico debba passare da un data center centrale. Un modello cloud-only ribalta la logica: la connettività va progettata per l’accesso diretto ai servizi cloud, sfruttando le backbone dei provider e i servizi di sicurezza integrati, sia per utenti in ufficio sia da remoto.5. Trattare le applicazioni legacy come il vero collo di bottigliaFile share, servizi di stampa, applicazioni gestionali interne e integrazioni con piattaforme di terze parti datate sono i blocchi reali dei progetti cloud-only, molto più della migrazione di VM o storage. Un’applicazione finance che si aspetta autenticazione Windows integrata, un sistema di magazzino che dipende da query LDAP o una file share con permessi ereditati da anni possono rallentare il progetto più di qualunque altro fattore. Per ciascuna, valutate lift-and-shift, refactoring o riscrittura in base a complessità e valore strategico.6. Ricostruire la governance per un modello operativo cloud-firstAggiornate le policy per riflettere una postura cloud-first, automatizzate il reporting di compliance e sfruttate strumenti di sicurezza nativi cloud per cifratura, rilevamento minacce e incident response, invece di adattare policy pensate per l’on-premise.7. Preparare il team IT al cambio operativoInvestite nella formazione sulle competenze cloud-specifiche, comunicate i cambiamenti con chiarezza e create canali di supporto e feedback per intercettare problemi prima che diventino bloccanti.Cosa si rompe per primo in una migrazione cloud-onlyAnche con una pianificazione accurata, alcuni punti critici emergono quasi sempre:Dipendenze nascoste da Active Directory: connessioni LDAP hard-coded, service account non gestiti, applicazioni dipendenti da NTLM o flussi di autenticazione mai documentati. Vanno inventariati prima di ritirare i Domain Controller o disattivare la sincronizzazione.Blocchi operativi da Conditional Access e MFA: l’enforcement di Conditional Access e multi-factor authentication migliora la sicurezza, ma una sequenza sbagliata può bloccare fuori gli amministratori o interrompere l’accesso a servizi critici. Testate sempre account di emergenza, opzioni di rollback e flussi di accesso privilegiato prima di un enforcement ampio.Resistenza culturale: il cambiamento comporta rischio percepito; serve chiarezza sui benefici e sui nuovi ruoli per ridurre lo scetticismo dei team.Interruzioni di servizio: pianificate la migrazione a fasi, con pilot e backup, per minimizzare l’impatto sul business.Il test pratico per capire quanto siete lontani dal cloud-onlySe la vostra organizzazione ha già adottato Microsoft 365, Intune ed Entra ID per la maggior parte dei carichi rivolti agli utenti, l’identità ibrida va trattata come debito tecnico, a meno che non abbiate una ragione precisa e documentata per mantenerla. Prima di pianificare una migrazione cloud-only, identificate ogni dipendenza residua da Active Directory: se la maggior parte supporta già l’autenticazione moderna, probabilmente siete più vicini al cloud-only di quanto pensiate.Per i sistemisti che gestiscono ambienti Microsoft, il consiglio pratico è iniziare da un inventario mirato: interrogate Entra Connect per capire quali oggetti sincronizzati sono ancora effettivamente in uso, verificate quali applicazioni autenticano ancora tramite Kerberos/NTLM controllando i log di sicurezza dei Domain Controller, e mappate le Group Policy applicate per capire quali impostazioni di sicurezza andranno ricreate tramite Intune prima di spegnere l’ultimo controller di dominio.ConclusioneLa migrazione a cloud-only non è un progetto infrastrutturale, è un progetto di identità. Le organizzazioni che falliscono di solito partono dal lato sbagliato del problema, migrando VM e storage prima di aver capito cosa dipende ancora da un dominio Active Directory che nessuno ha mai documentato del tutto. Chi parte invece dall’inventario delle dipendenze di identità, tratta l’ibrido come uno stato temporaneo e non come un’architettura permanente, arriva a un ambiente più semplice da gestire, più sicuro per costruzione e meno costoso da mantenere nel tempo.Fonte: Why Hybrid Identity Becomes Technical Debt and How to Move to Cloud-Only, Petri IT Knowledgebase (Dean Ellerby).

Chi gestisce ambienti SQL Server on-premises conosce bene il problema: la migrazione verso il cloud richiede quasi sempre di mettere insieme tool diversi per la valutazione, il trasferimento dei dati, il monitoraggio e infine il cutover. Ogni fase ha strumenti propri, competenze diverse e margini di errore che si sommano. Con l’annuncio della disponibilità generale (GA) della migrazione a SQL Server su macchine virtuali Azure tramite Azure Arc, Microsoft porta l’intero ciclo di vita della migrazione dentro un’unica esperienza guidata nel portale Azure, lo stesso modello già usato per le migrazioni verso Azure SQL Managed Instance.Per chi amministra data center misti, con carichi legacy e SQL Server sparsi su fisico e virtuale, questa novità merita attenzione: non è solo un annuncio di marketing, ma un cambio concreto di flusso di lavoro operativo.Cos’è cambiato con la GAFino a poco tempo fa, chi voleva spostare un’istanza SQL Server su una VM Azure doveva combinare Azure Migrate, Database Migration Service e strumenti di backup/restore manuali, gestendo ciascuno con logiche e dashboard separate. Con la funzionalità di migrazione integrata in Azure Arc, il processo si consolida in quattro fasi accessibili da un singolo pannello, il Database Migration, associato all’istanza SQL Server abilitata da Arc:Assess source instance — valutazione di leggibilità e readiness dell’istanza sorgenteSelect target — scelta o creazione della VM SQL Server di destinazioneMigrate data — trasferimento effettivo dei databaseMonitor and cutover — monitoraggio della sincronizzazione e passaggio finale in produzioneLa discovery delle istanze e la generazione dei report di readiness avvengono automaticamente ogni fine settimana, ma possono essere lanciate anche manualmente, senza configurazioni aggiuntive: la funzione è disponibile di default per tutte le istanze SQL Server abilitate da Arc a partire da SQL Server 2012 (11.x).Copilot integrato nel flusso di migrazioneUna parte interessante della nuova esperienza è l’integrazione di Microsoft Copilot direttamente nel pannello di migrazione. Non si tratta di un chatbot generico: interroga la knowledge base Microsoft nel contesto specifico della vostra migrazione e risponde a richieste operative come:Come vengono eseguite le valutazioni? Aiutami a confrontare le opzioni di destinazione Avvia la migrazione Aiutami a scegliere il metodo di migrazione corretto Monitora la migrazione in corso Completa la migrazionePer un DBA che gestisce decine di istanze, questo significa poter chiedere direttamente nel pannello “quale VM SKU è consigliata per questo carico?” invece di andare a cercare tabelle di sizing nella documentazione.Come funziona la migrazione via backup e restoreIl meccanismo sotto il cofano non è nuovo per chi ha familiarità con le migrazioni SQL Server classiche: si basa su backup e restore con log shipping continuo, pensato per supportare scenari di migrazione online con downtime minimo.Viene eseguito un backup completo del database sorgenteIl backup viene caricato su un account di Azure Blob Storage intermedioIl backup viene ripristinato sull’istanza SQL Server target sulla VM AzureI backup dei log delle transazioni vengono caricati in continuo sullo stesso storage e applicati automaticamente al database target, mantenendolo sincronizzatoAl momento del cutover, Azure Arc applica l’ultimo backup caricato e porta online il database targetUn vincolo operativo da tenere a mente in fase di progettazione: l’account di Azure Blob Storage e la VM SQL Server target devono trovarsi nella stessa region Azure. È un dettaglio facile da trascurare se si pianifica la migrazione partendo dalla region “storica” dell’organizzazione invece che da quella scelta per il nuovo carico.Prerequisiti praticiUna subscription Azure attivaL’istanza SQL Server deve essere abilitata da Azure Arc con l’estensione più recente installata (l’estensione si aggiorna indipendentemente da SQL Server, quindi va controllata separatamente)L’ambiente sorgente preparato secondo le linee guida ufficiali, incluso l’upload iniziale dei backup nello storage accountPer verificare rapidamente la versione dell’istanza sorgente prima di avviare l’assessment, un semplice controllo T-SQL è sempre un buon punto di partenza:SELECT SERVERPROPERTY('ProductVersion') AS Versione, SERVERPROPERTY('Edition') AS Edizione, SERVERPROPERTY('EngineEdition') AS TipoMotore;Cosa considerare prima di partireIl pannello di monitoraggio e cutover mostra in tempo reale quali database sono migrati con successo, quali sono ancora in corso, il metodo di migrazione scelto, la durata della sincronizzazione e i log dettagliati. Quando lo stato passa a “Ready for cutover”, si può decidere il momento esatto del passaggio in produzione selezionando Cutover, con opzioni diverse in base al metodo di migrazione utilizzato.Va detto che, come per ogni migrazione basata su backup/restore, restano da valutare a parte gli aspetti di sizing della VM di destinazione (storage, IOPS, memoria per il buffer pool), la licenza SQL Server (Hybrid Benefit se applicabile) e la strategia di alta disponibilità post-migrazione, che questo strumento non copre direttamente ma per cui l’assessment fornisce indicazioni.ConclusionePortare discovery, assessment, migrazione e monitoraggio in un’unica dashboard riduce sensibilmente l’attrito operativo delle migrazioni SQL Server verso Azure, soprattutto per i team che gestiscono ambienti ibridi complessi con decine o centinaia di istanze. Non elimina la necessità di pianificazione — region, sizing e licensing restano decisioni da prendere a monte — ma consolida in un solo posto ciò che prima richiedeva più tool scollegati tra loro. Per chi ha già istanze abilitate da Azure Arc, vale la pena aggiornare l’estensione e lanciare un primo assessment anche solo per farsi un’idea della readiness del proprio parco macchine.Fonte: Petri IT Knowledgebase e documentazione Microsoft Learn.