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.
Migrazione su SAP Hana: cosa comporta la migrazione del database in modo scorretto
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.
Approccio greenfield e approccio brownfield, cosa cambia per la migrazione dati
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.
Migrazione su SAP Hana, nuova installazione?
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.
I benefici della nuova installazione nella migrazione a SAP Hana
- Fornisce l'opportunità di correggere i problemi dell’anzianità del ciclo di vita del sistema in esercizio (consolidamento del sistema e armonizzazione dei dati inclusi)
- Aumenta la flessibilità offrendo una migrazione selettiva (solo su dati specifici senza interruzione dell’attività; pulizia di aree peculiari; riduzione della ridondanza)
- Semplifica l’introduzione di nuovi processi di business (ad esempio in ambito contabile)
- Minimizza il downtime dei servizi
La migrazione a SAP Hana classica
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 benefici della migrazione classica a SAP Hana
- Permette di spalmare nel tempo le attività di migrazione, semplificando tematiche di budget.
- Semplifica il lavoro sui sistemi da migrare e la complessità dell’intero progetto grazie alla separazione dell’attività in più task successivi.
Le fasi della migrazione classica
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 migrazione a SAP Hana con DMO of SUM
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”
I benefici di una migrazione SAP Hana via DMO
- Riduce le operazioni di migrazione applicativa e i tempi complessivi del progetto
- Abbassa i prerequisiti per il supporto delle release SAP Hana e DB
- Minimizza la presenza di punti di ripristino per fallback vista la possibilità di una riattivazione dei database originali in qualunque momento
- Realizza una sola fase di downtime, riducendolo a poche ore per alcuni scenari di portata limitata
Qual è la migliore opzione per migrare a SAP Hana?
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.
