Sono ancora moltissime le aziende italiane che lavorano con Exchange Server on-premises. In alcuni casi è una scelta consapevole, in altri semplicemente un'infrastruttura che ha funzionato per anni e che nessuno ha mai toccato. Il problema è che mantenere un Exchange on-premises oggi significa farsi carico di aggiornamenti cumulativi, certificati, sicurezza perimetrale, storage, alta disponibilità, tutto internamente, con costi e rischi crescenti (senza contare che ad esempio Exchange 2013 è fuori supporto dal 2023 tanto per dare delle date).
Oggi, affrontare una migrazione da Exchange a M365 non è più una questione di 'se', ma di 'quando'. E soprattutto di "come", perché è lì che le cose si complicano.
Negli ultimi mesi abbiamo completato la migrazione di un gruppo industriale italiano con tre società, circa 300 caselle di posta su Exchange Onprem, decine di cartelle pubbliche e un ambiente Active Directory on-premises da integrare con Entra ID. Non è stato un progetto lineare. Abbiamo incontrato problemi che la documentazione Microsoft non copre, situazioni che si presentano solo in ambienti reali con anni di storia alle spalle.
Questo articolo raccoglie quello che abbiamo imparato, nella speranza che possa risparmiare tempo e grattacapi a chi si trova ad affrontare la stessa migrazione.
Perché scegliere la versione Hybrid per la migrazione da Exchange a M365
La prima decisione da prendere è il tipo di migrazione. Le opzioni principali sono due: cutover (si sposta tutto in una volta) o hybrid (convivenza temporanea tra Exchange on-premises ed Exchange Online).
Per un'azienda con poche decine di caselle, il cutover può funzionare. Ma quando si superano le 100 mailbox, quando ci sono cartelle pubbliche attive, quando il dominio Active Directory è condiviso tra più servizi, la strada hybrid è quasi obbligata. Permette di migrare a gruppi, di testare progressivamente e di mantenere operativi i servizi durante la transizione.
Nel nostro caso, la scelta hybrid si è rivelata corretta ma ha portato con sé una complessità che non va sottovalutata.
La sincronizzazione delle identità con Entra ID
Prima di avviare la migrazione da Exchange a M365, serve che le identità on-premises siano sincronizzate correttamente con Entra ID (ex Azure AD) tramite Entra Connect (ex Azure AD Connect). Qui si apre un capitolo che, da solo, può richiedere settimane di lavoro.
Il problema dell'UPN (User Principal Name)
Il primo problema tipico è l'UPN (User Principal Name). Molte aziende italiane hanno configurato Active Directory anni fa usando il dominio interno .local come UPN suffix. Ma Microsoft 365 richiede un UPN che corrisponda a un dominio verificato nel tenant. Bisogna quindi aggiungere un UPN suffix alternativo in Active Directory, modificare l'UPN di ogni utente e verificare che Entra Connect sincronizzi correttamente il nuovo valore.
La gestione dei Proxy Address
Il secondo problema riguarda i proxy address. Ogni utente Exchange ha un attributo proxyAddresses in Active Directory che contiene tutti gli alias email. Quando si attiva l'hybrid, ogni utente deve avere un indirizzo di tipo @tenant.mail.onmicrosoft.com (il cosiddetto Remote Routing Address). Se questo indirizzo manca, la migrazione della casella fallisce con un messaggio tipo "target mailbox doesn't have an SMTP proxy matching the required format" — un errore che, senza contesto, può mandare fuori strada per ore.
La pulizia dei proxy address è un'attività che va fatta prima di iniziare le migrazioni, non durante. Abbiamo preparato uno script PowerShell che verifica tutti gli utenti e aggiunge automaticamente il Remote Routing Address dove mancante:
powershell
# Verifica e aggiunta Remote Routing Address
$users = Get-RemoteMailbox -ResultSize Unlimited
foreach ($user in $users) {
$routingAddress = ($user.EmailAddresses | Where-Object { $_ -like "smtp:*@tenantname.mail.onmicrosoft.com" })
if (-not $routingAddress) {
"smtp:"</span> <span class="token token">+</span> <span class="token token">$user</span><span class="token token">.</span>Alias <span class="token token">+</span> <span class="token token">"@tenantname.mail.onmicrosoft.com"
Set-RemoteMailbox $user.Identity -EmailAddresses @{Add=$newAddress}
Write-Host "Aggiunto routing address per $($user.DisplayName)" -ForegroundColor Yellow
}
}Un consiglio pratico: se possibile, esegui Entra Connect in modalità staging su un secondo server prima di passare in produzione. Questo ti permette di verificare cosa verrà sincronizzato senza impattare il tenant.
Migrare le caselle: batch, priorità e monitoraggio
La migrazione da Exchange a M365 per le caselle postali avviene tramite batch creati dal pannello Exchange Admin Center di Microsoft 365 o via PowerShell. Ogni batch può contenere da una a centinaia di caselle.
L'errore più comune che vediamo è voler migrare tutto in un unico batch. Non fatelo. Dividete per gruppi logici, per società, per reparto, per criticità e migrate prima un gruppo pilota di 5-10 utenti. Questo vi permette di verificare che il flusso di posta funzioni, che i profili Outlook si riconfigurino correttamente e che le deleghe sulle caselle condivise siano ancora operative.
Nel nostro progetto abbiamo usato batch separati per ciascuna delle tre società del gruppo, con una pianificazione che teneva conto delle esigenze operative: prima gli utenti meno critici (reception, amministrazione), poi i reparti tecnici, infine la direzione.
Per monitorare lo stato di ogni batch, un semplice script PowerShell è più efficace di qualsiasi dashboard:
# Monitoraggio rapido batch di migrazione
Get-MoveRequest | Get-MoveRequestStatistics |
Select-Object DisplayName, StatusDetail, PercentComplete,
TotalMailboxSize, BadItemsEncountered |
Sort-Object PercentComplete -Descending |
Format-Table -AutoSize
Un aspetto da non sottovalutare: i "bad items". Durante la migrazione, Exchange Online potrebbe incontrare elementi corrotti o in formato non supportato. Il parametro -BadItemLimit nel comando di migrazione definisce quanti elementi problematici sono tollerati prima che la migrazione si blocchi. Un valore troppo basso (0 o 1) causa blocchi continui; un valore troppo alto rischia di perdere posta. Noi impostiamo di solito un limite di 10-20 e verifichiamo a posteriori cosa è stato skippato.
Gestire le cartelle pubbliche nella migrazione da Exchange a M365
Se c'è un elemento della migrazione che ci ha fatto sudare più di tutti, sono le cartelle pubbliche (Public Folders). Le cartelle pubbliche sono una struttura dati legacy che Microsoft stessa sconsiglia da anni, ma che moltissime aziende italiane usano ancora come archivio condiviso, rubrica aziendale o repository documentale.
La migrazione delle cartelle pubbliche a Exchange Online richiede un processo specifico in più fasi: generazione dello script di mapping, creazione delle mailbox cartelle pubbliche nel cloud, sincronizzazione incrementale, blocco della scrittura on-premises, finalizzazione. Ogni fase ha le sue trappole.
- Il problema della dimensione: Exchange Online ha un limite per singola mailbox di cartelle pubbliche. Se la struttura on-premises supera questa soglia (e nella nostra esperienza succede quasi sempre...) bisogna suddividere il contenuto in più mailbox, il che richiede un lavoro manuale di mapping che può diventare molto articolato.
- Il problema della gerarchia: Se la struttura delle cartelle pubbliche ha molti livelli di annidamento o contiene caratteri speciali nei nomi, il processo di sincronizzazione può fallire silenziosamente, segnalando il completamento ma lasciando cartelle vuote nel cloud.
Il nostro consiglio: prima di iniziare la migrazione, fate un inventario dettagliato delle cartelle pubbliche con dimensioni, numero di elementi e data di ultimo accesso. Spesso scoprirete che il 70-80% del contenuto non è stato toccato da anni e può essere archiviato anziché migrato, semplificando enormemente il processo.
Dopo la migrazione: autenticazione e sicurezza
Una volta completata la migrazione da Exchange a M365 delle caselle, il lavoro non è finito. Anzi, la fase post-migrazione è quella dove si gioca la sicurezza dell'intero ambiente.
Il primo passo è verificare che tutti gli utenti riescano ad autenticarsi correttamente. In un ambiente hybrid, l'autenticazione può seguire percorsi diversi a seconda della configurazione scelta: ADFS, Pass-through Authentication o Password Hash Sync. Se durante la migrazione qualcosa si è disallineato — e capita più spesso di quanto si pensi — alcuni utenti potrebbero non riuscire più ad accedere, oppure potrebbero autenticarsi con credenziali cached che non si aggiornano.
Il secondo passo è cogliere l'occasione della migrazione per alzare il livello di sicurezza. Attivare la MFA per tutti gli utenti (senza eccezioni), configurare Conditional Access per limitare l'accesso da dispositivi e località non autorizzate, e fare una revisione delle app registrate nel tenant che potrebbero avere permessi eccessivi. Il passaggio al cloud è il momento migliore per impostare queste basi; farlo dopo, con gli utenti già operativi, è sempre più complicato.
Infine, un punto che molti trascurano: la dismissione del server Exchange on-premises. "Dismissione" non significa spegnerlo e basta. Exchange on-premises in ambiente hybrid continua a gestire certi attributi degli utenti anche dopo che tutte le caselle sono state migrate. La dismissione completa richiede una procedura specifica che, se saltata, può causare problemi nella gestione degli utenti mesi dopo la migrazione.
Cinque errori che vediamo ripetersi in ogni progetto
Dopo diverse migrazioni Exchange verso Microsoft 365, ci siamo accorti che certi errori si ripetono con una regolarità impressionante.
- Il dominio accettato rimane Authoritative. Come detto sopra, deve diventare Internal Relay. Finché non lo cambi, la posta per gli utenti già migrati rimbalza.
- Nessuno verifica i proxy address prima di iniziare. Risultato: le prime migrazioni falliscono e si perde una giornata a capire perché.
- Il firewall interferisce con il traffico SMTP verso il cloud. Proxy SMTP, deep packet inspection, regole troppo aggressive — il traffico verso Exchange Online deve passare pulito, senza ispezione.
- Le cartelle pubbliche vengono affrontate per ultime. Invece sono l'elemento che richiede più tempo in una migrazione da Exchange a M365. Iniziate l'inventario e la pulizia fin dal primo giorno del progetto.
- Nessun piano di rollback. Se qualcosa va storto durante un batch, sapete come tornare indietro? Avete un piano B per la posta se il flusso si interrompe? Preparatevi prima, non durante l'emergenza.
Conclusione
La migrazione da Exchange on-premises a Microsoft 365 è un progetto che, sulla carta, sembra semplice. Microsoft fornisce gli strumenti, la documentazione esiste, i passaggi sono definiti. Ma la realtà degli ambienti aziendali italiani con Active Directory cresciuti organicamente in quindici o vent'anni, firewall con configurazioni ereditate, cartelle pubbliche usate come archivio di tutto rende ogni migrazione un progetto unico.
La differenza tra una migrazione che funziona e una che si trasforma in un incubo sta nella preparazione: inventario accurato, pulizia preventiva degli attributi, test progressivi e un piano per ogni imprevisto.
Se vuoi approfondire i passaggi tecnici standard e i requisiti di sistema, ti consigliamo di leggere la nostra
Se stai pianificando una migrazione da Exchange on-premises (qualunque sia la versione) e vuoi confrontarti con chi ha già affrontato queste sfide, contattaci per una consulenza. Possiamo aiutarti a pianificare il percorso più efficiente per la tua situazione specifica.
