Acquisizione e consolidamento di tenant: 189 utenze su quattro workload con il Migration Orchestrator

Due strumenti, perché nessuno copre tutto. La documentazione Microsoft è esplicita: i workload selezionabili in un batch dell'Orchestrator sono quattro — caselle Exchange, OneDrive, chat e riunioni di Teams — e la soluzione *non* migra i dati condivisi, cioe team, canali e siti SharePoint, che restano sul tenant di origine. Quindi: Orchestrator per i quattro workload personali, cross-tenant SharePoint site migration per i siti dei team, e canali ricreati sul tenant di destinazione come scelta dichiarata a progetto. Dirlo prima è diverso dal farlo scoprire dopo.

L'Orchestrator muove contenuto, non identità. E la frase che riorganizza il progetto: le 189 utenze di destinazione vanno create e configurate prima, e il Cross-Tenant Identity Mapping è un prerequisito, non un'opzione. Con un vincolo che si paga caro se si scopre tardi: ogni utente deve essere un MailUser sul tenant di origine e non avere una casella su quello di destinazione prima che il mapping possa essere eseguito — e questo vale anche per gli utenti di cui non si sposta la casella.

Un batch solo, non quattro. Microsoft raccomanda di mettere tutti i workload nello stesso batch invece di gestirne uno per workload, perché l'Orchestrator ne ordina l'esecuzione tenendo conto delle dipendenze. E c'è un vincolo rigido: il batch non parte se si seleziona il workload delle riunioni di Teams senza selezionare anche le chat e le caselle.

La data di impatto come leva di progetto. Il campo `CompleteAfterDate` separa la sincronizzazione dall'impatto: prima di quella data sincronizza in background solo Exchange, e nessun dato si muove per OneDrive, chat e riunioni; dopo, partono gli altri tre. Su un'acquisizione con una data contrattuale è esattamente il campo che permette di far maturare la posta per giorni e di far cadere il disagio sull'utente nel giorno scelto.

Le due cose censite in assessment, perché dopo non si rimedia. Le caselle sotto qualunque tipo di hold non migrano e lo spostamento viene bloccato: su 189 utenze vanno trovate prima. E la casella di origine viene cancellata dopo una migrazione riuscita — dopo non è più disponibile né consultabile sul tenant di partenza — quindi la conservazione a norma e l'eDiscovery si risolvono a monte, non a valle. Il metodo completo e nella guida alla migrazione tenant-to-tenant; l'assessment è la fase che decide il progetto: vedi il cloud assessment.