Consolidamento di due tenant Microsoft 365: 10 utenti e 3 workload con strumenti nativi

Percorso scelto: per-workload, non orchestrator. Con un perimetro di posta, OneDrive e file — senza necessità di portarsi dietro chat e riunioni di Teams — il percorso per workload è quello con più chilometri alle spalle, non richiede il Cross-Tenant Identity Mapping come obbligo e consente l'automazione non presidiata tramite un'app Entra multi-tenant con permesso applicativo. Il limite di 2.000 caselle per batch rendeva i 10 utenti una singola ondata.

I tre workload, con tre strumenti distinti. Le caselle con la *cross-tenant mailbox migration* (MRS, in "pull" dal tenant di destinazione); OneDrive con la *cross-tenant OneDrive migration*; i file dei team con la *cross-tenant SharePoint site migration*, perché nativamente di Teams si migra il sito SharePoint del team — non i canali né i post.

La scelta dichiarata in fase di design: team e canali si ricreano nel tenant di destinazione. Nativamente non migrano, e dirlo prima è diverso dal farlo scoprire al cutover. Ricrearli è anche l'occasione per ripulire una tassonomia che nel tempo si sporca. Chat e riunioni sarebbero state possibili solo passando all'orchestrator, che però non copre i siti SharePoint: un ibrido non giustificato su questo perimetro.

L'ordine che evita il fallimento. Gli attributi di identità sugli oggetti del tenant di destinazione — `ExchangeGuid`, `ArchiveGuid`, indirizzi x500, `targetAddress` — sono stati stampati prima di assegnare le licenze workload. È la causa numero uno di fallimento in questi progetti: licenziare un MailUser prima dello stamping fa provisionare al target una casella nuova e vuota, e la conversione fallisce.

Il metodo completo, con i criteri di esclusione e le due licenze di migrazione che si confondono, è nella guida alla migrazione tenant-to-tenant. L'assessment è la fase che decide il progetto: vedi il cloud assessment.