Migrazione da Google Workspace a Microsoft 365: quale approccio scegliere?

Nel precedente articolo abbiamo scoperto, grazie all’integrazione di Microsoft alle API di Google, quanto sia semplice eseguire una migrazione dei contenuti da Google Workspace a Microsoft 365 mantenendo un’alta collaborazione tra i due ambienti di lavoro nella fase di transizione.

In questo articolo, invece, parleremo di quali potrebbero essere i percorsi migliori da intraprendere quando si affronta un progetto che ha lo scopo di cambiare così radicalmente il metodo e gli strumenti di lavoro degli utenti.

Prima di tutto, è necessario analizzare i dati nella sorgente (Google Workspace) per raccogliere tutte le modalità di utilizzo che se ne fa, poi è necessario valutare il numero di utenti in relazione al supporto IT interno. Questi due fattori sono essenziali per scegliere una delle due macrocategorie di migrazione, che sono CutOver e Staged.

In cosa consistono questi due approcci? In cosa si differenziano?

CutOver

Una migrazione di tipo CutOver indica una copia dei dati che si ripete più volte per tenerli allineati all’ambiente di produzione fino al giorno di “CutOver”, appunto, dove tutti gli utenti, in un unico momento, smetteranno di utilizzare il vecchio sistema e inizieranno ad utilizzare il nuovo.

I vantaggi di questo metodo di migrazione:

• richiede meno sforzi organizzativi nell’individuare i gruppi di utenti affini;
• non richiede una fase di coesistenza dove i due ambienti debbano collaborare, riducendo parte dell’attività tecnica di implementazione e manutenzione;
• non genera disomogeneità tra gli utenti che, generalmente, causa rallentamenti nella fase di risoluzione dei problemi da parte del supporto di primo livello;
• i tempi del progetto sono più brevi.

I contro del CutOver:

• gli utenti si troveranno tutti in difficoltà nell’utilizzo della nuova piattaforma nello stesso momento, diminuendo la prduttività per il primo periodo e chiedendo più supporto;
• mediamente, in un progetto di migrazione si stimano dal 15 al 20% di utenti con problemi, più o meno impattanti, dovuti al trasferimento dei dati o all’accesso alle nuove risorse. L’IT di primo livello e le escalation al team di progetto dovranno far fronte al 20% del totale degli utenti;
• alcuni applicativi del vecchio ambiente (o quelli che si integravano con lo stesso) potrebbero non essere pronti per la data di CutOver, rischiando di dover chiedere agli utenti di dover comunque utilizzare le due realtà;
• i processi di RollBack (tornare alla vecchia soluzione), alcune volte sono impraticabili senza una perdita degli ultimi dati dopo il giorno di cambio;
• il tempo che intercorre tra lo stop degli utenti e il CutOver (in genere dal venerdì sera alla domenica) potrebbe non essere sufficiente alla copia dei dati, in caso di numeri molto elevati.

Staged

Una migrazione di tipo Staged è, tra le due, la più lunga e la più complessa, sia in termini di preparazione che in termini di rilascio.

Lo scopo di questo approccio è quello di spostare gli utenti sulla nuova soluzione per piccoli gruppi, permettendo un passaggio più graduale e controllato e consentendo il passaggio dei workload a step, se pertinente al solo gruppo migrato.

I vantaggi dell’approccio Staged:

• limitando il numero di utenti - e considerando sempre il 20% di problemi- si riduce notevolmente il carico del supporto e del team di progetto nell’evadere le richieste degli utenti;
• In un ambiente in cui si hanno molto applicativi o particolarità, permette di unire i workload al gruppo che sarà spostato nel loro giorno di calendario (wave), garantendo una preparazione a tavolino del passaggio di una o di un piccolo gruppo di applicazioni, permettendo così un focus sull’attività maggiore sia in fase di migrazione che in fase di supporto successiva allo spostamento;
• in caso di problemi di forte impatto che non sono emersi nelle varie fasi di test e pilota, è possibile mettere in pausa il processo di spostamento, analizzare i fatti e creare un nuovo processo, così da riprendere la migrazione limitando o annullando completamente le nuove criticità emerse;
• nell’estremo caso di un RollBack, la perdita di dati è limitata ai soli utenti già spostati sulla nuova soluzione o, in caso di RollBack di un’unica wave, la perdita di dati degli utenti coinvolti nell’ultimo spostamento;
• i dati da migrare sono più contenuti e si raggiunge più facilmente il 100%, prima dello switch dell’utente.

I contro dello Staged:

• la preparazione di una migrazione Staged è molto più lunga e richiede profonde analisi come:
  • Individuare tutti gli utenti che fanno parte dello stesso gruppo (o che collaborano più spesso);
  • Individuare risorse e applicazioni direttamente collegate al gruppo di cui sopra;
  • Stilare un calendario di migrazione che tiene conto del tempo di copia dei dati e del tempo di conversione delle applicazioni sul nuovo ambiente.
• la necessità di gestire un ambiente promiscuo, che per quanto bene integrato creerà qualche confusione negli utenti che dovranno collaborare con strumenti diversi;
• Il progetto richiede personale dedicato unicamente a questo percorso.

Ora che abbiamo una panoramica dei due metodi di migrazione, è necessaria una valutazione cucita sull’organizzazione, sul prodotto che viene utilizzato per eseguire lo spostamento dei dati e ovviamente seguendo come linea guida i pro e i contro dei due approcci.

Come già espresso, Microsoft si integra egregiamente con Google: quindi, entrambe le soluzioni sono pienamente praticabili, ma quindi quale scegliere?

Cosa valutare prima della migrazione

La migrazione a CutOver è preferibile quando è importante mantenere costi più contenuti e ridurre i tempi della migrazione e le risorse allocate.

In quali scenari è consigliabile?

• Pressione sul supporto tecnico

Se teniamo in considerazione il 20% teorico di utenti con difficoltà, per poter permettere un passaggio che non abbia conseguenze disastrose, sarà necessario avere un supporto dedicato che riesca a ricoprire il fabbisogno di questi utenti in un tempo ragionevole.

Se, ad esempio, la nostra azienda è composta da 100 utenti, il giorno successivo al CutOver potrebbero esserci 20 utenti fermi che hanno bisogno di assistenza. Mediamente, un tecnico avrà bisogno di un’ora ad utente per risolvere (o comunque gestire) il problema -il tempo varia molto anche a seconda della preparazione del supporto tecnico in campo. Questo significa che un tecnico riesce a supportare 8 utenti al giorno; quindi, per 100 utenti si dovrebbe disporre di almeno 2 o 3 tecnici che diano supporto nei giorni subito successivi al CutOver.

Quando invece è consigliata una Staged?

• Copertura sul territorio

Nel caso in cui l’azienda sia fortemente distribuita sul territorio e non abbia soluzioni che ne permettano una comunicazione efficace in termini di supporto e che quindi richieda lo spostamento fisico dei tecnici per andare nelle sedi, lo Staged è preferibile perché, altrimenti, si rischia di avere dei Branch completamente fermi in attesa di un tecnico che passi da loro.

è importante tenere in considerazione anche i fusi orario diversi tra le varie sede, per una programmazione delle migrazioni ottimale.

• Ambiente complesso:

Se l’ambiente sorgente, oltre agli utenti e alle risorse di base (come cassette postali, gruppi, file, etc.) ha molte applicazioni proprietarie ed integrate, anche in questo caso il CutOver non è consigliato se non si ha una TaskForce che riesca a convertire gli applicativi in un fine settimana.

Raccogliendo le informazioni di cui sopra, è suggerita la metodologia Staged quando è presente:

1. uno sbilanciamento importante tra utenti e supporto tecnico;
2. un ambiente molto complesso;
3. una suddivisione sul territorio con sedi diverse, che richiedono supporto in loco;
4. fuso orario diverso, tra le varie sedi;
5. una quantità di dati ingente.

Una volta individuato il metodo adeguato, ci si potrà concentrare sul prioritizzare le fasi di progetto. Ecco un esempio:

• Fase di Inquadramento: Raccolta di tutte le informazioni dell’ambiente sorgente.
• Fase di Test: Prova delle soluzioni in destinazione e loro effettivo utilizzo.
• Fase di Training: Formazione degli utenti all’utilizzo delle nuove soluzioni.
• Fase Pilota: Alcuni utenti reali sono spostati sul nuovo ambiente e possono provare realmente l’efficacia del nuovo ambiente.
• Fase di RollOut: La completa realizzazione del progetto di migrazione
• Fase di Chiusura: Raccolta delle informazioni e feedback sulla migrazione e stesura di un piano per le future integrazioni e migliorie.

Ogni fase è importante e deve essere organizzata in ogni dettaglio. Gli esperti 4wardPRO possono esserti di supporto per realizzare un progetto di migrazione di successo.