Migrazione tenant-to-tenant Microsoft 365: cosa migra davvero con gli strumenti nativi

Quando due aziende si fondono o una ne acquisisce un’altra, sul tavolo dell’IT arriva un problema preciso: due tenant Microsoft 365 separati che devono diventare uno. È la migrazione tenant-to-tenant, e la domanda che determina il budget e il calendario non è “quanto dura” ma una molto più concreta: cosa gli strumenti Microsoft migrano davvero, e cosa resta indietro.

Questa guida risponde a quella domanda usando solo strumenti nativi Microsoft, e include i punti che nella documentazione ufficiale sono sparsi su pagine diverse — o che non ci sono affatto perché emergono solo eseguendo il progetto.

Nota sulla data. Il dominio T2T nativo è cambiato molto fra fine 2025 e inizio 2026: sono arrivati il Migration Orchestrator e il Cross-Tenant Identity Mapping. Quanto segue è verificato sulla documentazione Microsoft al 3 agosto 2026. Prima di impegnarsi contrattualmente su una data o su un perimetro, lo stato GA/preview va riverificato sulla doc live.

Cos’è, e i tre scenari

Un tenant è l’istanza Microsoft 365 di un’organizzazione: utenti, posta, file, Teams, identità Entra ID, licenze, configurazioni. Una migrazione tenant-to-tenant sposta contenuti e identità da un tenant a un altro. Tre situazioni tipiche:

• Fusione o acquisizione: gli utenti confluiscono in un tenant già operativo.
• Consolidamento di gruppo: più tenant in uno.
• Scorporo o rebrand: si crea un tenant nuovo e ci si migra dentro.

La differenza fra “tenant esistente” e “tenant nuovo” non è cosmetica: cambia la strategia degli UPN, la gestione delle collisioni, e il fatto che nel primo caso vada verificata la capienza di licenze e quote del target.

Il vincolo che spiega tutto il resto

C’è un principio che va capito prima di ogni scelta tecnica: le funzionalità native spostano il CONTENUTO, non l’identità.

Creare e configurare gli utenti nel tenant di destinazione resta lavoro di progetto. Nessuno strumento nativo “clona” un utente con la sua password, i suoi metodi MFA e i suoi gruppi.

Ne deriva un corollario che vale la pena scrivere in chiaro, perché è il fraintendimento più diffuso: la cross-tenant synchronization di Entra ID non è uno strumento di migrazione. Serve alla coesistenza — proiettare le identità del tenant A nel tenant B come utenti B2B, così che le persone si vedano nella rubrica e possano collaborare durante la transizione. Non sposta un solo messaggio di posta né un file. Progettare un piano di migrazione credendo il contrario porta a scoprire a metà percorso che non è stato migrato nulla.

Cosa migra nativamente, e cosa no

Questa è la tabella che serve per decidere, ed è la parte che i fornitori tendono a non mettere per iscritto.

Migra nativamente:

NON migra nativamente — e questo è l’elenco da mettere sul tavolo prima di firmare, non in fase di cutover:

• Team e canali di Teams, i post dei canali, le tab e le app installate.
• Teams Phone, le policy Teams, i canali privati e condivisi.
• Gruppi di Microsoft 365 e liste di distribuzione.
• Permessi e deleghe cross-tenant: FullAccess, SendAs, SendOnBehalf.
• Firme di Outlook, regole della Posta in arrivo, etichette di sensitivity e retention.
• Conditional Access e le policy di sicurezza: si ricostruiscono da zero nel target.
• Le migrazioni cross-cloud (per esempio da Worldwide a GCC High) non sono supportate.

Di Teams, in pratica, nativamente si salva il sito SharePoint del team — cioè i file — attraverso la migrazione dei siti. Team, canali e struttura si ricreano nel target. È una scelta di progetto onesta e spesso preferibile: ricreare i team è l’occasione per ripulire una tassonomia che in dieci anni si è sporcata.

Le due licenze che si confondono (e una sola è EA-only)

Questo è il punto più costoso del dominio, perché un’informazione sbagliata qui esclude un cliente da un progetto che potrebbe fare.

Esistono due licenze diverse, con modelli commerciali e canali di acquisto diversi:

Il gate Enterprise Agreement riguarda solo la seconda, quella dei siti SharePoint. Per migrare posta e OneDrive un cliente CSP o Web direct è perfettamente in regola.

⚠️ Attenzione a una pagina obsoleta della documentazione Microsoft. La panoramica Cross-tenant OneDrive migration riporta ancora la formula “for Enterprise Agreement customers” riferita a OneDrive. È quasi un anno più vecchia della panoramica dell’orchestrator, che dichiara invece esplicitamente la disponibilità per EA, CSP, Web direct, small business ed EDU. Chi si documenta in buona fede su quella pagina arriva alla conclusione sbagliata — ed è un errore che abbiamo visto ripetere in preventivi altrui.

Sui piani idonei all’add-on utente: Microsoft 365 Business Basic, Standard e Premium; Microsoft 365 F1, F3, E3, E5; Office 365 F3, E1, E3, E5; Exchange Online; SharePoint; OneDrive; EDU.

Una nota sul prezzo, per onestà: la tariffa una tantum non è dichiarata in nessuna pagina della documentazione Microsoft. Va confermata dal licensing desk o dal distributore prima di finire in un’offerta.

Per workload o con l’Orchestrator: la prima decisione

È la scelta d’apertura del progetto e non è reversibile a costo zero: cambia prerequisiti, ruoli, automazione e licenze.

In pratica è quasi sempre un ibrido, e va detto al cliente prima della firma: siti SharePoint e team/canali non li fa l’orchestrator, quindi anche scegliendolo servono gli strumenti per workload per il resto.

Per il perimetro tipico di una PMI — posta più OneDrive, senza necessità di portarsi dietro le chat — il percorso per workload è quello con più chilometri alle spalle, e l’unico che consente automazione non presidiata.

I cinque errori che fanno fallire il progetto

1. Non verificare gli hold in assessment. Le caselle sotto qualsiasi tipo di hold non vengono migrate e il move è bloccato, su entrambi i percorsi. Non esiste una via d’uscita tecnica: o si rimuove l’hold con avallo legale, o l’utente si esclude. È il primo criterio di esclusione da controllare, prima di stimare tempi e costi.

2. Licenziare prima di stampare gli attributi. È la causa numero uno di fallimento. L’identity mapping — cioè lo stamping di ExchangeGuid, ArchiveGuid, indirizzi x500 e targetAddress sull’oggetto utente del target — va fatto prima di assegnare le licenze workload. Se si licenzia un MailUser prima di stampare l’ExchangeGuid, il target gli provisiona una nuova casella vuota e la conversione fallisce. Gli utenti nel target non devono avere né casella né sito OneDrive preesistenti.

3. Sottovalutare il vincolo del dominio. Un dominio verificato vive in un solo tenant. “Spostarlo” significa rimuoverlo dall’origine e poi aggiungerlo e verificarlo nella destinazione: è una finestra critica, e detta la coreografia dell’intero cutover.

4. Dare per scontato un rollback. Dopo il move la casella di origine viene eliminata. Non esiste un rollback nativo dei dati: si può solo rifare il percorso al contrario, con gli stessi strumenti, e le riunioni Teams non vengono ricreate. L’eDiscovery post-migrazione esiste solo nel target.

5. Lavorare sul tenant sbagliato. Con due tenant aperti contemporaneamente, un comando lanciato sul contesto errato corrompe il mapping. Va verificato il contesto a ogni passaggio, e per le operazioni delicate conviene usare processi separati anziché fidarsi della sessione attiva.

Sette trappole verificate sul campo

Le prossime sette non stanno nella documentazione: sono emerse eseguendo una migrazione tenant-to-tenant reale, completata nell’agosto 2026 con soli strumenti nativi. Sono il tipo di dettaglio che sposta una giornata di lavoro.

1. Le Security Defaults del tenant di destinazione bloccano il device code flow. La sessione interattiva passa, quella con codice dispositivo no. Si risolve creando l’app dal portale ed eseguendo in interattivo, oppure allentando temporaneamente le Security Defaults.

2. Set-Mailbox -PrimarySmtpAddress non esiste in Exchange Online V3. L’indirizzo primario si imposta con -WindowsEmailAddress: prima si aggiunge l’indirizzo come secondario, poi si promuove.

3. FullAccess non migra cross-tenant, nemmeno mettendo principale e delegato nello stesso batch. Permessi FullAccess, SendAs e SendOnBehalf vanno ri-stampati dopo la migrazione. Va previsto come attività, non scoperto dagli utenti.

4. Le caselle condivise e di risorsa risultano esenti dalla licenza utente. Verificato sul campo; la documentazione non lo dichiara. Significa una licenza per utente reale e zero per le condivise — ma va confermato col licensing desk prima di preventivare.

5. Test-MigrationServerAvailability restituisce IsValid=True anche quando segnala un fallimento per licenza mancante. Non è un bug: IsValid=True dice che il canale di comunicazione fra i tenant funziona. Il fallimento sulla licenza è lo stato atteso prima dell’acquisto dell’add-on.

6. Non dare per scontato l’indirizzo di routing <alias>@<tenant>.mail.onmicrosoft.com sulle caselle di origine. Va verificato sugli indirizzi reali, altrimenti il routing dei MailUser non funziona.

7. Il client secret dell’app di migrazione dura 180 giorni per default. Su un progetto lungo scade a metà strada e la migrazione si interrompe senza una causa evidente.

La coesistenza è la metà del lavoro

Fra il primo e l’ultimo utente migrato passano settimane, e in quelle settimane le persone dei due tenant devono potersi scrivere, vedersi nella rubrica e leggere i calendari. La coesistenza si costruisce con le impostazioni di accesso cross-tenant, il trust su MFA e dispositivi, e — dove serve la rubrica unificata e il free/busy — la Multitenant Organization con la cross-tenant synchronization.

Il mail flow in coesistenza si comporta come in uno scenario ibrido: antispam, regole di trasporto e journaling agiscono prima nel tenant di origine e poi in quello di destinazione, e il free/busy dei MailUser deve puntare alla posizione reale della casella. È qui che si annidano i problemi che gli utenti percepiscono come “la migrazione non funziona”.

Le fasi, nell’ordine che conta

1. Assessment: inventario di caselle, OneDrive, siti, Teams; hold, quote, deleghe, volumi. Da qui esce il perimetro reale — vedi il cloud assessment.
2. Design: percorso per workload o orchestrator, strategia UPN e domini, ondate.
3. Coesistenza: accesso cross-tenant e trust, per far collaborare le persone dal primo giorno.
4. Setup dei due tenant: app di migrazione con consenso su entrambi, endpoint, relazione organizzativa.
5. Pre-staging delle identità: creazione dei MailUser nel target con gli attributi stampati — prima delle licenze.
6. Pilot: un gruppo ristretto, validando mail flow, free/busy, rubrica e Teams.
7. Migrazione a ondate.
8. Cutover: completamento dei batch e spostamento del dominio con i record DNS.
9. Post-migrazione: profili Outlook ricostruiti, OneDrive ri-sincronizzato, Teams ri-autenticato, e la ri-stampa di permessi, firme ed etichette che non sono migrati.
10. Dismissione: rimozione di endpoint e relazioni, chiusura del tenant di origine.

Come lavoriamo su questi progetti

Le migrazioni tenant-to-tenant che gestiamo usano strumenti nativi Microsoft, senza tool di terze parti: significa nessuna licenza aggiuntiva oltre a quelle Microsoft, nessun dato che transita da infrastrutture terze, e un percorso interamente supportato dal vendor. In cambio richiede di accettare i gap nativi e progettare intorno a essi — che è esattamente il motivo per cui l’elenco di cosa non migra sta all’inizio di questa pagina e non in fondo.

Come si traduce in pratica su un perimetro reale — percorso scelto, i tre workload con tre strumenti distinti, e i team ricreati come scelta dichiarata a progetto — è nel case study del consolidamento di due tenant su 10 utenti.

L’assessment è la fase che decide il progetto: gli hold, le collisioni di UPN, i volumi dei siti e le deleghe determinano perimetro, ondate e costi. Vedi i servizi di migrazione cloud e l’assistenza Microsoft 365 gestita per la gestione continuativa dopo il go-live.

Se hai una fusione o uno scorporo in agenda e vuoi capire cosa è realisticamente migrabile nel tuo caso, parla con un nostro consulente: partiamo dall’inventario dei due tenant e dai criteri di esclusione, prima di parlare di date.

Per il contesto più ampio delle migrazioni verso Microsoft 365 restano utili la guida completa alla migrazione, la checklist Exchange on-premises verso Exchange Online e il percorso da Active Directory a Entra ID. Per gli script di inventario e verifica, l’hub PowerShell raccoglie i toolkit di sola lettura che usiamo in assessment.