La migrazione al cloud può seguire percorsi diversi: trova quello giusto per te

Nella vita ci sono momenti in cui le tue stesse parole ti stupiscono. Per alcuni è trovarsi all’improvviso a dire “mi sembra di sentire mia madre”. Forse è successo anche a me, ma non lo ammetterò mai. Mi è capitato invece di recente di sentirmi dire che le strategie di migrazione mi affascinano. 

Ebbene sì, trovo veramente avvincente il modo in cui un’organizzazione migra un processo aziendale esistente dall’infrastruttura precedente a Snowflake Data Cloud. Perché? Perché è una sfida complessa. Nel caso di Snowflake, si tratta di trasferire un database legacy, pipeline di dati e un layer di consumo con strumenti per la creazione di report e l’analisi dei dati, oltre agli stessi report e alle dashboard. Per farlo è necessario tenere conto non solo della tecnologia, ma anche delle persone e dei processi. Sicuramente c’entra qualcosa anche il fatto che la storia che ha suscitato il mio interesse sia stata raccontata da uno dei miei clienti preferiti (no, no, non faccio favoritismi).

Per anni sono stata convinta che il passaggio a una nuova architettura non debba essere un “big bang”. Alcuni anni fa il Chief Data Officer di un’azienda di abbigliamento outdoor mi disse che aveva progettato una nuova architettura di dati, ma che l’avrebbe lanciata in produzione solo dopo avere completamente popolato il data lake. Voleva fare tutto nel modo migliore e non voleva che la piattaforma venisse utilizzata prima di essere pronta. Intanto erano già passati diversi anni. 

Un altro CDO mi raccontò invece il suo approccio in più fasi, partendo dal basso. Piuttosto che annunciare all’azienda che stava creando un framework comune (e lasciare tutti ad aspettare che fosse pronto), il team aveva lavorato a stretto contatto con ogni business unit per fornire gli insight necessari, ma in modo tale che tutto si adattasse a una struttura di back‑end e strumenti di visualizzazione comuni. Col tempo, il team aveva creato un nuovo “archivio aziendale di informazioni” con dashboard condivise tra tutti i brand. La rivelazione finale era stata una sorpresa per gli stakeholder aziendali, ma non un “big bang” dal punto di vista della migrazione. Nessuno aveva aspettato anni per ricevere gli insight necessari. Era stato fornito valore in ogni fase del processo incrementale. Queste storie hanno fatto di me una convinta sostenitrice dell’approccio incrementale… fino a poche settimane fa.  

Il mese scorso ho partecipato allo Snowflake Data Cloud World Tour a Toronto. È stato favoloso, con presentazioni avvincenti e conversazioni a margine ancora più interessanti. Durante una pausa mi sono trovata in compagnia delle responsabili dei dati di un retailer e di un assicuratore canadesi e abbiamo iniziato a parlare di strategie di migrazione. Ebbene sì. 

Allora ho citato una recente conversazione con un altro cliente che si trovava in difficoltà. Stava lavorando meticolosamente alla migrazione alla sua architettura di destinazione ideale e progettava un “big bang”, e mi ha ricordato quell’azienda di abbigliamento. Tutte hanno annuito. Quando però ho parlato dell’approccio alternativo, ossia quello incrementale, una delle mie interlocutrici mi ha contraddetta. Secondo la sua esperienza, la best practice era proprio un big bang: fai quello che devi fare, e fallo in fretta! Nel suo caso, la strategia di migrazione era stata un trasferimento completo senza modifiche, il classico “lift and shift”. Nessuna riprogettazione immediata, solo uno spostamento sulla nuova architettura. La sua organizzazione partiva da una piattaforma legacy on‑premise, insufficiente a soddisfare le sue esigenze attuali e costosa da mantenere. Grazie al veloce trasferimento senza modifiche, non avevano dovuto mantenere due sistemi in esecuzione allo stesso tempo. Inoltre, liberarsi definitivamente del vecchio sistema era una priorità. 

Ma la storia non era finita. Nonostante il trasferimento sulla nuova piattaforma, non tutti i report e le dashboard producevano valore. È proprio questa la sfida dell’approccio “lift and shift”. Si finisce per portarsi dietro pesi superflui. 

La soluzione? Nel caso della mia interlocutrice, si è trattato di disattivare tutto. Proprio così: tutti gli 80.000 report e dashboard migrati sono stati disattivati. E naturalmente ci sono state rimostranze, ma meno di quanto potessero immaginare. Non tutti i report avevano folle di ammiratori. Solo 3000 circa sono stati riattivati. Tutto è bene ciò che finisce bene. E per fortuna questa responsabile dei dati canadese ha i nervi d’acciaio.

In conclusione, la migrazione è una sfida, ed è necessario prendere in considerazione approcci diversi. Ci sono due decisioni da prendere: la strategia di migrazione vera e propria e l’approccio alla transizione. 

L’approccio alla transizione può essere descritto come un “big bang” o un trasferimento “in più fasi”.

• Big bang: una migrazione dalla piattaforma esistente alla nuova piattaforma che viene effettuata in una sola operazione, in un unico momento, e fornisce i suoi vantaggi in quel momento.
• Approccio in più fasi: una migrazione della piattaforma suddivisa in porzioni ragionevoli e implementata gradualmente nel tempo, che fornisce vantaggi incrementali al termine di ogni fase.

Le strategie di migrazione, a loro volta, dipendono da ciò che si vuole spostare e dalla destinazione desiderata. Se non si vogliono apportare modifiche immediate, si possono prendere i dati esistenti e trasferirli così come sono nella nuova piattaforma. Se si preferisce fare subito le modifiche, è possibile “correggere” o riprogettare prima di spostare i dati. E si può utilizzare l’approccio alla transizione che risulta più efficace. Ci sono sempre dei pro e dei contro.

La figura seguente illustra tre comuni strategie di migrazione. 

In ultima analisi, non esiste una soluzione adatta a tutte le esigenze. L’approccio giusto dipende dall’organizzazione, dalla piattaforma esistente e dalla propensione al cambiamento dell’azienda. Il trasferimento senza modifiche potrebbe non essere la soluzione ottimale. Certo, è veloce e sposta tutto in una sola volta, compresi i pesi superflui però. Quella conversazione in Canada mi ha insegnato che a volte si può preferire questa strada. L’essenziale è fornire valore il più rapidamente possibile, che si tratti di quello incrementale offerto dalla nuova piattaforma con un approccio in più fasi o del big bang spettacolare che ha abbattuto la costosa piattaforma legacy. 

Secondo il team Professional Services di Snowflake, indipendentemente dalla strategia di migrazione scelta, ci sono alcuni passaggi fondamentali da seguire:

• Fai una prova: identifica un caso d'uso iniziale che fornisca valore aziendale e con il quale sperimentare la migrazione dalla piattaforma attuale a Snowflake.
• Definisci la portata: in base alle lezioni ricavate da questo progetto pilota, identifica gli elementi da includere o escludere dall’ambito della migrazione dalla piattaforma attuale a Snowflake.
• Pianifica: crea un piano di migrazione con i costi, le tempistiche, le attività e le risorse richieste per migrare a Snowflake.

Inoltre, assicurati di avere tutte le informazioni necessarie per prendere le decisioni relative alla migrazione. Il questionario riportato di seguito, tratto dalla valutazione della preparazione alla migrazione di Snowflake, è un ottimo punto di partenza.

Se ti interessa scoprire come Snowflake può aiutarti durante e dopo la migrazione, dai un’occhiata ai nostri Snowflake Professional Services e ai programmi di formazione e training di Snowflake.