Migrare in cloud è un’attività complessa. Una volta convinto il cliente che sia la scelta più opportuna per supportare le sue esigenze, il fornitore It deve rimboccarsi le maniche e procedere per comparti.
Può anche succedere che, su ambienti particolarmente complessi, sia necessario l’intervento di un pool di fornitori It, ognuno con la sua specializzazione. Ma tra tutte le attività, migrare in cloud le applicazioni è certamente la più complessa e delicata.
Dopo aver scelto gli ambienti cloud su cui migrare è fondamentale accertarsi che tutte le applicazioni di produttività siano portabili senza alcun rischio di perdita di archivi e di funzionalità. Visto l’interesse crescente di questo tipo di piattaforme, migrare in cloud rappresenta un’ottima opportunità per le software house e per i system integrator con un adeguata struttura di sviluppo.
[Vuoi conoscere la strada migliore per portare i tuoi clienti e le tue applicazioni in cloud? Il prossimo 12 marzo va in onda una straordinaria puntata della Azure Academy.
Un giorno intero dedicato alla migrazione in cloud con alcuni tra i massimi esperti italiani. Qui la registrazione per la sessione della mattina – Qui la registrazione per la sessione del pomeriggio e di seguito la video intervista esclusiva con Michele Aponte che ci regala qualche anticipazione]
Migrare in cloud: 5 situazioni classiche e come risolverle
In questo post vogliamo segnalare i 5 scenari più comuni all’interno di un progetto di migrazione delle applicazioni in cloud. 5 scenari che certamente ogni software house si troverà ad affrontare in un progetto di migrazione al cloud.
Prima di tutto ricordiamo che una migrazione di un software da una piattaforma all’altra si configura come un trasferimento di dati, profili e funzionalità. In generale, ci si può muovere da una struttura on premise al cloud, da un server a un altro e anche da un cloud all’altro. In fondo, migrare in cloud è un caso particolare di migrazione di un software, con qualche distinguo.
LEGGI ANCHE: Cosa fa uno sviluppatore oggi e perché deve aggiornarsi
Per esempio, si deve sempre tenere a mente che ci si sta muovendo verso un’architettura con alcune peculiarità. Se, da una parte, ci si guadagna certamente in performance, gestione e integrazione di funzionalità, c’è anche da mettere in conto l’anzianità e la complessità dell’ambiente di partenza o il software che si vuole trasferire e la “disponibilità” della piattaforma cloud.
Il livello di complessità della migrazione dipende da diversi fattori come la struttura e la “openess” del software di terze parti utilizzato, il numero di profili coinvolti, l’interazione con altri applicativi e database, l’allocazione di dati di archiviazione. Bene, partiamo con i 5 scenari più comuni e le pratiche relative consigliate.
Dall’Erp al database, in primis tutela il dato
1. L’affinità funzionale. Prima di tutto, realizzare una mappa. Ovvero, catalogare tutte le funzionalità – in particolare le personalizzazioni e i link con altri applicativi – del “vecchio” software e accertarsi prima di poter continuare a lavorare allo stesso modo nel nuovo ambiente.
2. L’incubo Erp. L’applicativo per la gestione amministrativa è presente in tutte le aziende del mondo In Italia, poi, abbiamo un’antichissima tradizione di Erp “legacy” realizzati da decine di software house. Applicativi di antica concezione, spesso non standard e rattoppati negli anni. Ma costano, e il cliente non vorrebbe sacrificarli. Sarà un possibile bagno di sangue. Bisogna solo sperare che la software house abbia già previsto una versione cloud del suo applicativo. Se non è così, il processo sarà lungo, faticoso, pieno di insidie e di riscritture di codice. Vuoi una scorciatoia? Usa le macchine virtuali.
3. L’affaire Database. Anche i database sono ben presenti in azienda. E, sebbene in numero minore, potremmo trovarci in una condizione simile a quella degli Erp. Nel caso dei database, però, ciò che deve essere assolutamente tutelato non è tanto la funzionalità, spesso replicabile, ma il dato. La migrazione di uno o più database deve avere due obiettivi: nessuna perdita di dati e totale similitudine di funzionalità e di connettori di integrazione applicativa.
E poi, esegui una profonda analisi preliminare del nuovo ambiente
4. Il sito e l’ecommerce. Migrare i contenuti di un sito aziendale è impresa ardua. Non è prioritario? Andiamolo a spiegare a chi vive di ecommerce. Sebbene le architetture dei Cms (Content Management Systems), in quanto servizi web, siano più indipendenti dall’ambiente, anche in questo caso l’attenzione deve essere massima al corretto porting dei contenuti e alla tutela delle integrazioni con gli altri applicativi come i database.
5. Da cloud a cloud. Magari alcuni software di produttività aziendale a uso quotidiano sono già in cloud e nessuno lo sa. Ebbene, eseguire il porting di un servizio di produttività da un cloud all’altro, anche in questo caso, è una questione di tutela del dato. Dove sono i documenti condivisi? Come organizzarne la trasformazione con la garanzia di non perderne nessuno? Sono queste le domande da porsi. Primo step? Organizza una mappa dettagliata dei repository e assicurati che si possa eseguire l’esportazione con garanzia di piena compatibilità dei documenti.
[Vuoi sapere tutto sul cloud e su come “venderlo” ai tuoi clienti? Scopri tutto grazie alla nuova puntata della Azure Academy il 12 Marzo alle 9,30. Qui tutti i dettagli e il programma completo]
