prestazioni e procedure consigliate per la migrazione della posta elettronica di Microsoft 365 e Office 365

Esistono molti percorsi per eseguire la migrazione dei dati di posta elettronica per un'organizzazione ospitata in locale a Microsoft 365 o Office 365. Quando si pianifica una migrazione a Microsoft 365 o Office 365, una chiara comprensione del processo di migrazione dei dati e della velocità aiuta gli amministratori a pianificare meglio.

Panoramica della migrazione della posta elettronica a Microsoft 365 o Office 365

Microsoft 365 o Office 365 supporta diversi metodi per eseguire la migrazione dei dati di posta elettronica, calendario e contatto dall'ambiente di messaggistica esistente a Microsoft 365 o Office 365, come descritto in Come eseguire la migrazione di più account di posta elettronica a Microsoft 365 o Office 365.

Per domande relative alla rete e alle prestazioni in Microsoft 365 o Office 365, vedere Pianificazione della rete e ottimizzazione delle prestazioni per Microsoft 365 o Office 365.

Metodi di migrazione più frequenti

Prestazioni per i metodi di migrazione

Le sezioni seguenti confrontano i carichi di lavoro di migrazione delle cassette postali e i risultati delle prestazioni osservati per i diversi metodi di migrazione per la migrazione di cassette postali e dati delle cassette postali a Microsoft 365 o Office 365. Questi risultati si basano sui test interni e sulle migrazioni effettive dei clienti a Microsoft 365 o Office 365.

Carichi di lavoro di migrazione dei clienti

Nella tabella seguente vengono descritti i diversi carichi di lavoro coinvolti in una migrazione tipica e le sfide e le opzioni per ognuno di essi.

Quando viene eseguita la migrazione delle cassette postali all'interno dei data center di Microsoft 365, ogni spostamento delle cassette postali o lo spostamento in blocco delle cassette postali richiede tempo per il completamento dell'operazione. Esistono diversi fattori, ad esempio l'attività del servizio Microsoft 365, che possono influire esattamente sulla quantità di tempo. Il servizio è progettato per limitare i carichi di lavoro discrezionali come gli spostamenti delle cassette postali, per garantire che il servizio venga eseguito in modo ottimale per tutti gli utenti. È comunque possibile prevedere l'elaborazione degli spostamenti delle cassette postali, a seconda della disponibilità discrezionale delle risorse del servizio. Altre informazioni sulla limitazione delle risorse sono disponibili in questo post di blog.

Stime della durata per la migrazione delle cassette postali in Exchange Online

Per pianificare la migrazione, le tabelle seguenti presentano linee guida su quando prevedere il completamento delle migrazioni in blocco delle cassette postali o delle singole migrazioni. Queste stime si basano su un'analisi dei dati delle migrazioni precedenti dei clienti. Poiché ogni ambiente è univoco, la velocità di migrazione esatta può variare.

Durata della migrazione delle cassette postali in base ai profili delle dimensioni delle cassette postali:

• GoLocal/Multi-Geo/Crittografia in Exchange Online

  Carico di lavoro	Dimensioni della cassetta postale (GB)	P50 (50° durata percentile) (giorni)	P90 (durata del 90° percentile) (giorni)
  GoLocal/Multi-Geo/Encryption	0 - 10	1	1
  GoLocal/Multi-Geo/Encryption	10 - 50	2	6
  GoLocal/Multi-Geo/Encryption	50 - 100	4	11
  GoLocal/Multi-Geo/Encryption	100 - 200	6	14
  GoLocal/Multi-Geo/Encryption	> 200	Non supportato	Non supportato

• Onboarding in Exchange Online da exchange server locali (Cutover/Staged/Hybrid)

  Carico di lavoro	Dimensioni della cassetta postale (GB)	P50 (50° durata percentile) (giorni)	P90 (durata del 90° percentile) (giorni)
  Onboarding da locale	0 - 10	1	3
  Onboarding da locale	10 - 50	2	6
  Onboarding da locale	50 - 100	4	13
  Onboarding da locale	100 - 200	10	31
  Onboarding da locale	> 200	Non supportato	Non supportato

• Migrazione tra tenant a Exchange Online (usare la soluzione microsoft di prima parte o usare soluzioni di terze parti).

  Carico di lavoro	Dimensioni della cassetta postale (GB)	P50 (50° durata percentile) (giorni)	P90 (durata del 90° percentile) (giorni)
  Tenant incrociato	0 - 10	1	1
  Tenant incrociato	10 - 50	1	2
  Tenant incrociato	50 - 100	2	5
  Tenant incrociato	100 - 200	3	6
  Tenant incrociato	> 200	Non supportato	Non supportato

• Onboarding specializzato in Exchange Online da Gmail/G Suite/GWS (EAC, PowerShell)

  Carico di lavoro	Dimensioni della cassetta postale (GB)	P50 (50° durata percentile) (giorni)	P90 (durata del 90° percentile) (giorni)
  Onboarding gmail specializzato	0 - 10	1	2
  Onboarding gmail specializzato	10 - 50	1	8
  Onboarding gmail specializzato	50 - 100	3	12
  Onboarding gmail specializzato	100 - 200	5	19
  Onboarding gmail specializzato	> 200	Non supportato	Non supportato

• Onboarding in Exchange Online da origini IMAP (altre origini IMAP, PowerShell, Gmail tramite IMAP)

  Carico di lavoro	Dimensioni della cassetta postale (GB)	P50 (50° durata percentile) (giorni)	P90 (durata del 90° percentile) (giorni)
  Onboarding IMAP generico	0 - 10	1	1
  Onboarding IMAP generico	10 - 50	1	2
  Onboarding IMAP generico	50 - 100	1	8
  Onboarding IMAP generico	100 - 200	3	29
  Onboarding IMAP generico	> 200	Non supportato	Non supportato

• Onboarding in Exchange Online tramite importazione PST

  Carico di lavoro	Dimensioni della cassetta postale (GB)	P50 (50° durata percentile) (giorni)	P90 (durata del 90° percentile) (giorni)
  Importazione PST	0 - 10	1	1
  Importazione PST	10 - 50	1	3
  Importazione PST	50 - 100	2	5
  Importazione PST	100 - 200	3	6
  Importazione PST	> 200	Non supportato	Non supportato

Fattori relativi alle prestazioni di migrazione

La migrazione delle cassette postali/posta elettronica ha diversi fattori comuni che influiscono sulle prestazioni della migrazione.

Fattori comuni legati alle prestazioni della migrazione

La tabella seguente contiene un elenco dei fattori comuni che influiscono sulle prestazioni della migrazione. Altri dettagli sono riportati nelle sezioni che descrivono i singoli metodi di migrazione.

Fattori legati alle prestazioni della rete

In questa sezione vengono descritte le procedure consigliate per migliorare le prestazioni di rete durante la migrazione. La discussione è generica, perché l'impatto maggiore sulle prestazioni di rete durante la migrazione riguarda l'hardware di terze parti e i provider di servizi Internet (ISP).

Usare Exchange Analyzer per comprendere meglio la connettività di rete con Microsoft 365 o Office 365. Per eseguire i test di Exchange Analyzer in Microsoft Support and Recovery Assistant, passare a Diagnostica > avanzata Exchange Online > Controllare la connettività > di rete di Exchange Online Sì. Per altre informazioni su Microsoft Support and Recovery Assistant, vedere l'Assistente supporto e ripristino Microsoft.

Per un'analisi più approfondita delle migrazioni all'interno dell'ambiente, vedere l'analisi delle prestazioni della migrazione delle cassette postali. Il post include uno script per analizzare le richieste di spostamento.

Limitazione di Microsoft 365 e Office 365

Microsoft 365 e Office 365 usano vari meccanismi di limitazione per garantire la sicurezza e la disponibilità del servizio. I tre tipi seguenti di limitazione possono influire sulle prestazioni della migrazione:

• Limitazione utente
• Limitazione del servizio di migrazione
• Limitazione basata sull'integrità delle risorse

Limitazione utenti di Microsoft 365 e Office 365

La limitazione degli utenti influisce sulla maggior parte degli strumenti di migrazione di terze parti e sul metodo di migrazione con caricamento del client. Questi metodi di migrazione usano protocolli di accesso client, ad esempio RPC (Remote Procedure Call) tramite protocollo HTTP, per eseguire la migrazione dei dati delle cassette postali alle cassette postali di Microsoft 365 o Office 365. Si tratta di strumenti usati per eseguire la migrazione dei dati da piattaforme come IBM Lotus Domino e Novell GroupWise.

La limitazione delle richieste degli utenti è il metodo di limitazione più restrittivo in Microsoft 365 e Office 365. Poiché viene configurata per funzionare rispetto a un singolo utente finale, ogni utilizzo a livello di applicazione supererà facilmente i criteri di limitazione, rallentando la migrazione dei dati.

Limitazione del servizio di migrazione di Microsoft 365 e Office 365

La limitazione del servizio di migrazione influisce su tutti gli strumenti di migrazione di Microsoft 365 o Office 365. La limitazione del servizio di migrazione gestisce la concorrenza della migrazione e l'allocazione delle risorse del servizio per le soluzioni di migrazione di Microsoft 365 o Office 365.

La limitazione del servizio di migrazione influisce sulle migrazioni eseguite con i metodi seguenti:

• Migrazione IMAP
• Migrazione completa di Exchange
• Migrazione a fasi di Exchange
• Migrazioni ibride (spostamenti basati sul servizio MRSProxy in ambienti ibridi)

Un esempio di limitazione del servizio di migrazione consiste nel controllare il numero di cassette postali trasferite simultaneamente durante le migrazioni semplici di Exchange e le migrazioni IMAP. Il valore predefinito è 20. Ciò significa che viene eseguita la migrazione di un massimo di 20 cassette postali di tutti i batch di migrazione in qualsiasi momento. È possibile aumentare il numero di migrazioni simultanee delle cassette postali per un batch di migrazione nell'interfaccia di amministrazione di Exchange o in Windows PowerShell. Per altre informazioni su come ottimizzare questa impostazione, vedere Gestire i batch di migrazione in Microsoft 365 o Office 365.

Limitazione basata sull'integrità delle risorse di Microsoft 365 o Office 365

Tutti i metodi di migrazione sono soggetti alla governance della limitazione di disponibilità. La limitazione delle richieste del servizio Microsoft 365 o Office 365, tuttavia, non influisce sulle migrazioni di Microsoft 365 o Office 365 tanto quanto gli altri tipi di limitazione descritti in precedenza.

La limitazione basata sull'integrità delle risorse rappresenta il metodo di limitazione meno aggressivo. Si verifica quando c'è un problema di disponibilità del servizio che potrebbe influire sugli utenti finali e su operazioni strategiche.

Prima che le prestazioni del servizio peggiorino al punto da influire negativamente sulle prestazioni degli utenti finali, la migrazione ibrida verrà bloccata finché le prestazioni non vengono ripristinate e il servizio non torna a un livello inferiore alla soglia di limitazione.

Di seguito viene illustrato ciò che i clienti vedranno in merito alle durate di stallo usando il Get-MoveRequestStatistics - <> -IncludeReport cmdlet:

$R.REPORT.TARGETTHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 00:02:07.6222549
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:38:41.7018480
CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:26:34.6588104
DISKLATENCYTHROTTLE : 1.15:45:37.7873632

$R.REPORT.SOURCETHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 3.03:21:07.7192848
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:00:00

CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:00:00
DISKLATENCYTHROTTLE : 00:20:47.1101552
MDBMAINTENANCETHROTTLE : 00:00:00

Soluzione e pratica:

Se si verifica una situazione analoga, attendere che le risorse di Microsoft 365 o Office 365 diventino disponibili.

Fattori relativi alle prestazioni e procedure consigliate per le migrazioni di distribuzione non ibride

Questa sezione descrive i fattori che influiscono sulle migrazioni IMAP, complete o a fasi. Identifica inoltre le procedure consigliate per migliorare le prestazioni.

Fattore 1: origine dati per migrazioni di distribuzione non ibride

Nella tabella seguente viene descritto l'impatto sulla migrazione prodotto dai server di origine nell'organizzazione di posta elettronica corrente e le procedure consigliate per ridurre tale impatto.

Fattore 2: Server di migrazione per migrazioni di distribuzione non ibride

Le migrazioni IMAP, complete e a fasi sono metodi di migrazione con pull dei dati avviati sul cloud, quindi non è necessario avere un server dedicato. Gli host del protocollo con connessione Internet (IMAP o PROTOCOLLO RPC su HTTP), tuttavia, funzionano come server di migrazione per la migrazione di cassette postali e dati delle cassette postali a Microsoft 365 o Office 365. Pertanto, i fattori di prestazioni della migrazione e le procedure consigliate, descritte nella sezione precedente sul server di origine dati per l'organizzazione di posta elettronica corrente, si applicano anche ai server perimetrali Internet. Per le organizzazioni di Exchange 2007, Exchange Server 2010 e Exchange 2013, il server Accesso client funge da server di migrazione.

Per altre informazioni, vedere:

• Exchange Server 2007: Monitoraggio dei server accesso client

• Exchange Server 2010: contatori del server Accesso client

• Exchange Server 2013: gestione del carico di lavoro di Exchange

• Exchange Server 2016: gestione del carico di lavoro degli utenti in Exchange Server

• Exchange Server 2019: gestione del carico di lavoro degli utenti in Exchange Server

Fattore 3: motore di migrazione per migrazioni di distribuzione non ibride

Le migrazioni di Exchange IMAP, cutover e a fasi vengono eseguite usando il dashboard migrazione nell'interfaccia di amministrazione di Exchange. Questo è soggetto alla limitazione del servizio di migrazione di Microsoft 365 o Office 365.

Soluzione e pratica:

I clienti ora possono specificare la simultaneità delle migrazioni, ad esempio il numero di cassette postali da trasferire simultaneamente, usando Windows PowerShell. Il valore predefinito è 20 cassette postali. Dopo aver creato un batch di migrazione, è possibile usare il cmdlet di Windows PowerShell seguente per aumentare questo valore fino a un massimo di 100.

Set-MigrationEndPoint <Identity> -MaxConcurrentMigrations <value between 1 and 100>

Per altre informazioni, vedere Gestire i batch di migrazione in Microsoft 365 o Office 365.

Fattore 4: Rete per migrazioni di distribuzione non ibride

Test di verifica:

In base al metodo di migrazione, è possibile provare i test di verifica seguenti:

• Migrazioni IMAP: prepopolare una cassetta postale di origine con dati di esempio. Quindi da Internet (all'esterno della rete locale), connettersi alla cassetta postale di origine usando un client di posta elettronica IMAP standard, ad esempio Microsoft Outlook, e quindi misurare le prestazioni di rete determinando il tempo necessario per scaricare tutti i dati dalla cassetta postale di origine. La velocità effettiva deve essere simile a quella che i clienti possono ottenere usando lo strumento di migrazione IMAP in Microsoft 365 o Office 365, dato che non esistono altri vincoli.

• Migrazioni di Exchange a fasi e cutover: prepopolare una cassetta postale di origine con dati di esempio. Quindi, da Internet (all'esterno della rete locale), connettersi alla cassetta postale di origine con Outlook usando RPC tramite protocollo HTTP. Assicurarsi di connettersi usando la modalità memorizzata nella cache. Misurare le prestazioni di rete controllando quanto tempo richiede la sincronizzazione di tutti i dati della cassetta postale di origine. La velocità effettiva deve essere simile a quella che i clienti possono ottenere usando i semplici strumenti di migrazione di Exchange in Microsoft 365 o Office 365, dato che non esistono altri vincoli.

Durante una migrazione IMAP, completa o a fasi di Exchange si potrebbe verificare un sovraccarico. La velocità effettiva, tuttavia, dovrebbe essere simile a quella dei risultati di questi test di verifica.

Fattore 5: servizio Microsoft 365 e Office 365 per migrazioni di distribuzione non ibride

La limitazione basata sull'integrità delle risorse di Microsoft 365 o Office 365 influisce sulle migrazioni usando gli strumenti di migrazione semplici di Microsoft 365 o Office 365 nativi. Vedere la sezione relativa alla limitazione basata sull'integrità delle risorse di Microsoft 365 o Office 365 .

Spostare le richieste in Microsoft 365 o Office 365

Per informazioni generali sul recupero di informazioni sullo stato per le richieste di spostamento, vedere Visualizzare le proprietà delle richieste di spostamento:

• Move-Mailbox

• [Get-MoveRequestStatistics]] (/powershell/module/exchange/get-moverequeststatistics)

Nel servizio Microsoft 365 o Office 365 la coda di migrazione e le risorse del servizio allocate per le migrazioni vengono condivise tra i tenant e influiscono sulla modalità di gestione delle richieste di spostamento in ogni fase del processo di spostamento.

Esistono due tipi di richieste di spostamento in Microsoft 365 e Office 365:

• Onboarding delle richieste di spostamento: le migrazioni dei nuovi clienti vengono considerate come richieste di spostamento di onboarding. Queste richieste hanno una priorità standard.

• Richieste interne di "spostamento" del data center: si tratta di richieste di spostamento delle cassette postali avviate dai team operativi del data center. Queste richieste hanno una priorità più bassa, perché l'esperienza degli utenti finali non ne risente qualora vengano ritardate.

Impatto e ritardi potenziali per le richieste di spostamento con stato "Accodato" e "In corso"

• Richieste di spostamento in coda: questo stato specifica che lo spostamento è stato accodato e che è in attesa che il servizio di replica delle cassette postali di Exchange lo selezioni. Per le richieste di spostamento di Exchange 2003, gli utenti possono comunque accedere alle loro cassette postali in questa fase.

  Due fattori influiscono sulla richiesta che verrà gestita dal servizio di replica delle cassette postali:

  • Priorità: le richieste di spostamento in coda con priorità più alta vengono prelevate prima delle richieste di spostamento con priorità inferiore. In questo modo ci si assicura che le richieste di spostamento delle migrazioni dei clienti vengano sempre elaborate prima di quelle interne al data center.

  • Posizione nella coda: se le richieste di spostamento hanno la stessa priorità, prima la richiesta entra nella coda, prima verrà prelevata dal servizio di replica delle cassette postali. Poiché potrebbero esserci più clienti che eseguono le migrazioni delle cassette postali contemporaneamente, è normale che le nuove richieste di spostamento rimangano nella coda prima di essere elaborate.

Spesso il tempo di attesa nella coda prima che le richieste di cassette postali vengano elaborate non viene considerato durante la pianificazione della migrazione. Il risultato è che ai clienti non viene assegnato un tempo sufficiente per completare tutte le migrazioni pianificate.

• Richieste di spostamento in corso: questo stato specifica che lo spostamento è ancora in corso. Se si tratta di uno spostamento di cassette postali online, l'utente avrà comunque la possibilità di accedervi.

Quando la richiesta di spostamento delle cassette postali ha lo stato "in corso", la priorità non ha più importanza e le nuove richieste di spostamento verranno elaborate solo dopo il completamento di quelle attualmente in corso, anche se la nuova richiesta ha una priorità più alta.

Procedure consigliate

Pianificazione: come accennato in precedenza, poiché gli utenti di Exchange 2003 perdono l'accesso durante una migrazione ibrida, i clienti di Exchange 2003 sono in genere più preoccupati quando pianificare le migrazioni e quanto tempo impiegano.

Quando si pianifica il numero di cassette postali di cui eseguire la migrazione durante uno specifico periodo di tempo, considerare quanto segue:

• Includere la quantità di tempo in cui la richiesta di spostamento sarà in attesa nella coda. Per calcolarlo, usare la formula seguente:

  (numero totale di cassette postali di cui eseguire la migrazione) = ((tempo totale) - (tempo medio coda)) * (velocità effettiva della migrazione)

  dove la velocità effettiva della migrazione equivale al numero totale di cassette postali che è possibile spostare ogni ora.

Si supponga ad esempio di avere una finestra temporale di sei ore per eseguire la migrazione delle cassette postali. Se il tempo medio della coda è di un'ora e si dispone di una velocità effettiva di migrazione di 100 cassette postali all'ora, è possibile eseguire la migrazione di 500 cassette postali nell'intervallo di tempo di sei ore: 500 = (6 - 1) * 100.

• Avviare la migrazione prima di quanto inizialmente pianificato per tenere conto del tempo in coda. Quando le cassette postali sono in coda, gli utenti di Exchange 2003 possono comunque accedere alle loro cassette postali.

Determinare il tempo di coda: il tempo di coda cambia sempre perché Microsoft non gestisce le pianificazioni della migrazione dei clienti.

Per determinare il potenziale tempo in coda, è possibile provare a pianificare uno spostamento di test diverse ore prima dell'avvio della migrazione effettiva. Quindi, in base alla quantità di tempo osservata durante il quale la richiesta rimane in coda, è possibile stimare in modo più accurato quando iniziare la migrazione e quante cassette postali è possibile spostare in uno specifico periodo.

Ad esempio, se una migrazione di test è stata completata quattro ore prima dell'inizio di una migrazione pianificata. Il cliente determina che il tempo trascorso in coda per la migrazione di prova è stato di circa un'ora. Quindi, il cliente deve prendere in considerazione l'avvio della migrazione un'ora prima di quanto originariamente previsto per assicurarsi che ci sia abbastanza tempo per completare tutte le migrazioni.

Strumenti di terze parti per le migrazioni di Microsoft 365 o Office 365

Gli strumenti di terze parti vengono usati principalmente negli scenari di migrazione che non coinvolgono Exchange, ad esempio quelli di Gmail/G Suite/GWS (Google Workspace), IBM Lotus, Domino e Novell GroupWise. Questa sezione riguarda principalmente i protocolli di migrazione usati da strumenti di terze parti, piuttosto che i prodotti e gli strumenti specifici. La tabella seguente fornisce un elenco di fattori applicabili agli strumenti di terze parti per gli scenari di migrazione di Microsoft 365 o Office 365.

Fattore 1: origine dati per le migrazioni di strumenti di terze parti

Fattore 2: Server di migrazione per migrazioni di strumenti di terze parti

La maggior parte degli strumenti di terze parti per le migrazioni di Microsoft 365 o Office 365 è avviata dal client ed esegue il push dei dati in Microsoft 365 o Office 365. Questi strumenti richiedono in genere un server di migrazione. A questi server di migrazione si applicano fattori come le prestazioni di sistema, le attività di back-end e i criteri di limitazione dei server di origine.

Soluzione e pratica:

Per migliorare le prestazioni della migrazione quando si usa un server di migrazione, applicare le stesse procedure consigliate descritte nella sezione Factor 1: Origine dati per le migrazioni di strumenti di terze parti .

Fattore 3: Motore di migrazione per le migrazioni di strumenti di terze parti

Per gli strumenti di migrazione di terze parti, i protocolli più diffusi sono Servizi Web Exchange e RPC su HTTP.

Servizi Web Exchange:

Servizi Web Exchange è il protocollo consigliato da usare per la migrazione a Microsoft 365 o Office 365 perché supporta batch di dati di grandi dimensioni e offre una migliore limitazione orientata ai servizi. In Microsoft 365 o Office 365, se usate in modalità di rappresentazione, le migrazioni che usano Servizi Web Exchange non utilizzano la quantità preventivata di risorse di Microsoft 365 o Office 365 Exchange Web Services dell'utente, utilizzando invece una copia delle risorse preventivate:

• Tutte le chiamate che rappresentano Servizi Web Exchange effettuate dallo stesso account di amministratore vengono calcolate separatamente rispetto al budget applicato a tale account.

• Per ogni sessione di rappresentazione, viene creata una copia shadow del budget effettivo dell'utente. Tutte le migrazioni di questa specifica sezione consumeranno questa copia shadow.

• La limitazione in rappresentazione è isolata per ogni sessione di migrazione degli utenti.

• I criteri di limitazione dei servizi Web Exchange possono essere modificati temporaneamente nel tenant (per una durata di 30, 60 o 90 giorni) per consentire il completamento della migrazione. Questa richiesta può essere richiesta dalla sezione Della Guida dell'interfaccia di amministrazione di Microsoft 365.

Procedure consigliate:

• Le prestazioni della migrazione per gli utenti che usano strumenti di terze parti basati sulla rappresentazione di EWA competono con le migrazioni basate su Servizi Web Exchange e con l'utilizzo delle risorse da parte di altri tenant. Pertanto, le prestazioni della migrazione possono variare.

• Se possibile, usare strumenti di migrazione di terze parti basati sulla rappresentazione di Servizi Web Exchange, perché in genere sono più veloci ed efficienti rispetto all'uso di protocolli come RPC su HTTP.

Protocollo RPC su HTTP:

Le soluzioni di migrazione tradizionali usano il protocollo RPC su HTTP. Questo metodo è completamente basato su un modello di accesso client, ad esempio quello di Outlook, e la scalabilità e le prestazioni sono limitate perché il servizio Microsoft 365 o Office 365 limita l'accesso presupponendo che l'utilizzo sia da parte di un utente anziché da un'applicazione.

Procedure consigliate:

• Per gli strumenti di migrazione che usano RPC tramite protocollo HTTP, è una procedura comune aumentare la velocità effettiva della migrazione aggiungendo più server di migrazione e usando più account utente amministrativi di Microsoft 365 o Office 365. Questa procedura può ottenere il parallelismo dell'inserimento dei dati e ottenere una velocità effettiva dei dati più elevata perché ogni utente amministratore è soggetto alla limitazione delle richieste degli utenti di Microsoft 365 e Office 365. Molti clienti aziendali segnalano di aver dovuto configurare più di 40 server di migrazione per ottenere una velocità effettiva di 20-30 GB/ora.

• Nella fase di sviluppo degli strumenti di migrazione, è fondamentale valutare il numero di operazioni RPC necessarie per eseguire la migrazione di un messaggio. A questo scopo, sono stati raccolti i log acquisiti dai servizi di Microsoft 365 o Office 365 per due soluzioni di migrazione di terze parti (sviluppate da società di terze parti) usate dai clienti per eseguire la migrazione delle cassette postali a Microsoft 365 o Office 365. Abbiamo confrontato le due soluzioni di migrazione sviluppate da altre aziende. Per ogni soluzione, abbiamo confrontato la migrazione di due cassette postali e il relativo caricamento in un file PST di Outlook. Ecco i risultati.

Fattore 4: Rete per le migrazioni di strumenti di terze parti

Procedura consigliata:

Per le soluzioni di migrazione di terze parti che usano il protocollo RPC su HTTP, ecco un metodo valido per misurare le potenziali prestazioni di migrazione:

1. Dal server di migrazione connettersi alla cassetta postale di Microsoft 365 o Office 365 con Outlook tramite RPC tramite protocollo HTTP. Assicurarsi di non connettersi usando la modalità cache.

2. Importare un file pst di grandi dimensioni con dati di esempio nella cassetta postale di Microsoft 365 o Office 365.

3. Misurare le prestazioni della migrazione calcolando il tempo richiesto per caricare il file PST. La velocità effettiva della migrazione dovrebbe essere simile a quella che i clienti possono ottenere con uno strumento di migrazione di terze parti che usa il protocollo RPC su HTTP, purché non siano presenti altri vincoli. Durante una migrazione effettiva si verifica un sovraccarico, quindi la velocità potrebbe essere leggermente diversa.

Fattore 5: servizio Microsoft 365 e Office 365

La limitazione basata sull'integrità delle risorse di Microsoft 365 e Office 365 influisce sulle migrazioni che usano strumenti di migrazione di terze parti. Per altre informazioni, vedere Limitazione basata sull'integrità delle risorse di Microsoft 365 e Office 365 .