Nei post precedenti abbiamo affrontato i motivi e i benefici di una migrazione verso SAP Hana. Una volta considerato lo scenario di riferimento, la migrazione vera e propria è possibile attraverso tre strade alternative. Queste opzioni differenti danno vita a procedure peculiari ma hanno un unico obiettivo, quello di portare i sistemi scelti sul database in-memory della piattaforma di SAP. I modelli da seguire sono questi: nuova installazione con successiva ripresa dati, migrazione classica e migrazione tramite “DMO of SUM”. Andiamo a fondo, considerando gli step operativi di ognuno. Ma prima spieghiamo brevemente cosa può comportare una migrazione del database non effettuata correttamente.
Potrebbe sembrare superfluo ricordarlo, ma è fondamentale che la migrazione del database sia effettuata correttamente. È un processo delicato che va pianificato accuratamente, pena la perdita di dati indispensabili per il funzionamento delle applicazioni mission critical come l'ERP o l'insorgere di incompatibilità tra sistemi legacy e nuova piattaforma gestionale. Tutta l'efficienza e i benefici che si possono ottenere grazie all'adozione dell'in-memory database di SAP HANA rischiano di essere vanificati se non si svolge, possibilmente guidati da un partner esperto, un'intensa attività di assessment della natura delle risorse da trasferire.
Dopo aver valutato con attenzione cosa bisogna salvare, cosa dev'essere cambiato e cosa invece conviene eliminare, è necessario capire se conviene scegliere per la migrazione dati un approccio greenfield oppure un approccio brownfield. Optare per il primo vuol dire creare un ambiente ex novo, appositamente progettato per le esigenze dell'impresa in funzione della nuova piattaforma. Ciò implica il massimo grado di compatibilità tra architettura e parco applicativo, ma comporta la perdita dei dati fino a quel momento raccolti ed elaborati. L'approccio brownfield consiste nel portare su S/4 Hana tutto ciò che viene valutato indispensabile nel nuovo ambiente, costruendo connettori e traduttori in grado di garantire la continuità di business anche con la stratificazione dei software e dei dati.
L’opzione più semplice è quella che prevede una nuova installazione. Un simile panorama si ottiene con la configurazione di nuove macchine e con un avvio da zero, pulito, effettuando poi una ripresa dati applicativa dai sistemi pre-esistenti, declinandoli in totale verso SAP Hana. Per raggiungere tale obiettivo ci viene in aiuto la piattaforma SAP Landscape Transformation, che consente di ottenere, tramite uno sforzo ridotto, un risultato mirato, grazie all’automazione di alcune operazioni, come la creazione di shell con opzioni carve-out e il consolidamento del sistema. In aggiunta a ciò, altri servizi, tra cui Data Management Services o System Landscape Optimizing, permettono di seguire le procedure di migrazione pur lasciando la maggior parte delle attività nelle mani dei software.
Attraverso questa migrazione è possibile portare il sistema verso il database Hana tramite upgrade graduali. Il numero di questi upgrade dipende dalla release di partenza del sistema, è può essere pari a zero se il sistema di origine è già stato aggiornato ai livelli minimi richiesti per la migrazione al database Hana. Al termine di queste attività sul sistema sorgente si può procedere alla migrazione dei database. La migrazione fatta con passaggi progressivi permette, tramite punti di ripristino e in casi estremi, di tornare all’ultimo stato disponibile, dal quale far riprendere la migrazione.
I momenti in cui si divide il processo di migrazione classica sono tre. Nel primo avviene la preparazione degli ambienti con procedure quali lo split dual-stack e la conversione in linguaggio Unicode. In seguito, l’attività di upgrade porta i sistemi ad un livello maggiore di SAP enhancement packages. Solo alla fine di queste fasi si potrà effettuare la migrazione verso Hana.
La Database Migration Option (DMO) of Software Update Manager (SUM) comprime in una sola operazione sia l’upgrade del sistema che la migrazione dei database. Questa migrazione introduce una complessità tecnica nel momento del passaggio al nuovo database, ma riduce le attività progettuali applicative e permette di fare il passaggio in un unico momento, definito “big bang”
Ad oggi, la migrazione via DMO sta divenendo uno standard in ambito SAP. Tuttavia, la presenza di requisiti di sistema minimi apre la strada alle altre due vie alternative sopra descritte. La seconda scelta è allora quella della migrazione classica, magari con un software previsionale, che aiuta a stendere un programma dettagliato sul da farsi. Per tutte le eccezioni resta l’installazione nativa, forse più onerosa in termini di costi e tempi ma ottimizzabile attraverso la creazione di shell e carve-out che isolano aree e destinazioni di intervento, permettendo di poter ridisegnare i processi del sistema SAP allineandoli in modo semplice con i mutati processi aziendali.