Office 365: Migrazione tenant to tenant

!! Batman e Robin sullo stesso Tenant Office 365 !! (aka migrazione tenant to tenant)

Non importa che voi siate Batman o Robin l’importante è che voi sappiate che Yooda è al vostro fianco per accompagnarvi ed effettuare la migrazione tenant to tenant di tutti i Workload che Microsoft fornisce da un Tenant office 365 a un altro.

Quello che andremo ad illustrarti è come noi di Yooda affrontiamo le migrazioni di tipo migrazione tenant to tenant.

Microsoft ad oggi non offre strumenti nativi che diano la possibilità agli admin IT di effettuare la move dei contenuti di posta, Onedrive, Teams e sharepoint Online da Tenant 365 a Tenant 365 ed è quindi necessario affidarsi ad esperti del settore e a software di terze parti per effettuare tali attività.

Noi di Yooda collaboriamo con Quest, multinazionale leader nel deploy di software in grado di gestire in modo sicuro e affidabile migrazioni di questo tipo.

Nello specifico per le move Tenant to Tenant sono 2 i prodotti che di solito utilizziamo per una migrazione tenant to tenant:

Quest On Demand per la move di workload come Posta, Onedrive e Teams

Metalogix Essentials for Office 365 per la move della parte relativa a Sharepoint Online

Una migrazione su misura per te.

Initiate

Durante il meeting di kickoff iniziale in cui ci conosciamo e raccogliamo quelle che sono le vostre esigenze, la nostra prassi è riempirvi di domande ? per raccogliere più informazioni possibili e delineare insieme quello che sarà il profilo di una migrazione il più possibile fedele alle vostre esigenze in termini di tempistiche, servizi e priorità.

Una delle decisioni cruciali ad esempio è la modalità in cui dovrà essere effettuata la migrazione tenant to tenant:

Cutover o in coesistenza?

Decidiamo assieme 🙂

• quanto tempo abbiamo a disposizione per effettuare la migrazione?
• quanti sono gli utenti oggetto di migrazione?
• qual è la mole di dati presenti negli Onedrive degli utenti e Sharepoint online aziendale?

La modalità Cutover consiste nell’effettuare la move di tutti gli utenti e tutti i servizi ad essi associati e utilizzati in un unico blocco. Questa opzione è indicata quando il numero di utenti non supera le 100/150 unità e il tempo a disposizione è abbastanza per permettere la move della mole di dati presenti sul tenant sorgente nel periodo prestabilito. 

Diversamente meglio optare per una migrazione in coesistenza, dove la move degli utenti e dei workload (servizi) verrà effettuata a gruppi di persone suddivise per mansione, ruolo aziendale o altro in più tempi prestabiliti.

Altre due domande importanti: 

• Quale dovrà essere il dominio principale che avranno assegnato gli utenti a fine migrazione?

Il dominio sorgente o il dominio di destinazione?

Supponiamo che Batman e i suoi collaboratori utilizzino il dominio batman.it (bruce.wayne@batman.it) e Robin utilizzi il dominio robin.com (dick.grayson@robin.com)

Robin deve migrare dal suo tenant (sorgente) verso il tenant di Batman (destinazione)

Una volta ultimata la migrazione, la casella di Robin e i suoi collaboratori dovranno rimanere @robin.com o dovranno diventare @batman.it ?

• Gli oggetti sul tenant sorgente sono sincronizzati con una piattaforma Active Directory onprem o sono cloudonly?

Come dovranno essere riportati su tenant di destinazione?

Avere in anticipo queste informazioni è importante per permetterci di impostare la migrazione e gli strumenti di lavoro nella modalità più congeniale.

Assessment e Remediation

“Dalle parole ai fatti” nel senso che una volta conclusa la parte conoscitiva, passiamo alla fase di Assessment in cui effettueremo un controllo sulle piattaforme coinvolte nel progetto, per raccogliere tutte le informazioni e i dati relativi ai due tenant (ed eventuali piattaforme onprem)per segnalarvi quelle che potrebbero essere le criticità in fase di migrazione.

Dopo la fase di Assessment l’iter prevede un secondo meeting in cui vengono discussi i dati raccolti per poi passare ad effettuare quelle che sono [se necessarie] le attività di “remediation” ovvero operazioni utili per correggere le configurazioni che potrebbero ostacolare il corretto svolgimento della migrazione.

Costantemente connessi

Tutto il processo di migrazione è un susseguirsi di operazioni importanti, tutto dev’essere riportato fedelmente e nulla dev’essere lasciato al caso. Nessuna decisione sarà presa individualmente. Ci teniamo quindi sempre in contatto con meeting settimanali e nelle fasi più delicate anche con chat e meeting rapidi quotidiani.

Cosa portare e cosa no?

“Tutto, vogliamo portare tutto” ? questo è quello che di solito ci sentiamo dire..

Va bene portiamo tutto ? ma perché non sfruttare la migrazione per disfarsi un po’ delle mailbox non più utilizzate, i gruppi a cui nessuno scrive più, gli N. teams di “test” creati e lasciati a prendere la polvere?

Per aiutarvi a comprendere meglio cosa c’è sul vostro Tenant, vi forniremo un bel file Excel con ben suddivise insieme alle relative statistiche di utilizzo: tutte le Mailbox, shared maibox, Distribution List, contatti,Teams, siti Sharepoint in modo da permettervi di dirci cosa effettivamente dovrà essere oggetto di migrazione e cosa no. 

Go!!!

Partiamo con la creazione delle User mailbox e dei Guest users presenti sul Tenant sorgente nel Tenant di destinazione.

Questo per permetterci di mappare sul tool di migrazione gli oggetti e non correre il rischio di migrare i contenuti di un utente all’interno della casella di un altro e anche per permettere al tool di settare correttamente la membership dei vari utenti all’interno delle DL, Teams e siti sharepoint e riportare fedelmente le permissions come full Access e Send As.

Un’importante considerazione da fare in questo passaggio è la gestione del mailflow, perché per permettere al tool di migrazione di spostare i dati, le “nuove” mailbox sul tenant di destinazione dovranno essere a tutti gli effetti attive.

Ma cosa succede se in questa fase in cui la migrazione è appena iniziata qualcuno scrive a queste “nuove” mailbox?

Che nessuno leggerà queste mail perché gli utenti stanno ancora usando le loro cassette sul tenant sorgente. 

Per evitare che questo accada sono due le attività che effettuiamo sulle caselle:

• Crearle nascoste dalla rubrica aziendale (GAL)
• Impostare sulle caselle un forward che punta all’indirizzo di posta della casella sul tenant sorgente

In questo modo in maniera del tutto trasparente, le nuove caselle saranno attive ma nessuno si accorgerà che sono state create e comunque anche nel caso in cui per errore qualcuno dovesse scrivergli un messaggio, la mail verrà recapitata nella mailbox sul tenant sorgente utilizzata dall’utente.

Migriamo?

Ora che i tenant sono connessi tra di loro e le utenze sono state create a mappate passiamo alla fase di test.

Questo step è molto importante per aiutarci a capire se il tool è stato configurato correttamente o ha bisogno di attività di tuning per affinare la comunicazione tra i tenant e la migrazione dei contenuti.

Una volta conclusa la fase di test passiamo alla fase pilota.

Vi chiederemo infatti dai 3 a 5 nominativi di colleghi che migreremo prima di tutti gli altri e che dovranno con il nostro supporto, riportarci quella che è la user experience reale di migrazione, eventuali anomalie e punti di vista.

La scelta degli utenti pilota richiede attenzione perché il loro ruolo è molto importante: dovranno essere utenti in grado di fornire feedback affidabili e di solito la scelta ricade sui membri dell’IT e varie utenze “amiche” preferibilmente che ricoprano ruoli con particolari esigenze e\o siano in sedi differenti.

Questo Step è fondamentale per impostare definitivamente il tool di migrazione e organizzare la fase massiva di move dei contenuti.

Quest’ultima può essere suddivisa in due o più parti in base alla quantità di dati totali ed è la fase in cui sposteremo tutto lo storico dei contenuti presenti sul tenant sorgente fino a una data concordata insieme.

Ad esempio, tutti i contenuti dal 01/01/1999 al 31/12/2020

Questo permetterà nella fase finale di migrazione di effettuare una move “delta” soltanto dei  pochi mesi restanti che comprenderà una mole di dati più ridotta e si completerà in breve tempo. 

Ad esempio, tutti i contenuti dal 01/01/2021 al 26/03/2021 (giorno concordato di fine migrazione)

In base alla modalità di migrazione concordata (cutover o in coesistenza) creeremo i batch di migrazione di tutti i workload e in maniera del tutto trasparente per gli utenti potremo spostare i contenuti e mantenerli sincronizzati tra i due Tenant.

Ormai ci siamo..

Finalize in coesistenza

La modalità in coesistenza permette di suddividere la move degli utenti e delle risorse ad essi associate in gruppi (batch) di migrazione e la durata in base alle dimensione della vostra azienda può durare anche settimane o addirittura mesi.

Una volta che tutti i batch di migrazione sono stati migrati e saremo così giunti al termine non rimarrà che seguire i passaggi sotto descritti al paragrafo “The End”

Finalize Cutover

Se la modalità scelta per effettuare la migrazione è stata Cutover, il nostro consiglio è quello di effettuare le attività di finalizzazione della migrazione durante il weekend. Questo per permetterci di avere una maggiore tranquillità, autonomia e più tempo per concludere tutte le attività senza dare alcun disservizio agli utenti.

Di norma il giovedì prima del weekend concordato chiediamo di abbassare il TTL dei record DNS pubblici del domino o dei domini oggetto di migrazione a 5 minuti.

Abbassare il TTL a un valore cosi basso permetterà una propagazione più rapida delle modifiche che effettueremo durante le attività del weekend.

Jumpin’ Friday

Al venerdì sera all’orario prestabilito faremo partire le move “Delta” di tutti i workload.

Se per la posta elettronica erano stati impostati i forward per la gestione del mailflow da tenant sorgente a tenant destinazione,invertiremo la logica di forward.

Così facendo tutte le nuove mail in arrivo sul tenant in dismissione verranno girate verso le “nuove” mailbox.

The End

Al termine di tutti i processi di move (di norma al sabato) sono due gli scenari in cui potremmo trovarci:

Premessa: Microsoft non permette che un dominio di posta sia registrato su più tenant contemporaneamente. Quindi fino a che il dominio robin.com sarà registrato sul dominio sorgente le caselle di posta sul tenant batman.it avranno un indirizzo mail batman.it o batman.onmicrosoft.com [in base a come l’avremo voluto configurare]

Scenario A:

Le mailbox dovranno mantenere il proprio indirizzo mail originale (@robin.com) anche se saranno ospitate su un tenant in cui il dominio principale è (batman.it)

In questo scenario modificheremo il puntamento del record MX (di cui abbiamo a tempo debito abbassato il TTL) verso un record MX di appoggio a cui far puntare tutto il traffico di posta durante la fase di decommissioning.

In questo modo tutte le mail in arrivo sul tenant in dismissione verranno parcheggiate su questo MX, non ci sarà alcuna perdita di mail e potremo procedere ad eliminare il dominio dal tenant e registrarlo sul nuovo.

Una volta che il dominio robin.com sarà a bordo del tenant batman.it modificheremo gli indirizzi mail di tutti gli oggetti migrati con @robin.com e faremo puntare i record MX di nuovo verso i server di Office 365 e rilasceremo le mailbox presenti sull’mx di appoggio.

Scenario B:

Le mailbox non dovranno mantenere il proprio indirizzo mail originale quindi Robin e i suoi collaboratori avranno un nuovo indirizzo di posta dick.grayson@robin.com –> dick.grayson@batman.it

In questo scenario di fatto l’unico passaggio differente è il fatto che dopo aver registrato il dominio @robin.com sul tenant Batman.it l’indirizzo mail degli oggetti migrati non verrà modificato ma gli indirizzi saranno solo aggiunti come Alias per fare in modo che se un mittente scrive ancora a dick.grayson@robin.com anche se il suo nuovo indirizzo sarà dick.grayson@batman.it

Avendo il TTL del record a 5 minuti ogni operazione di propagazione potrà avvenire con tempi veramente ridotti permettendoci di procedere senza troppe interruzioni e attese nelle attività.

È tempo di verifiche e di test. Le attività di migrazione sono finite ma a maggior ragione se si è scelta la modalità cutover è più che mai necessario verificare i log di migrazione dei contenuti ed effettuare i test di mailflow e verificare che tutto sia stato riportato il più fedelmente possibile.

Il lunedì (ma anche il martedì tanto non scappiamo :)) quando tutti gli utenti arriveranno al lavoro noi ci saremo per darvi tutto il supporto Post-migrazione necessario.