Due domande decidono il percorso

Ogni scenario di migrazione SAP verso Azure si risolve rispondendo a due domande, in quest’ordine. La prima: il database di destinazione è lo stesso di quello di origine? La seconda: quanto fermo può tollerare il business? Il resto — strumenti, sequenza dei passi, architettura target — discende da qui.

Se la piattaforma di database non cambia, si parla di migrazione omogenea: i dati restano nel formato nativo del motore e lo spostamento è, concettualmente, una copia. Se la piattaforma cambia — il caso più frequente è il passaggio ad SAP HANA nell’ambito di una conversione a SAP S/4HANA — si parla di migrazione eterogenea: i dati vanno esportati dal formato di origine e ricaricati in quello di destinazione, con una conversione vera e propria.

Prima di entrambe viene sempre l’assessment. Inventario della landscape, dipendenze fra application server e database, raccolta dei dati di carico dal sistema esistente per tradurli in SAPS e scegliere le VM sulla lista di quelle certificate SAP (o Azure Large Instances quando l’istanza HANA eccede quanto una VM può offrire), dimensionamento dello storage per /hana/data e /hana/log fra Premium SSD, Ultra Disk e Azure NetApp Files. Azure Migrate è lo strumento di discovery, dependency mapping e assessment dell’infrastruttura, e fornisce anche la replica delle macchine virtuali per il lift-and-shift: non sostituisce il sizing SAP, lo affianca.

Migrazione omogenea

Con lo stesso motore di database su entrambi i lati, le opzioni sono quelle native della piattaforma: backup e restore, oppure una forma di replica (log shipping, mirroring, Always On per SQL Server, HANA System Replication quando l’origine è già HANA). La logica è: si porta in Azure una copia consistente, la si mantiene allineata con l’applicazione dei log mentre il sistema di origine resta in produzione, e la finestra di fermo si riduce all’ultimo allineamento più il cutover applicativo e di rete.

Un caso limite dell’omogenea è il rehost puro: si replica l’intera macchina virtuale verso Azure e si accende dall’altra parte. Il database non viene convertito, la versione SAP non cambia, il sistema operativo neppure. È la scelta quando il requisito è “spostare”, non “trasformare”.

Migrazione eterogenea e DMO

Quando si cambia motore di database, lo scenario tipico d’esame è la conversione verso HANA. Qui entra il DMO (Database Migration Option) del Software Update Manager: una singola procedura che combina l’aggiornamento del software SAP e la conversione del database, evitando la sequenza “prima aggiorno, poi migro” con due fermi distinti. Due caratteristiche contano per l’esame: il DMO consuma una sola finestra di downtime, e il database di origine resta intatto, il che rende possibile un fallback se la procedura non va a buon fine.

La variante DMO with System Move aggiunge lo spostamento fisico: l’export prodotto sul sistema di origine viene trasferito e il sistema atterra direttamente sull’host di destinazione in Azure, senza passare da un’installazione intermedia. È la risposta canonica allo scenario “on-premises su database non-HANA, target HANA su Azure, un solo fermo”.

Il criterio finale è semplice e conviene memorizzarlo così: cambio di piattaforma database + fermo unico → DMO (con System Move se il target è in un’altra sede); nessun cambio di piattaforma, solo spostamento → rehost con replica.

Trappole tipiche d’esame

  • Migrazione a HANA con una sola finestra di fermo → DMO di SUM: le opzioni che propongono export/import classico con SWPM o “prima l’upgrade, poi la migrazione” richiedono due fermi e sono la risposta sbagliata quando il requisito è “un solo downtime”.
  • Spostare la landscape senza cambiare database → rehost con replica di VM: il DMO non converte nulla se il motore resta lo stesso, quindi in uno scenario same-database è sovradimensionato e fuori tema.
  • Sistema di origine da preservare per il fallback → DMO (in particolare con System Move): la procedura non modifica il database sorgente; una migrazione in-place o un upgrade diretto invece lo consumano.
  • “Serve un assessment prima di migrare” → Azure Migrate: raccoglie inventario e dipendenze, ma non produce il sizing SAP; SAPS e VM certificate restano il vincolo, e una VM non certificata non è supportata anche se ha CPU e RAM sufficienti.
  • Downtime minimo con stesso database → backup/restore più applicazione dei log o replica nativa: una copia a freddo dell’intero volume dati allunga il fermo in proporzione alla dimensione del database.
  • Destinazione HANA troppo grande per una VM → Azure Large Instances: la scelta dello strumento di migrazione non cambia, ma la piattaforma target sì; non confondere il vincolo di sizing con quello di conversione.

L’esame AZ-120 è in lingua inglese, con passing score 700/1000. Per numeri di SAPS, dimensioni supportate e matrici di certificazione fai sempre riferimento alla documentazione Microsoft e alle SAP Note ufficiali, che cambiano nel tempo.