Microsoft 365 et Office 365 de migration de messagerie électronique et les meilleures pratiques

Il existe de nombreux chemins pour migrer des données d’une organisation de messagerie sur site vers Microsoft 365 ou Office 365. Lors de la planification d’une migration vers Microsoft 365 ou Office 365, une question fréquente est de savoir comment améliorer les performances de la migration des données et optimiser la vitesse de migration.

Notes

Les informations de performances répertoriées dans cette rubrique ne s’appliquent pas Microsoft 365 service Office 365 service pour les plans d’abonnement dédiés. Pour plus d’informations sur les plans dédiés, voir Microsoft 365 et Office 365 descriptions du service plans dédiés.

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

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

Pour plus d’informations sur Microsoft 365 réseau Office 365 réseau et les performances, voir Planification réseau et optimisation 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 de messagerie. 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. Migrer vos boîtes aux lettres IMAP vers Microsoft 365 ou Office 365
Migration à basculement À l’aide d’une migration à cutover, vous migrez toutes les boîtes aux lettres sur site vers Microsoft 365 ou Office 365 sur quelques jours. Utilisez la migration à cutover si vous prévoyez de déplacer l’ensemble de votre organisation de messagerie vers Microsoft 365 ou Office 365 et de gérer les comptes d’utilisateurs dans Microsoft 365 ou Office 365. Vous pouvez migrer un maximum de 2 000 boîtes aux lettres de votre organisation Exchange sur site vers Microsoft 365 ou Office 365 à l’aide d’une migration à Office 365. Toutefois, le nombre recommandé de boîtes aux lettres est de 150. Une baisse des performances est observée avec un nombre supérieur à celui-ci. Les contacts de courrier et les groupes de distribution dans votre organisation Exchange locale sont également migrés. Migration à cutover vers Microsoft 365 ou Office 365
Migration intermédiaire Vous utilisez une migration par étapes si vous envisagez de migrer toutes les boîtes aux lettres de votre organisation vers Microsoft 365 ou Office 365. À l’aide d’une migration par étapes, vous migrez des lots de boîtes aux lettres sur site vers Microsoft 365 ou Office 365 sur une série de semaines ou de mois. Ce que vous devez savoir sur une migration de messagerie électronique Microsoft 365 ou Office 365
Déploiement hybride Un déploiement hybride permet aux organisations d'étendre l'expérience riche en fonctionnalités et le contrôle administratif dont ils disposent avec leur organisation Exchange locale existante dans le cloud. Un déploiement hybride offre l’apparence transparente d’une organisation Exchange unique entre une organisation Exchange sur site et des 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 Microsoft 365 ou Office 365 organisation. Conseiller de migration de messagerie

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

Exchange Server 2013 hybrides

Configuration hybride minimale
Migration tierce De nombreux outils sont proposés par des tiers. Ils utilisent des protocoles et des approches identifiables pour effectuer les migrations de courrier à partir de plateformes de courrier telles qu'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 :

Binary Tree: fournisseur de logiciels de coexistence et de migration de messagerie sur plusieurs plateformes, avec des produits qui fournissent l’analyse et la coexistence et la migration entre les environnements de collaboration et de messagerie d’entreprise locaux et en ligne basés sur IBM Lotus Notes et Domino et Exchange et SharePoint.

BitTitan :fournisseur de solutions de migration vers Microsoft 365 ou Office 365.

CodeTwo :fournisseur de solutions Microsoft 365 et Office 365 migration. Migrez des boîtes aux lettres et des dossiers publics à partir de n’importe quel Exchange local et courrier électronique depuis IMAP (Gmail, IBM Notes, etc.) vers le cloud ou effectuez des migrations client/client. Transférer toutes les données en une seule fois ou par lots et automatiser l’intégralité du processus de migration, sans temps mort.

Quadrotech: fournisseur de solutions de migration vers Microsoft 365 ou Office 365.

Provider: Fournisseur de solutions de migration de Exchange, Microsoft 365, Office 365, Gmail, GroupWise, Notes, POP/IMAP, Zimbra, Sun ONE/iMap, PSTs et archives de messagerie vers Microsoft 365 ou Office 365 et Exchange. Les solutions De recherche 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.

Transvault : fournisseurde solutions de migration Office cloud vers Microsoft 365 à partir Exchange notes. Transvault prend en charge 23 sources différentes pour la migration et offre des produits qui offrent n’importe quelle taille de projet, migrations d’archives de messagerie complexes et 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és à la fois en local et dans le Cloud.

SkyKick: fournisseur de solutions de migration automatisées pour déplacer des Exchange, Gmail, POP3, IMAP, Lotus Notes vers 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.

Société de collaboration BCC: aide les entreprises en appuyant leur stratégie de migration de collaboration. Meilleur fournisseur de classe pour les 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îtes aux lettres et les résultats observés en matière de performances pour les différentes méthodes de migration de boîtes aux lettres et de données de boîtes aux lettres vers Microsoft 365 ou Office 365. Ces résultats sont basés sur des tests internes et des migrations de clients réelles vers Microsoft 365 ou Office 365.

Important

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

Charges de travail de migration des clients

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 Notes
Intégration (migration vers Microsoft 365 ou Office 365) Microsoft offre aux clients des outils et des fonctionnalités de migration de données à utiliser pour migrer leurs données de Exchange Server local vers Exchange Online dans Microsoft 365 ou Office 365. Il existe plusieurs méthodes de migration des boîtes aux lettres et des données de boîtes aux lettres, en commençant par les migrations à cutover et les migrations par étapes, qui sont basées sur les déplacements de fusion et de synchronisation, et qui sont décrites plus haut dans cet article. L’autre méthode de migration principale implique des déplacements hybrides, qui est actuellement la méthode la plus courante. Vous pouvez décider exactement quand vous souhaitez migrer vers Microsoft 365, en fonction des besoins de votre entreprise.
Multi-Géo Les entreprises multinationales ayant des bureaux dans le monde entier ont souvent besoin de stocker les données de leurs employés au repos dans des régions spécifiques, afin de répondre aux exigences de résidence des données. Multi-Géo permet à une seule organisation Microsoft 365 ou Office 365 de s’étendre sur plusieurs zones géographiques de centre de données Microsoft 365 ou Office 365 (zones géographiques), ce qui vous permet de stocker des données Exchange au repos, par utilisateur, dans les zones géographiques que vous avez choisies. Pour plus d’informations, voir Obtenir des contrôles d’emplacement de données globaux de niveau entreprise avec Multi-Géo.
Chiffrement Le chiffrement de service avec clé client est une fonctionnalité qui permet à un client de mettre en service et de gérer les clés racines utilisées pour chiffrer les données au repos au niveau de la couche d’application dans Microsoft 365 ou Office 365. Pour qu’une boîte aux lettres soit chiffrée pour la première fois, un déplacement de boîte aux lettres est requis. Pour plus d’informations, voir Chiffrement de service avec clé client.
GoLocal Microsoft continue d’ouvrir de nouveaux centres de données dans de nouvelles régions ou régions géographiques. Les clients existants, lorsqu’ils sont éligibles, peuvent demander à déplacer leurs données client à partir de leur centre de données d’origine vers une nouvelle géo. 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 sur 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 région est lancé (à ce stade, vous avez environ trois à six mois pour demander un déplacement). Pour plus d’informations, voir Moving core data to new Microsoft 365 datacenter geos.

Lorsque des boîtes aux lettres sont migrées dans Microsoft 365 centres de données, chaque déplacement de boîte aux lettres ou déplacement en bloc de boîtes aux lettres nécessite du temps pour terminer l’opération. Il existe un certain nombre de facteurs, tels que Microsoft 365 l’activité du service, qui peuvent affecter exactement le temps. 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 s’assurer 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îtes aux lettres soient traitées en fonction de la disponibilité discrétionnaire des ressources du service. Vous pouvez trouver plus d’informations sur la limitation des ressources dans ce billet de blog.

Temps de migration estimés

Pour vous aider à planifier votre migration, les tableaux suivants présentent des instructions sur le moment où les migrations de boîtes aux lettres en bloc ou les migrations individuelles sont à effectuer. 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 des boîtes aux lettres en fonction des profils de taille de boîte aux lettres :

  1. Intégration / PSTImport

Taille de la boîte aux lettres (Go) 50e centile de durée (jours) 90e centile de durée (jours)
< 1 1 7
1 - 10 1 7
10 - 50 3 14
50 - 100 3 30
100 - 200 8 45
> 200 Non pris en charge Non pris en charge
  1. Multi-Géo / GoLocal / Chiffrement

Taille de la boîte aux lettres (Go) 50e centile de durée (jours) 90e centile de durée (jours)
< 1 1 7
1 - 10 1 10
10 - 50 3 30
50 - 100 15 45
100 - 200 30 60
> 200 Non pris en charge Non pris en charge

Durée de migration pour effectuer 90 % des déplacements de boîtes aux lettres en fonction des profils de taille de client :


Taille du client (nombre de boîtes aux lettres) Durée (jours) Peut prendre jusqu’à autant de jours
< 1,000 5 14
1,000 - 5,000 10 30
5,000 - 10,000 20 45
10,000 - 50,000 30 60
50,000 - 100,000 45 90
> 1000,000 60 180

Notes

Certaines boîtes aux lettres aberrantes prennent plus de temps à se terminer en fonction du profil de boîte aux lettres. En outre, si un client a des boîtes aux lettres plus volumineuses en moyenne, cela peut également contribuer à la durée étendue de la migration.

Facteurs de performances de migration

La migration de messagerie électronique présente plusieurs facteurs communs susceptibles d’avoir une incidence sur 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’tirage des données à partir du serveur source convertit les données, si nécessaire. Le moteur transmet ensuite les données sur le réseau et les injecte dans la boîte aux lettres Microsoft 365 ou Office 365'utilisateur. boîte aux lettres. Le service MRSProxy possède ses propres fonctionnalités et limitations.
Équipements du réseau local Les performances du réseau de bout en bout (de la source de données aux serveurs Exchange Online d’accès au client) affectent les performances de migration. Configuration du pare-feu et caractéristiques de l'organisation locale.
Microsoft 365 service Office 365 service Microsoft 365 et Office 365 offrent une prise en charge et des 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. Les conseils sont d’ordre général car ce sont le matériel tiers et les fournisseurs de services Internet qui ont le plus fort impact sur les performances réseau durant la migration.

Utilisez l 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 Assistant Support et récupération, accédez à Diagnostics avancés > Exchange Online > Vérifier la connectivité réseau Exchange Online > Oui. Lisez la Assistant Support et récupération Microsoft pour en savoir plus sur Assistant Support et récupération.


Facteur Description Meilleures pratiques
Capacité réseau La durée de migration des boîtes aux lettres vers Microsoft 365 ou Office 365 est déterminée 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 des données vers Microsoft 365 ou Office 365 boîtes aux lettres dépend de 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.) Travaillez avec votre fournisseur de services Internet pour résoudre les problèmes liés à Internet.
Ajoutez des adresses IP pour les serveurs de centre de données Microsoft à votre liste d’adresses ip ou ignorez tout le trafic lié à la migration à partir de votre pare-feu réseau. Pour plus d’informations sur Microsoft 365 ou Office 365 plages d’adresses IP, voir Microsoft 365 et Office 365 url et les plages d’adresses IP.

Pour une analyse approfondie des migrations dans votre environnement, consultez notre billet de blog sur le déplacement des analyses. Le billet inclut un script pour vous aider à analyser les demandes de déplacement.

Microsoft 365 et Office 365 limitation

Microsoft 365 et Office 365 différents mécanismes de limitation pour garantir la sécurité et la disponibilité du service. 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

Notes

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

Microsoft 365 et Office 365 limitation des utilisateurs

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 au client, tels que le protocole RPC sur HTTP, pour migrer des données de boîtes aux lettres vers Microsoft 365 ou Office 365 boîtes aux lettres. 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.

Microsoft 365 et Office 365 de service de migration

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

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)

Important

Les méthodes de migration susmentionnées 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 10. Cela signifie qu'au maximum 10 boîtes aux lettres de tous les lots de migration sont migrées à un moment donné. Vous pouvez augmenter le nombre de migrations simultanées pour un lot de migration dans le panneau de configuration 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.

Microsoft 365 ou Office 365 limitation basée sur l’état des ressources

Toutes les méthodes de migration sont soumises à la gouvernance de la limitation de disponibilité. Microsoft 365 ou Office 365 limitation de service, cependant, 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.

Voici des exemples extraits d'un rapport statistique de migration Exchange. Ils affichent des entrées consignées lorsque le seuil de limitation de service est dépassé.

1/25/2018 12:56:01 AM [BL2PRD0410CA012] Copy progress: 723/1456 messages, 225.8 MB (236,732,045 bytes)/416.5 MB (436,712,733 bytes).

1/25/2018 12:57:53 AM [BL2PRD0410CA012] Move for mailbox '/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' is stalled because DataMoveReplicationConstraint is not satisfied for the database 'NAMPRD04DG031-db081' (agent MailboxDatabaseReplication). Failure Reason: Database edbf0766-1f2a-4552-9115-bb3a53a8380b doesn't satisfy constraint SecondDatacenter. There are no available healthy database copies. Will wait until 1/25/2018 1:27:53 AM.

1/25/2018 12:58:24 AM [BL2PRD0410CA012] Request is no longer stalled and will continue.

6/30/2017 00:03:58 [CY4PR19MB0056] Relinquishing job because of large delays due to unfavorable server health or budget limitations with a request throttling state 'StalledDueToTarget_DiskLatency'.

Solution et pratique:

Si vous êtes dans une situation similaire, attendez que les ressources Microsoft 365 ou Office 365 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 : la source de données

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 du système lors d'un 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, voir :
Exchange 2013 Server Health and Performance
Comprendre Exchange performances 2010
Exchange 2007 : Surveillance des serveurs de boîtes aux lettres

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. Sur la base des performances individuelles du serveur, la liste peut être davantage affinée pour 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. 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 préférable d’effectuer une migration après les heures d’ouverture, il est courant que les migrations entrent en conflit avec des 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 des Exchange locaux, les tâches principales courantes sont les solutions de sauvegarde et Exchange maintenance du magasin.
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 pendant un certain temps. Vérifiez quelle stratégie d'accélération est déployée pour votre système de courrier. Par exemple, Google Mail limite la quantité de données pouvant être extraite lors d'une période donnée.

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 dans une organisation Exchange 2013, exécutez l'applet de commande Get-ThrottlingPolicy. Pour plus d'informations, voir Gestion de la charge de travail Exchange.

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

Pour plus d'informations sur la limitation du protocole RPC sur HTTP, voir :
Exchange charges de travail 2013
Exchange 2010 : Understanding Client Throttling Policies
Exchange 2007 : Understanding Client Throttling

Facteur 2 : le serveur de migration

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 protocoles côté Internet (protocole IMAP ou RPC sur HTTP) fonctionnent comme le serveur de migration pour la migration des boîtes aux lettres et des données de boîtes 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 de source de données pour votre organisation de messagerie actuelle, s’appliquent également aux serveurs Edge 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, voir :

Facteur 3 : le moteur de migration

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

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.

Notes

Si votre source de données ne dispose pas des ressources suffisantes pour gérer toutes les connexions, nous vous recommandons d'éviter un taux élevé d'accès concurrentiels. 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

Tests de vérification:

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

  • Migrations IMAP: pré-implémenter 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 réseau en déterminant la durée de téléchargement de 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’existe aucune autre contrainte.

  • Migrations à Exchange et par étapes : prére implémenter 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. Assurez-vous que vous vous connectez en utilisant le 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 à l’aide des outils de migration Exchange simples dans Microsoft 365 ou Office 365, étant donné qu’il n’existe aucune autre contrainte.

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 : Microsoft 365 et Office 365 service

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

Déplacer des demandes dans le service Microsoft 365 ou Office 365 service

Pour des informations générales sur l'obtention d'informations sur l'état des demandes de déplacement, voir Afficher les propriétés des demandes de déplacement.

Dans le service Microsoft 365 ou Office 365, contrairement au service local Exchange 2010, la file d’attente de migration et les ressources de service allouées aux migrations sont partagées entre les clients. Ce partage affecte la façon dont les demandes 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 :

  • Demandes de déplacement d’intégration: 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’agir de demandes de déplacement de boîtes aux lettres initié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 indique que le déplacement a été mis en file d’attente et qu’il attend d’être pris en compte par le service de réplication de boîte aux lettres Exchange de l’utilisateur. 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 reprises 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é, le plus tôt la demande est entrée dans la file d’attente, plus elle est rapidement reprise par le service de réplication de boîte 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 indique 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. Pour les déplacements de boîtes aux lettres en mode hors connexion, la boîte aux lettres de l'utilisateur ne sera pas disponible.

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 de Exchange 2003 perdent l’accès au cours d’une migration hybride, les clients Exchange 2003 se soucient généralement davantage du moment où planifier les migrations et de la durée qu’ils vont prendre.

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 d'attente moyen dans la file)) * (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 d'attente moyen dans la file 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 en 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 le temps de file d’attente : le temps de file d’attente change constamment, 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 migrations

Les outils tiers s'utilisent principalement dans les scénarios de migration qui n'impliquent pas Exchange, tels que ceux de Google Mail, 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 des facteurs qui s’appliquent aux outils tiers pour les scénarios Microsoft 365 ou Office 365 migration.

Important

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 de l’aide.

Facteur 1 : la source de données


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 du système lors d'un 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 en réduisant la charge sur le système. Le chargement du système peut être réduit en déplaçant des tâches et des utilisateurs vers d'autres serveurs qui ne font pas partie de la migration.

Pour plus d'informations, voir :
Exchange 2013 Server Health and Performance
Comprendre Exchange performances 2010
Exchange 2007 : Surveillance des serveurs de boîtes aux lettres

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. Sur la base des performances individuelles du serveur, la liste peut être davantage affinée pour 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 le système offre 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. Car il est recommandé d'effectuer les migrations après les heures de travail, il est fréquent que celles-ci entrent en conflit avec les tâches de maintenance en cours d'exécution sur vos serveurs locaux, telles que la sauvegarde de données. Passez en revue les autres tâches système en cours d'exécution pendant la migration. Nous vous conseillons de créer une fenêtre de temps réservée à la migration des données, dans laquelle il n'y a aucune autre tâche sollicitant les ressources de façon intensive.

Pour les clients locaux Exchange, les tâches courantes sont les solutions de sauvegarde. Pour plus d'informations, voir Maintenance de la banque d'informations Exchange.
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 quelle stratégie d'accélération est déployée pour votre système de courrier. Par exemple, Google Mail limite la quantité de données pouvant être extraite lors d'une période donnée.

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 plus d'informations sur la limitation IMAP, voir Conseils pour l'optimisation de migrations IMAP.

Pour plus d'informations sur la limitation du protocole RPC sur HTTP, voir :
Exchange charges de travail 2013
Exchange 2010 : Understanding Client Throttling Policies
Exchange 2007 : Understanding Client Throttling

Pour plus d'informations sur la configuration de la limitation des services Web Exchange, voir Exchange 2010 : Présentation des stratégies de limitation du client.

Facteur 2 : le serveur de migration

La plupart des outils tiers pour les migrations Microsoft 365 ou Office 365 sont initiés par le client et les données sont 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.

Notes

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 lorsque vous utilisez un serveur de migration, appliquez les mêmes recommandations que celles décrites dans la section Facteur 1 : Source de données.

Facteur 3 : le moteur de migration

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.

Exchange Web Services :

Exchange Les services web sont le protocole recommandé pour la migration vers Microsoft 365 ou Office 365, car il prend en charge les lots de données de grande taille et offre une meilleure limitation orientée service. Dans Microsoft 365 ou Office 365, lorsqu’elles sont utilisées en mode d’emprunt d’identité, les migrations à l’aide des services web Exchange n’utilisent pas la quantité budgétée de ressources des services web Microsoft 365 ou Office 365 Exchange de l’utilisateur, en 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.

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

Meilleures 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:

De nombreuses 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 de Outlook, et l’évolutivité et les performances sont limitées, car le service Microsoft 365 ou Office 365 limite l’accès sur l’hypothèse que l’utilisation est par un utilisateur plutôt que par une application.

Meilleures pratiques:

  • Pour les outils de migration qui utilisent le protocole RPC sur HTTP, il est courant d’augmenter le débit de migration en ajoutant davantage de serveurs de migration et en utilisant plusieurs comptes d’utilisateurs 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 Microsoft 365 et Office 365 limitation des utilisateurs. 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

Notes

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

Facteur 4 : Réseau

Meilleure 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 de grande taille avec des exemples de données dans Microsoft 365 ou Office 365 boîte aux lettres.

  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 : Microsoft 365 et Office 365 service

Microsoft 365 et Office 365 limitation basée sur l’état des ressources affectent les migrations à l’aide d’outils de migration tiers. Pour plus d Microsoft 365, voir Office 365 limitation basée sur l’état des ressources.