Partage via

Performances et meilleures pratiques en matière de migration des e-mails vers Microsoft 365 et Office 365

  • Article

Il existe de nombreux chemins permettant de migrer les données de messagerie d’une organisation hébergée localement vers Microsoft 365 ou Office 365. Lors de la planification d’une migration vers Microsoft 365 ou Office 365, une compréhension claire du processus de migration des données et de la rapidité permet aux administrateurs de mieux planifier.

Vue d’ensemble de la migration du courrier électronique vers Microsoft 365 ou Office 365

Microsoft 365 ou Office 365 prend en charge plusieurs méthodes pour migrer les données de courrier, de calendrier et de contact de votre environnement de messagerie existant vers Microsoft 365 ou Office 365, comme décrit dans Méthodes de migration de plusieurs comptes de messagerie vers Microsoft 365 ou Office 365.

Pour les questions relatives au réseau et aux performances sur Microsoft 365 ou Office 365, voir Planification réseau et réglage des performances pour Microsoft 365 ou Office 365.

Méthodes de migration utilisées le plus souvent

Méthode de migration Description Ressources
Migration de IMAP (Internet Message Access Protocol) Vous pouvez utiliser le Centre d’administration Exchange ou Exchange Online PowerShell pour migrer le contenu des boîtes aux lettres des utilisateurs d’un système de messagerie IMAP vers leurs boîtes aux lettres Microsoft 365 ou Office 365. Cela inclut la migration de vos boîtes aux lettres à partir d'autres services de courrier hébergés, tels que Gmail ou Yahoo Mail. Notez qu’Exchange Online propose désormais un processus hautement spécialisé dans le centre d’administration exchange moderne pour la migration des e-mails d’un déploiement Gmail/G Suite/Google WorkSpace (GWS) existant d’une organisation vers Exchange Online. Migrer vos boîtes aux lettres IMAP vers Microsoft 365 ou Office 365
Migration à basculement Utilisez la migration à basculement pour migrer toutes les boîtes aux lettres locales vers Microsoft 365 ou Office 365 sur quelques jours. Utilisez la migration à basculement si vous envisagez de déplacer l’ensemble de votre organisation de messagerie vers Microsoft 365 ou Office 365 et de gérer les comptes d’utilisateur dans Microsoft 365 ou Office 365. Vous pouvez migrer un maximum de 2 000 boîtes aux lettres de votre organisation Exchange locale vers Microsoft 365 ou Office 365 à l’aide d’une migration à basculement. Toutefois, le nombre recommandé de boîtes aux lettres est de 150. Les performances peuvent probablement se dégrader avec des nombres supérieurs à cela. Les contacts de courrier et les groupes de distribution dans votre organisation Exchange locale sont également migrés. Migration à basculement vers Microsoft 365 ou Office 365
Migration intermédiaire Utilisez la migration intermédiaire si vous envisagez de migrer à terme toutes les boîtes aux lettres de votre organisation vers Microsoft 365 ou Office 365, au fil du temps. À l’aide d’une migration intermédiaire, vous migrez des lots de boîtes aux lettres locales vers Microsoft 365 ou Office 365 au cours de quelques semaines ou mois. Ce que vous devez savoir sur une migration intermédiaire du courrier électronique vers Microsoft 365 ou Office 365
Déploiement hybride Le déploiement hybride offre aux organisations la possibilité d’étendre au cloud l’expérience riche en fonctionnalités et le contrôle administratif dont elles disposent avec leur organisation Exchange locale existante. Un déploiement hybride offre l’apparence transparente d’une seule organisation Exchange entre une organisation Exchange locale et Exchange Online dans Microsoft 365 ou Office 365. En outre, un déploiement hybride peut servir d’étape intermédiaire pour passer complètement à une organisation Microsoft 365 ou Office 365. Conseiller de migration de messagerie Microsoft 365 et Office 365

Déploiements hybrides Exchange Server

Conseiller de migration de messagerie

Assistant Déploiement Exchange pour Exchange local 2013/2016/2019

Déploiements hybrides Exchange Server 2013

Configuration hybride minimale
Migration tierce De nombreux outils sont proposés par des tiers. Ils utilisent des protocoles et des approches distincts pour effectuer des migrations d’e-mails à partir de plateformes de messagerie comme GWS, GoDaddy, Yahoo, IBM Lotus Notes et Novell GroupWise. Voici quelques partenaires et outils de migration tiers pouvant vous aider lors de migrations Exchange à partir de plateformes tierces :

Arborescence / binaireQuête / QuadroTech : Arbre binaire et QuadroTech font désormais partie de Quest. Quest est un fournisseur de logiciels de migration et de coexistence de messagerie multiplateforme, avec des produits pour l’analyse, la coexistence et la migration entre plusieurs plateformes vers Exchange Online. Les solutions de quête synchronisent les boîtes aux lettres, les dossiers publics et les informations de calendrier tout en conservant la coexistence tout au long de la migration.

BitTitan : fournit une solution automatisée pour les migrations vers Microsoft 365 ou Office 365 à partir d’un large éventail de plateformes.

CodeTwo : fournisseur de solutions de migration Microsoft 365 et Office 365 pour des migrations de données sécurisées et automatisées vers Microsoft 365 (Office 365) à partir de serveurs Exchange locaux, IMAP et entre des locataires Microsoft 365.

Transvault : fournisseur de solutions de migration Office cloud vers Microsoft 365 à partir d’Exchange et Notes. Transvault prend en charge des dizaines de sources pour la migration et propose des produits qui fournissent n’importe quelle taille de projet, des migrations d’archivage d’e-mails complexes et la gestion PST. Les solutions de migration d’entreprise sont sécurisées, conformes, efficaces et axées sur l’utilisateur, et peuvent être exécutées localement et dans le cloud.

SkyKick : fournisseur de solutions de migration automatisée pour passer de plusieurs types de sources à Microsoft 365 ou Office 365. Les outils de migration de bout en bout fournissent une aide aux partenaires en ce qui concerne les ventes, la planification, la migration, la gestion et les phases sur site du projet de migration.

BCC : Aider les entreprises en soutenant leur stratégie de migration de collaboration. Meilleur fournisseur d’outils de migration basés sur la plateforme Domino, pour la migration vers Microsoft Exchange, Microsoft 365 et Office 365.

Performances des méthodes de migration

Les sections suivantes comparent les charges de travail de migration de boîte aux lettres et les résultats de performances observés pour les différentes méthodes de migration des boîtes aux lettres et des données de boîte aux lettres vers Microsoft 365 ou Office 365. Ces résultats sont basés sur les tests internes et les migrations réelles des clients vers Microsoft 365 ou Office 365.

Importante

En raison des différences dans la façon dont les migrations sont effectuées et quand elles sont effectuées, votre vitesse de migration réelle peut varier.

Charges de travail de migration de client

Le tableau suivant décrit les différentes charges de travail impliquées dans une migration classique, ainsi que les défis et les options pour chacune d’elles.

Charge de travail Remarques
Intégration (migration vers Microsoft 365 ou Office 365) Microsoft offre des fonctionnalités et des outils de migration de données que les clients peuvent utiliser pour migrer leurs données à partir d’Exchange Server en local (via l’hybrideintermédiaire/ à basculement/) ou de Gmail/S Suite/GWS alias Google Work Space (via EAC, PowerShell) ou à partir d’autres sources IMAP (PowerShell, Gmail via IMAP) ou des migrations inter-locataires vers Exchange Online dans Microsoft 365 ou Office 365.
Multi-Géo Les entreprises multinationales ayant des bureaux dans le monde entier ont souvent besoin de stocker leurs données d’employés au repos dans des régions spécifiques, afin de répondre à leurs exigences de résidence des données. Multigéographique permet à une seule organisation Microsoft 365 ou Office 365 de s’étendre sur plusieurs zones géographiques de centres de données Microsoft 365 ou Office 365, ce qui vous donne la possibilité de stocker des données Exchange, au repos, par utilisateur, dans les zones géographiques choisies. Pour plus d’informations, consultez Obtenir des contrôles d’emplacement de données globaux de niveau entreprise avec multigéographique.
Chiffrement Le chiffrement de service avec clé client est une fonctionnalité qui permet à un client de provisionner et de gérer les clés racines utilisées pour chiffrer les données au repos au niveau de la couche application dans Microsoft 365 ou Office 365. Pour qu’une boîte aux lettres soit chiffrée la première fois, un déplacement de boîte aux lettres est nécessaire. Pour plus d’informations, consultez Chiffrement du service avec la clé client Microsoft Purview.
GoLocal Microsoft continue d’ouvrir de nouveaux centres de données dans de nouvelles régions ou zones géographiques. Les clients existants, lorsqu’ils sont éligibles, peuvent demander à ce que leurs données client de leur centre de données d’origine soient déplacées vers une nouvelle zone géographique. La période pendant laquelle vous pouvez effectuer cette demande est généralement d’un ou deux ans, en fonction de la demande globale pour le service. Notez que cette période pendant laquelle vous pouvez demander le déplacement de vos données client devient plus courte une fois qu’un centre de données (DC) pour la nouvelle zone géographique démarre (à ce stade, vous avez environ trois à six mois pour demander un déplacement). Les détails sont disponibles dans Déplacement de données principales vers de nouvelles zones géographiques de centre de données Microsoft 365.

Lorsque des boîtes aux lettres sont migrées dans des centres de données Microsoft 365, chaque déplacement de boîte aux lettres ou de boîte aux lettres en bloc nécessite du temps pour que l’opération se termine. Il existe un certain nombre de facteurs, tels que l’activité du service Microsoft 365, qui peuvent affecter exactement la durée. Le service est conçu pour limiter les charges de travail discrétionnaires telles que les déplacements de boîtes aux lettres, afin de garantir que le service s’exécute de manière optimale pour tous les utilisateurs. Toutefois, vous pouvez toujours vous attendre à ce que les déplacements de boîte aux lettres soient traités, en fonction de la disponibilité discrétionnaire des ressources du service. Pour plus d’informations sur la limitation des ressources, consultez ce billet de blog.

Estimations de la durée de la migration de boîtes aux lettres dans Exchange Online

Pour vous aider à planifier votre migration, les tableaux suivants présentent des instructions sur la fin des migrations de boîtes aux lettres en bloc ou des migrations individuelles. Ces estimations sont basées sur une analyse des données des migrations de clients précédentes. Étant donné que chaque environnement est unique, votre vitesse de migration exacte peut varier.

Durée de migration de boîte aux lettres en fonction des profils de taille de boîte aux lettres :

  • GoLocal/Multigéographique/Chiffrement dans Exchange Online

    Charge de travail Taille de boîte aux lettres (Go) P50 (durée du 50e centile) (jours) P90 (durée du 90e centile) (jours)
    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 pris en charge Non pris en charge

  • Intégration à Exchange Online à partir de serveurs Exchange locaux (basculement//intermédiaire hybride)

    Charge de travail Taille de boîte aux lettres (Go) P50 (durée du 50e centile) (jours) P90 (durée du 90e centile) (jours)
    Intégration à partir d’un site local 0 - 10 1 3
    Intégration à partir d’un site local 10 - 50 2 6
    Intégration à partir d’un site local 50 - 100 4 13
    Intégration à partir d’un site local 100 - 200 10 31
    Intégration à partir d’un site local > 200 Non pris en charge Non pris en charge

  • Migration interlocataire vers Exchange Online (utilisez une solution interne Microsoft ou des solutions tierces).

    Charge de travail Taille de boîte aux lettres (Go) P50 (durée du 50e centile) (jours) P90 (durée du 90e centile) (jours)
    Interlocataire 0 - 10 1 1
    Interlocataire 10 - 50 1 2
    Interlocataire 50 - 100 2 5
    Interlocataire 100 - 200 3 6
    Interlocataire > 200 Non pris en charge Non pris en charge

  • Intégration spécialisée à Exchange Online à partir de Gmail/G Suite/GWS (EAC, PowerShell)

    Charge de travail Taille de boîte aux lettres (Go) P50 (durée du 50e centile) (jours) P90 (durée du 90e centile) (jours)
    Intégration Gmail spécialisée 0 - 10 1 2
    Intégration Gmail spécialisée 10 - 50 1 8
    Intégration Gmail spécialisée 50 - 100 3 12
    Intégration Gmail spécialisée 100 - 200 5 19
    Intégration Gmail spécialisée > 200 Non pris en charge Non pris en charge

  • Intégration à Exchange Online à partir de sources IMAP (autres sources IMAP, PowerShell, Gmail via IMAP)

    Charge de travail Taille de boîte aux lettres (Go) P50 (durée du 50e centile) (jours) P90 (durée du 90e centile) (jours)
    Intégration IMAP générique 0 - 10 1 1
    Intégration IMAP générique 10 - 50 1 2
    Intégration IMAP générique 50 - 100 1 8
    Intégration IMAP générique 100 - 200 3 29
    Intégration IMAP générique > 200 Non pris en charge Non pris en charge

  • Intégration à Exchange Online via l’importation PST

    Charge de travail Taille de boîte aux lettres (Go) P50 (durée du 50e centile) (jours) P90 (durée du 90e centile) (jours)
    Importation PST 0 - 10 1 1
    Importation PST 10 - 50 1 3
    Importation PST 50 - 100 2 5
    Importation PST 100 - 200 3 6
    Importation PST > 200 Non pris en charge Non pris en charge

Remarque

La réalisation de certaines boîtes aux lettres hors norme prend plus de temps en fonction du profil de boîte aux lettres. En outre, si un locataire a en moyenne des boîtes aux lettres plus volumineuses, cela peut également contribuer à la durée prolongée de la migration.

Facteurs de performances de migration

La migration de boîtes aux lettres/e-mails a plusieurs facteurs communs qui affectent les performances de la migration.

Facteurs de performances de migration communs

Le tableau suivant fournit une liste de facteurs courants qui affectent les performances de la migration. Plus de détails sont fournis dans les sections décrivant les méthodes de migration individuelles.

Facteur Description Exemple
Source de données Le périphérique ou le service qui héberge les données à migrer. Nombre de limitations peuvent s'appliquer à la source de données en raison de spécifications matérielles, de la charge de travail des utilisateurs finaux et des tâches de maintenance du serveur principal. Gmail limite la quantité de données pouvant être extraites pendant une période spécifique.
Type de données et densité En raison de la nature unique de l'entreprise d'un client, le type et la combinaison d'éléments de courrier au sein des boîtes aux lettres varient considérablement. Une boîte aux lettres de 4 Go avec 400 éléments, chacun avec 10 mégaoctets (Mo) de pièces jointes, migrera plus vite qu'une boîte aux lettres de 4 Go avec 100 000 éléments plus petits.
Serveur de migration De nombreuses solutions de migration utilisent un serveur de migration ou de poste de travail de type « boîte de renvoi » pour effectuer la migration. Les clients utilisent souvent une machine virtuelle avec de faibles performances afin d'héberger le service MRSProxy pour des déploiements hybrides ou pour des migrations non hybrides de PC clients.
Moteur de migration Le moteur de migration de données responsable de l’extraction des données du serveur source convertit les données, si nécessaire. Le moteur transmet ensuite les données sur le réseau et injecte les données dans la boîte aux lettres Microsoft 365 ou Office 365. Boîte aux lettres. Le service MRSProxy possède ses propres fonctionnalités et limitations.
Équipements du réseau local Les performances réseau de bout en bout (de la source de données aux serveurs d’accès au client Exchange Online) affectent les performances de migration. Configuration du pare-feu et caractéristiques de l'organisation locale.
Service Microsoft 365 ou Office 365 Microsoft 365 et Office 365 disposent d’une prise en charge et de fonctionnalités intégrées pour gérer la charge de travail de migration. La stratégie de limitation des utilisateurs a des paramètres par défaut et limite la vitesse de transfert maximale totale des données.

Facteurs de performances réseau

Cette section décrit les meilleures pratiques pour améliorer les performances réseau durant la migration. La discussion est d'ordre général, car l'impact le plus important sur les performances du réseau lors de la migration est lié au matériel tiers et aux fournisseurs de services Internet.

Utilisez Exchange Analyzer pour mieux comprendre votre connectivité réseau avec Microsoft 365 ou Office 365. Pour exécuter les tests De l’analyseur Exchange dans l’Assistant Support et récupération Microsoft, accédez à Diagnostics avancés > Exchange Online > Vérifier la connectivité > réseau Exchange Online Oui. En savoir plus sur l’Assistant Support et récupération Microsoft pour en savoir plus sur l’Assistant Support et récupération Microsoft.

Facteur Description Meilleures pratiques
Capacité réseau Le temps nécessaire à la migration des boîtes aux lettres vers Microsoft 365 ou Office 365 est déterminé par la capacité disponible et maximale de votre réseau. Identifiez votre capacité réseau disponible et déterminez la capacité maximale de téléchargement.
Contactez votre fournisseur de services Internet pour confirmer la bande passante allouée et pour obtenir des détails sur les restrictions, telles que le montant total des données qui peuvent être transférées au cours d'une période spécifique.
Utilisez les outils pour évaluer la capacité réelle de votre réseau. Vérifiez que vous testez le flux de données de bout en bout à partir de votre source de données locale vers les serveurs de passerelle du centre de données Microsoft.
Identifiez les autres charges de votre réseau (par exemple, les utilitaires de sauvegarde et la maintenance planifiée) qui peuvent affecter la capacité de votre réseau.
Stabilité du réseau Un réseau rapide ne permet pas toujours d'effectuer des migrations rapides. Si le réseau n'est pas stable, le transfert de données est plus long en raison de la correction des erreurs. Selon le type de migration, la correction des erreurs peut considérablement affecter les performances de la migration. Les problèmes liés au matériel réseau et aux pilotes entraînent souvent des problèmes de stabilité du réseau. Travaillez avec vos fournisseurs de matériel pour comprendre vos périphériques réseau et appliquer les pilotes les plus récents des fournisseurs et les mises à jour logicielles.
Retards de réseau La fonctionnalité de détection des intrusions configurée sur un pare-feu réseau provoque souvent des retards importants sur le réseau et affecte les performances de la migration.
La migration de données vers des boîtes aux lettres Microsoft 365 ou Office 365 repose sur votre connexion Internet. Les retards sur Internet affectent les performances générales de migration.
En outre, les utilisateurs de la même société peuvent avoir des boîtes aux lettres dans le cloud se trouvant dans des centres de données à différents emplacements géographiques. Selon le fournisseur de services Internet du client, les performances de migration peut varier.		 Évaluez les délais de réseau vers tous les centres de données Microsoft potentiels pour garantir la cohérence du résultat. (Cela permet également de garantir une expérience cohérente pour les utilisateurs finaux.) Collaborez avec votre isp pour résoudre les problèmes liés à Internet.
Ajoutez des adresses IP pour les serveurs de centre de données Microsoft à votre liste verte, ou contournez tout le trafic lié à la migration à partir de votre pare-feu réseau. Pour plus d’informations sur les plages d’adresses IP Microsoft 365 ou Office 365, voir URL et plages d’adresses IP Microsoft 365 et Office 365.

Pour une analyse plus approfondie des migrations au sein de votre environnement, consultez notre analyse des performances de migration des boîtes aux lettres. Le billet inclut un script pour vous aider à analyser les demandes de déplacement.

Limitation de Microsoft 365 et Office 365

Microsoft 365 et Office 365 utilisent différents mécanismes de limitation pour garantir la sécurité et la disponibilité des services. Les trois types suivants de limitation peuvent affecter les performances de la migration :

  • Limitation d'utilisateurs
  • Limitation du service de migration
  • Limitation basée sur l'intégrité des ressources

Remarque

Les trois types de limitation Microsoft 365 et Office 365 n’affectent pas toutes les méthodes de migration.

Limitation des utilisateurs Microsoft 365 et Office 365

La limitation des utilisateurs a une incidence sur la plupart des outils de migration tiers et la méthode de migration de téléchargement de client. Ces méthodes de migration utilisent des protocoles d’accès client, tels que l’appel de procédure distante (RPC) sur le protocole HTTP, pour migrer les données de boîte aux lettres vers des boîtes aux lettres Microsoft 365 ou Office 365. Ces outils sont utilisés pour migrer les données à partir de plateformes telles qu'IBM Lotus Domino et Novell GroupWise.

La limitation des utilisateurs est la méthode de limitation la plus restrictive dans Microsoft 365 et Office 365. Étant donné que la limitation des utilisateurs est configurée pour opérer par rapport à un utilisateur individuel, toute utilisation de niveau application dépassera facilement la stratégie de limitation et entraînera une migration plus lente des données.

Limitation du service de migration Microsoft 365 et Office 365

La limitation du service de migration affecte tous les outils de migration Microsoft 365 ou Office 365. La limitation du service de migration gère la concurrence de migration et l’allocation des ressources de service pour les solutions de migration Microsoft 365 ou Office 365.

La limitation du service de migration affecte les migrations effectuées à l'aide des méthodes de migration suivantes :

  • Migration IMAP
  • Migration Exchange à basculement
  • Migration intermédiaire Exchange
  • Migrations hybride (déplacements basés sur un service MRSProxy dans un environnement hybride)

Importante

Les méthodes de migration mentionnées ci-dessus ne sont pas affectées par la limitation des utilisateurs.

Un exemple de limitation du service de migration est le contrôle du nombre de boîtes aux lettres qui sont déplacées simultanément lors de migrations Exchange simples et de migrations IMAP. La valeur par défaut est 20. Cela signifie qu’un maximum de 20 boîtes aux lettres de tous les lots de migration sont migrées à tout moment. Vous pouvez augmenter le nombre de migrations de boîtes aux lettres simultanées pour un lot de migration dans le Centre d’administration Exchange ou Windows PowerShell. Pour en savoir plus sur l’optimisation de ce paramètre, voir Gérer les lots de migration dans Microsoft 365 ou Office 365.

Limitation basée sur l’intégrité des ressources Microsoft 365 ou Office 365

Toutes les méthodes de migration sont soumises à la gouvernance de la limitation de disponibilité. Toutefois, la limitation du service Microsoft 365 ou Office 365 n’affecte pas les migrations Microsoft 365 ou Office 365 autant que les autres types de limitation décrits précédemment.

La limitation basée sur l'intégrité des ressources est la méthode de limitation la moins restrictive. Elle intervient pour éviter tout problème de disponibilité du service susceptible d'affecter les utilisateurs finaux et les opérations de service critiques.

Avant toute dégradation des performances du service pouvant se répercuter sur les performances de l'utilisateur final, les migrations hybrides sont mises en attente jusqu'à ce que les performances soient récupérées et le service renvoie à un niveau inférieur au seuil de limitation.

L’exemple suivant montre ce que les clients verront en ce qui concerne les durées de blocage à l’aide de l’applet Get-MoveRequestStatistics - <> -IncludeReport de commande :

$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

Solution et pratique :

Si vous rencontrez une situation comparable, attendez que les ressources Microsoft 365 ou Office 365 soient disponibles.

Facteurs de performances et meilleures pratiques pour les migrations de déploiement non hybrides

Cette section décrit les facteurs qui affectent les migrations à l'aide des méthodes de migration IMAP, à basculement ou intermédiaire. Elle identifie également les meilleures pratiques permettant d'améliorer les performances de la migration.

Facteur 1 : source de données pour les migrations de déploiement non hybride

Le tableau suivant décrit l’impact des serveurs sources dans votre organisation de messagerie actuelle sur la migration et les meilleures pratiques pour atténuer cet impact.

Liste de vérification Description Meilleures pratiques
Performances du système L'extraction des données est une tâche intensive. Le système source doit disposer de ressources suffisantes, tels que le temps processeur et la mémoire, pour fournir des performances de migration optimales. Pendant la migration, le système source est souvent proche de sa capacité maximale en ce qui concerne la charge de travail normale des utilisateurs finaux. Si les ressources système sont insuffisantes, la charge de travail supplémentaire résultant de la migration peut affecter les utilisateurs finaux. Surveillez les performances système lors du test de migration pilote. Si le système est occupé, nous vous recommandons d'éviter une planification de migration restrictive pour le système spécifique en raison de la lenteur potentielle de la migration et des problèmes de disponibilité de service. Si possible, améliorez les performances du système source en ajoutant des ressources matérielles, et réduisez la charge sur le système en déplaçant les tâches et les utilisateurs vers d'autres serveurs qui ne sont pas impliqués dans la migration.

Pour plus d’informations, consultez : Intégrité et performances du serveur d’Exchange Server (2007, 2010, 2013, 2016, 2019)

Remarque : Les serveurs Exchange Server 2007 et 2010 ne sont plus activement pris en charge. La fin du support d’Exchange 2013 Server est prévue pour avril 2023. Exchange Server 2016 et 2019 sont en support étendu jusqu’en octobre 2025. Pour plus d’informations, consultez la matrice de prise en charge d’Exchange Server .

Lors de la migration à partir d'une organisation Exchange locale lorsqu'il y a plusieurs serveurs de boîte aux lettres, nous vous recommandons de créer une liste des utilisateurs de la migration qui soit répartie de façon uniforme entre plusieurs serveurs de boîte aux lettres. En fonction des performances de chaque serveur, cette liste peut être affinée en vue d'optimiser le débit.

Par exemple, si le serveur A présente une disponibilité des ressources supérieure de 50 pour cent à celle du serveur B, il est raisonnable de compter 50 pour cent d'utilisateurs du serveur A en plus dans le même lot de migration. Des pratiques similaires peuvent être appliquées à d'autres systèmes sources. Effectuez les migrations lorsque les serveurs disposent d'une disponibilité maximale des ressources comme après les heures de travail ou pendant les week-ends et les jours fériés.
Tâches principales D'autres tâches principales s'exécutent au moment de la migration. Étant donné qu’il est recommandé d’effectuer une migration après les heures de bureau, il est courant que les migrations entrent en conflit avec les tâches de maintenance (telles que la sauvegarde des données) exécutées sur vos serveurs locaux. Examinez les autres tâches système susceptibles de s'exécuter durant la migration. Nous vous recommandons d'effectuer la migration des données lorsqu'aucune autre tâche nécessitant de nombreuses ressources ne s'exécute.
Remarque : Pour les clients qui utilisent Exchange local, les tâches principales courantes sont les solutions de sauvegarde et la maintenance du magasin Exchange (2013, 2016, 2019).
Stratégie de limitation Il est courant de protéger les systèmes de messagerie avec une stratégie de limitation qui définit une limite spécifique sur la vitesse et la quantité de données pouvant être extraites du système pendant un certain laps de temps. Vérifiez la stratégie de limitation déployée pour votre système de messagerie. Par exemple, Google Mail limite la quantité de données pouvant être extraites au cours d’une certaine période. Selon la version, Exchange dispose de stratégies qui limitent l'accès de IMAP au serveur de courrier local (utilisé par les migrations IMAP) et au protocole RPC sur HTTP (utilisé par les migrations Exchange à basculement et les migrations Exchange intermédiaires).

Pour vérifier les paramètres de limitation, exécutez l’applet de commande Get-ThrottlingPolicy . Pour plus d’informations sur la limitation, consultez : (2007, 2010, 2013, 2016, 2019).

Pour plus d’informations sur la limitation IMAP, voir Migrer vos boîtes aux lettres IMAP vers Microsoft 365 ou Office 365.

Facteur 2 : Serveur de migration pour les migrations de déploiement non hybride

Les migrations IMAP, à basculement et intermédiaires sont des méthodes de migration à extraction des données initiées par le cloud, il n'est donc pas nécessaire d'avoir un serveur de migration dédié. Toutefois, les hôtes de protocole accessibles sur Internet (IMAP ou RPC sur le protocole HTTP) fonctionnent en tant que serveur de migration pour la migration des boîtes aux lettres et des données de boîte aux lettres vers Microsoft 365 ou Office 365. Par conséquent, les facteurs de performances de migration et les meilleures pratiques, décrits dans la section précédente sur le serveur source de données pour votre organisation de messagerie actuelle, s’appliquent également aux serveurs De périphérie Internet. Pour les organisations Exchange 2007, Exchange 2010 et Exchange 2013, le serveur d'accès client fonctionne en tant que serveur de migration.

Pour plus d’informations, reportez-vous aux rubriques suivantes :

Facteur 3 : Moteur de migration pour les migrations de déploiement non hybride

Les migrations IMAP, à basculement et à étapes intermédiaires d’Exchange sont effectuées à l’aide du tableau de bord Migration dans le Centre d’administration Exchange. Cela est soumis à la limitation du service de migration Microsoft 365 ou Office 365.

Solution et pratique :

Les clients peuvent désormais indiquer les accès concurrentiels de migration (par exemple, le nombre de boîtes aux lettres devant être déplacées simultanément) à l'aide de Windows PowerShell. La valeur par défaut est de 20 boîtes aux lettres. Après avoir créé un lot de migration, vous pouvez utiliser l'applet de commande Windows PowerShell suivante pour arriver au maximum de 100.

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

Pour plus d’informations, voir Gérer les lots de migration dans Microsoft 365 ou Office 365.

Remarque

Si votre source de données ne dispose pas de ressources suffisantes pour gérer toutes les connexions, nous vous recommandons d’éviter une concurrence élevée. Commencez par une petite valeur d'accès concurrentiels, par exemple, 10. Augmentez ce nombre tout en analysant les performances des source de données afin d'éviter les problèmes d'accès des utilisateurs finaux.

Facteur 4 : Réseau pour les migrations de déploiement non hybride

Tests de vérification :

Selon la méthode de migration, vous pouvez essayer les tests de vérification suivants :

  • Migrations IMAP : préremplir une boîte aux lettres source avec des exemples de données. Ensuite, à partir d’Internet (en dehors de votre réseau local), connectez-vous à la boîte aux lettres source à l’aide d’un client de messagerie IMAP standard tel que Microsoft Outlook, puis mesurez les performances du réseau en déterminant le temps nécessaire pour télécharger toutes les données à partir de la boîte aux lettres source. Le débit doit être similaire à ce que les clients peuvent obtenir à l’aide de l’outil de migration IMAP dans Microsoft 365 ou Office 365, étant donné qu’il n’y a pas d’autres contraintes.

  • Migrations Exchange intermédiaires et à basculement : préremplir une boîte aux lettres source avec des exemples de données. Ensuite, à partir d’Internet (en dehors de votre réseau local), connectez-vous à la boîte aux lettres source avec Outlook à l’aide du protocole RPC sur HTTP. Vérifiez que vous vous connectez à l’aide du mode mis en cache. Mesurez les performances réseau en vérifiant le temps nécessaire pour synchroniser toutes les données de la boîte aux lettres source. Le débit doit être similaire à ce que les clients peuvent obtenir en utilisant les outils de migration Exchange simples dans Microsoft 365 ou Office 365, étant donné qu’il n’y a pas d’autres contraintes.

Il y a une surcharge pendant une migration IMAP réelle, à basculement ou intermédiaire d'Exchange. Le débit réel, toutefois, doit être similaire aux résultats de ces tests de vérification.

Facteur 5 : Service Microsoft 365 et Office 365 pour les migrations de déploiement non hybride

La limitation basée sur l’intégrité des ressources Microsoft 365 ou Office 365 affecte les migrations à l’aide des outils de migration simples Microsoft 365 ou Office 365 natifs. Consultez la section Limitation basée sur l’intégrité des ressources Microsoft 365 ou Office 365 .

Déplacer des demandes dans Microsoft 365 ou Office 365

Pour obtenir des informations générales sur l’obtention d’informations d’état pour les demandes de déplacement, consultez Afficher les propriétés de la demande de déplacement :

Dans le service Microsoft 365 ou Office 365, la file d’attente de migration et les ressources de service allouées pour les migrations sont partagées entre les locataires et affectent la façon dont les demandes de déplacement sont gérées à chaque étape du processus de déplacement.

Il existe deux types de demandes de déplacement dans Microsoft 365 et Office 365 :

  • Intégration des demandes de « déplacement » : les nouvelles migrations de clients sont considérées comme des demandes de déplacement d’intégration. Ces demandes ont une priorité normale.

  • Demandes de « déplacement » internes du centre de données : il s’agit de demandes de déplacement de boîte aux lettres lancées par les équipes d’exploitation du centre de données. Ces demandes ont une priorité inférieure car l'expérience utilisateur final n'est pas affectée si la demande de déplacement est retardée.

Impact et retards potentiels dans les demandes de déplacement présentant l’état « Mis en file d’attente » et « En cours ».

  • Demandes de déplacement en file d’attente : cet état spécifie que le déplacement a été mis en file d’attente et qu’il attend que le service de réplication de boîtes aux lettres Exchange le récupère. Pour les demandes de déplacement Exchange 2003, les utilisateurs peuvent toujours accéder à leur boîte aux lettres à ce stade.

    Deux facteurs influencent la demande qui sera choisie par le Service de réplication de boîte aux lettres :

    • Priorité : les demandes de déplacement en file d’attente avec une priorité plus élevée sont récupérées avant les demandes de déplacement de priorité inférieure. Cela permet de s'assurer que les demandes de déplacement de migrations clientes soient toujours traitées avant les demandes de déplacement internes du centre de données.

    • Position dans la file d’attente : si les demandes de déplacement ont la même priorité, plus la demande arrive tôt dans la file d’attente, plus tôt elle est récupérée par le service de réplication de boîtes aux lettres. Dans la mesure où plusieurs clients peuvent exécuter des migrations de boîtes aux lettres en même temps, il est normal que les nouvelles demandes de déplacement soient conservés dans la file d'attente avant d'être traitées.

Souvent, la durée pendant laquelle les demandes restent dans la file d'attente avant d'être traitées n'est pas prise en compte lors de la planification de la migration. Il en résulte que les clients ne se voient pas attribuer suffisamment de temps pour effectuer toutes les migrations planifiées.

  • Demandes de déplacement en cours : cet état spécifie que le déplacement est toujours en cours. S'il s'agit d'un déplacement de boîtes aux lettres en ligne, l'utilisateur pourra toujours accéder à sa boîte aux lettres.

Une fois que la demande de déplacement de boîtes aux lettres a le statut « En cours », la priorité n'a plus d'importance et aucune nouvelle demande de déplacement ne sera traitée jusqu'à ce qu'une demande de déplacement « en cours » existante soit effectuée, même si la nouvelle demande de déplacement a une priorité plus élevée.

Meilleures pratiques

Planification : Comme mentionné précédemment, étant donné que les utilisateurs d’Exchange 2003 perdent l’accès pendant une migration hybride, les clients Exchange 2003 sont généralement plus préoccupés par le moment où planifier les migrations et le temps nécessaire.

Lors de la planification du nombre de boîtes aux lettres à migrer pendant une période donnée, envisagez ce qui suit :

  • Incluez la durée pendant laquelle la demande de déplacement attend dans la file d'attente. Pour calculer ce nombre, tapez ceci :

    (nombre total de boîtes aux lettres à migrer) = ((durée totale) - (temps de file d’attente moyen)) * (débit de migration)

    où le débit de migration est égal au nombre total de boîtes aux lettres qui peuvent être migrées par heure.

Par exemple, supposons que vous disposiez d'une fenêtre de six heures pour migrer des boîtes aux lettres. Si le temps de file d’attente moyen est d’une heure et que vous avez un débit de migration de 100 boîtes aux lettres par heure, vous pouvez migrer 500 boîtes aux lettres dans la période de six heures : 500 = (6 - 1) * 100.

  • Commencez la migration plus vite que prévu initialement pour réduire le temps dans la file d'attente. Lorsque les boîtes aux lettres sont en file attente, les utilisateurs Exchange 2003 peuvent continuer d'accéder à leur boîte aux lettres.

Déterminer la durée de la file d’attente : la durée de la file d’attente change toujours, car Microsoft ne gère pas les planifications de migration des clients.

Pour déterminer le temps d'attente potentiel, un client peut tenter de planifier un déplacement test plusieurs heures avant le début effectif de la migration. Ensuite, en fonction de la durée observée pendant laquelle la demande est dans la file d'attente, le client peut mieux estimer le moment où commencer la migration et le nombre de boîtes aux lettres qui peuvent être déplacées dans un laps de temps spécifique.

Par exemple, si une migration test a été achevée quatre heures avant le début d'une migration planifiée. Le client détermine que le temps d'attente pour la migration test a été environ d'une heure. Ensuite, le client doit envisager de commencer la migration une heure avant le moment prévu initialement afin qu'il y ait suffisamment de temps pour effectuer toutes les migrations.

Outils tiers pour les migrations Microsoft 365 ou Office 365

Les outils tiers sont principalement utilisés dans les scénarios de migration qui n’impliquent pas Exchange, tels que ceux de Gmail/G Suite/GWS (Google Workspace), IBM Lotus, Domino et Novell GroupWise. Cette section se concentre sur les protocoles de migration utilisés par des outils de migration tiers, plutôt que sur les produits et les outils de migration réels. Le tableau suivant fournit une liste de facteurs qui s’appliquent aux outils tiers pour les scénarios de migration Microsoft 365 ou Office 365.

Importante

Pour des problèmes de cohérence ou d’intégrité des données après avoir effectué une migration à l’aide d’outils tiers, contactez le fournisseur qui a fourni l’outil pour obtenir du support.

Facteur 1 : source de données pour les migrations d’outils tiers

Liste de vérification Description Meilleures pratiques
Performances du système L'extraction des données est une tâche intensive. Le système source doit disposer de ressources suffisantes, tels que le temps processeur et la mémoire, pour fournir des performances de migration optimales. Pendant la migration, le système source est souvent proche de sa capacité maximale en ce qui concerne la charge de travail normale des utilisateurs finaux. Si les ressources système sont insuffisantes, la charge de travail supplémentaire résultant de la migration peut affecter les utilisateurs finaux. Surveillez les performances système lors du test de migration pilote. Si le système est occupé, nous vous recommandons d'éviter une planification de migration restrictive pour le système spécifique en raison de la lenteur potentielle de la migration et des problèmes de disponibilité de service. Si possible, améliorez les performances du système source en ajoutant des ressources matérielles, et réduisez la charge sur le système en déplaçant les tâches et les utilisateurs vers d'autres serveurs qui ne sont pas impliqués dans la migration.

Pour plus d’informations, consultez : Intégrité et performances du serveur d’Exchange Server (2007, 2010, 2013, 2016, 2019).

Remarque : Les serveurs Exchange Server 2007 et 2010 ne sont plus activement pris en charge. La fin du support d’Exchange 2013 Server est prévue pour avril 2023. Exchange Server 2016 et 2019 sont en support étendu jusqu’en octobre 2025. Pour plus d’informations, consultez la matrice de prise en charge d’Exchange Server .

Lors de la migration à partir d'une organisation Exchange locale lorsqu'il y a plusieurs serveurs de boîte aux lettres, nous vous recommandons de créer une liste des utilisateurs de la migration qui soit répartie de façon uniforme entre plusieurs serveurs de boîte aux lettres. En fonction des performances de chaque serveur, cette liste peut être affinée en vue d'optimiser le débit.

Par exemple, si un serveur A présente une disponibilité des ressources supérieure de 50 % par rapport au serveur B, il est judicieux d'avoir plus 50 % d'utilisateurs en plus provenant du serveur A dans le même lot de migration. Une pratique similaire peut être appliquée à d'autres systèmes sources.

Effectuez les migrations lorsque les serveurs disposent d'une disponibilité maximale des ressources comme après les heures de travail ou pendant les week-ends et les jours fériés.
Tâches principales Autres tâches principales généralement exécutées au moment de la migration. Étant donné qu'il est préférable d'effectuer la migration en dehors des heures de travail, les migrations peuvent entrer en conflit avec d'autres tâches de maintenance exécutées sur vos serveurs locaux, telles que les sauvegardes de données. Examinez les autres tâches système susceptibles de s'exécuter durant la migration. Nous vous recommandons d'effectuer la migration des données lorsqu'aucune autre tâche nécessitant de nombreuses ressources ne s'exécute.

Remarque : Pour les clients qui utilisent Exchange local, les tâches principales courantes sont les solutions de sauvegarde et la maintenance du magasin Exchange (2013, 2016, 2019).
Stratégie de limitation Il est fréquent de protéger les systèmes de courrier avec une stratégie de limitation qui définit une limite spécifique sur la vitesse et la quantité de données pouvant être extraites du système dans un laps de temps spécifique et au moyen d'une méthode de migration spécifique. Vérifiez la stratégie de limitation déployée pour votre système de messagerie. Par exemple, Google Mail limite la quantité de données pouvant être extraites au cours d’une certaine période. Selon la version, Exchange dispose de stratégies qui limitent l'accès de IMAP au serveur de courrier local (utilisé par les migrations IMAP) et au protocole RPC sur HTTP (utilisé par les migrations Exchange à basculement et les migrations Exchange intermédiaires).

Pour vérifier les paramètres de limitation, exécutez l’applet de commande Get-ThrottlingPolicy . Pour plus d’informations sur la limitation, consultez : (2007, 2010, 2013, 2016, 2019).

Pour plus d’informations sur la limitation IMAP, voir Migrer vos boîtes aux lettres IMAP vers Microsoft 365 ou Office 365.

Facteur 2 : Serveur de migration pour les migrations d’outils tiers

La plupart des outils tiers pour les migrations Microsoft 365 ou Office 365 sont initiés par le client et poussent des données vers Microsoft 365 ou Office 365. Ces outils nécessitent généralement un serveur de migration. Les facteurs tels que les performances du système, les tâches principales et les stratégies de limitation pour les serveurs sources s'appliquent à ces serveurs de migration.

Remarque

Certaines solutions de migration tierces sont hébergées sur Internet en tant que services cloud et ne nécessitent pas de serveur de migration local.

Solution et pratique :

Pour améliorer les performances de migration lors de l’utilisation d’un serveur de migration, appliquez les mêmes bonnes pratiques que celles décrites dans la section Facteur 1 : Source de données pour les migrations d’outils tiers .

Facteur 3 : Moteur de migration pour les migrations d’outils tiers

Pour les outils de migration tiers, les protocoles les plus fréquemment utilisés sont les services Web Exchange et le protocole RPC sur HTTP.

Services web Exchange :

Les services web Exchange sont le protocole recommandé pour la migration vers Microsoft 365 ou Office 365, car ils prennent en charge les lots de données volumineux et disposent d’une meilleure limitation orientée service. Dans Microsoft 365 ou Office 365, lorsqu’elles sont utilisées en mode emprunt d’identité, les migrations à l’aide des services web Exchange ne consomment pas la quantité budgétée des ressources des services web Microsoft 365 ou Office 365 Exchange, consommant à la place une copie des ressources budgétées :

  • Tous les appels d'emprunt d'identité des Services Web Exchange effectués par le même compte d'administrateur sont calculés séparément du budget appliqué à ce compte d'administrateur.

  • Pour chaque session d'emprunt d'identité, un cliché instantané du budget de l'utilisateur réel est créé. Toutes les migrations pour cette session particulière utiliseront ce cliché instantané

  • La limitation sous l'emprunt d'identité est isolée pour chaque session de migration d'utilisateur.

  • La stratégie de limitation des services Web Exchange peut être modifiée temporairement dans le locataire (pour une durée de 30, 60 ou 90 jours) pour permettre la fin de la migration. Cela peut être demandé à partir de la section Aide du Centre d’administration Microsoft 365.

Bonnes pratiques :

  • Les performances de migration pour les clients utilisant des outils de migration tiers faisant appel à l'emprunt d'identité EWA entrent en concurrence avec les migrations basée sur les Services Web Exchange et l'utilisation des ressources de service par les autres clients. Par conséquent, les performances de migration peuvent varier.

  • Dès que possible, les clients doivent utiliser des outils de migration tiers qui utilisent l'emprunt d'identité des Services Web Exchange, car c'est généralement plus rapide et plus efficace que d'utiliser des protocoles client tels que le protocole RPC sur HTTP.

Protocole RPC sur HTTP :

Les solutions de migration traditionnelles utilisent le protocole RPC sur HTTP. Cette méthode est entièrement basée sur un modèle d’accès client tel que celui d’Outlook, et la scalabilité et les performances sont limitées, car le service Microsoft 365 ou Office 365 limite l’accès en supposant que l’utilisation est effectuée par un utilisateur plutôt que par une application.

Bonnes pratiques :

  • Pour les outils de migration qui utilisent RPC sur le protocole HTTP, il est courant d’augmenter le débit de migration en ajoutant d’autres serveurs de migration et en utilisant plusieurs comptes d’utilisateur d’administration Microsoft 365 ou Office 365. Cette pratique peut obtenir un parallélisme d’injection de données et obtenir un débit de données plus élevé, car chaque utilisateur administratif est soumis à la limitation des utilisateurs Microsoft 365 et Office 365. Nous avons reçu des rapports indiquant que de nombreuses entreprises devaient configurer plus de 40 serveurs de migration pour obtenir un débit de migration de 20 à 30 Go/heure.

  • Lors d'une phase de développement d'outils de migration, il est essentiel de prendre en compte le nombre d'opérations RPC requises pour migrer un message. Pour illustrer cela, nous avons collecté les journaux capturés par les services Microsoft 365 ou Office 365 pour deux solutions de migration tierces (développées par des sociétés tierces) utilisées par les clients pour migrer des boîtes aux lettres vers Microsoft 365 ou Office 365. Nous avons comparé deux solutions de migration développées par des sociétés tierces. Nous avons comparé la migration de deux boîtes aux lettres pour chaque solution de migration, et nous les avons également comparées au téléchargement d'un fichier .pst dans Outlook. Voici les résultats.

Méthode Taille de boîte aux lettres nombre d'éléments Durée de migration Nombre total de transactions RPC Latence de client moyenne (ms) AvgCasRPCProcessingTime (ms)
Solution A (boîte aux lettres 1) 376,9 Mo 4 115 4:24:33 132 040 48.4395 18.0807
Solution A (boîte aux lettres 2) 249,3 Mo 12 779 10:50:50 423 188 44.1678 4.8444
Solution B (boîte aux lettres 1) 618,1 Mo 4 322 1:54:58 12 196 37.2931 8.3441
Solution B (boîte aux lettres 2) 56,7 Mo 2 748 0:47:08 5 806 42.1930 7.4439
Outlook 201,9 Mo 3 297 0:29:47 15 775 36.9987 5.6447

Remarque

Les temps de traitement du client et du service sont similaires, mais la solution A nécessite beaucoup plus d’opérations RPC pour migrer les données. Étant donné que chaque opération consomme le temps de latence du client et le temps de traitement du serveur, la solution A est beaucoup plus lente à migrer la même quantité de données que la solution B et vers Outlook.

Facteur 4 : Réseau pour les migrations d’outils tiers

Bonne pratique :

Pour les solutions de migration tierces qui utilisent le protocole RPC sur HTTP, voici un bon moyen de mesurer les performances de migration potentielles :

  1. À partir du serveur de migration, connectez-vous à la boîte aux lettres Microsoft 365 ou Office 365 avec Outlook à l’aide du protocole RPC sur HTTP. Assurez-vous que vous ne vous connectez pas à l’aide du mode mis en cache.

  2. Importez un fichier .pst volumineux avec des exemples de données dans la boîte aux lettres Microsoft 365 ou Office 365.

  3. Mesurez les performances de migration en déterminant le temps nécessaire pour télécharger le fichier .pst. Le débit de migration doit être similaire à ce que les clients peuvent obtenir d'un outil de migration tiers qui utilise le protocole RPC sur HTTP, en l'absence d'autres contraintes. Étant donné qu'une surcharge se produit lors d'une migration réelle, le débit peut être légèrement différent.

Facteur 5 : Service Microsoft 365 et Office 365

La limitation basée sur l’intégrité des ressources Microsoft 365 et Office 365 affecte les migrations à l’aide d’outils de migration tiers. Pour plus d’informations, voir Limitation basée sur l’intégrité des ressources Microsoft 365 et Office 365 .