Le principe repose sur une approche fractionnée : plutôt que de basculer l’ensemble des boîtes aux lettres en une seule opération, la migration se déroule par vagues successives. Les entreprises exploitant encore Exchange Server 2003 ou Exchange Server 2007 sont les principales concernées par ce scénario, leur infrastructure de messagerie nécessitant une modernisation vers Microsoft 365 et Exchange Online. Cette migration progressive Exchange vers le cloud Microsoft présente un avantage majeur : elle minimise les interruptions de service et facilite l’accompagnement au changement pour les utilisateurs.
Parmi les différentes stratégies disponibles — migration cutover, hybride ou import PST — la staged migration occupe une place spécifique, adaptée aux environnements de taille intermédiaire. Pour choisir la méthode la mieux alignée avec votre contexte, consultez notre guide sur le choix du scénario de migration Exchange Online. Eliadis vous accompagne à chaque étape de ce projet.
À retenir :
- La migration Exchange vers Microsoft 365 par lots permet un transfert progressif des boîtes aux lettres sans interruption de service
- Ce processus est adapté aux entreprises utilisant Exchange Server 2003 ou 2007, optimisant le contrôle de la transition cloud
- La migration se déroule par vagues successives, nécessitant une gestion minutieuse du routage et de la synchronisation
- Des prérequis techniques comme Outlook Anywhere, MRS Proxy et Azure AD Connect doivent être respectés pour une migration réussie
- Un suivi rigoureux des statuts de migration et une communication proactive aux utilisateurs sont essentiels pour minimiser les interruptions
- La validation finale et la mise à jour des DNS marquent l’achèvement de la migration, avec une attention particulière portée à la période de coexistence
Comprendre le scénario de migration Exchange vers Microsoft 365 par lots
La migration par lots (staged migration) consiste à transférer progressivement les boîtes aux lettres Exchange vers Microsoft 365, par vagues successives, sans interruption globale du service de messagerie. Cette approche convient aux organisations souhaitant maîtriser le rythme de leur transition vers Exchange Online.
Le principe de la migration progressive par vagues
Contrairement à une bascule unique, la migration progressive Exchange vers Microsoft 365 découpe le périmètre en lots de boîtes aux lettres traités séquentiellement. Chaque vague suit un cycle : préparation, synchronisation, validation, puis activation. Pendant toute la durée du projet, les utilisateurs non encore migrés continuent de fonctionner sur l’environnement Exchange on-premises, tandis que les utilisateurs déjà migrés exploitent Exchange Online. Cette coexistence temporaire exige une gestion rigoureuse du routage du courrier et une synchronisation d’annuaire maintenue tout au long des phases de migration.
Versions d’Exchange supportées : un périmètre délimité
Selon Microsoft, la staged migration migre les boîtes aux lettres depuis Exchange Server 2003 ou Exchange Server 2007 vers Microsoft 365 de façon échelonnée dans le temps (Source : Microsoft — 2025-05-21). Il s’agit d’une limitation technique importante : Exchange Server 2010 n’est pas pris en charge par ce scénario, ce qui oriente les organisations sous Exchange 2010 vers d’autres approches, notamment la migration hybride.
| Version Exchange source | Staged migration | Cutover migration | Migration hybride |
|---|---|---|---|
| Exchange Server 2003 | ✔ Supporté | ✔ Supporté | ✘ Non applicable |
| Exchange Server 2007 | ✔ Supporté | ✔ Supporté | ✔ Possible |
| Exchange Server 2010 | ✘ Non supporté | ✔ Supporté | ✔ Recommandé |
| Exchange Server 2013/2016/2019 | ✘ Non supporté | ✘ Non applicable | ✔ Recommandé |
Différences majeures avec les autres scénarios de migration
La migration par étapes vers Exchange Online se distingue nettement des autres approches disponibles. La cutover migration migre la totalité des boîtes aux lettres en une seule opération, adaptée aux structures de moins d’une centaine d’utilisateurs. La migration hybride, plus complexe, permet une coexistence longue durée avec une synchronisation riche des fonctionnalités. Enfin, l’import PST constitue une méthode manuelle, non automatisée, limitée au transfert de données sans gestion de la continuité opérationnelle. Pour les environnements Exchange 2003 et 2007 de taille intermédiaire, la staged migration représente l’équilibre le plus pertinent entre contrôle et progressivité. Les équipes IT souhaitant approfondir les arbitrages liés aux scénarios complexes peuvent consulter notre analyse dédiée à la planification d’une migration hybride Exchange vers Exchange Online.
Coexistence temporaire et continuité des opérations
L’un des objectifs centraux du scénario staged migration est de garantir la continuité du service pendant toute la durée du projet. Le routage des messages entre utilisateurs on-premises et utilisateurs déjà sur Exchange Online doit être configuré avec soin, via un connecteur approprié, pour éviter toute interruption. La compatibilité Exchange 2003/2007 avec ce mécanisme de coexistence repose sur des fonctionnalités de base bien documentées, mais elle impose également des contraintes : certaines fonctionnalités collaboratives avancées ne sont disponibles qu’une fois la migration complètement finalisée. La phase suivante détaillera les prérequis techniques et organisationnels à réunir avant de lancer le premier lot.
Préparer son infrastructure Exchange à la migration par lots
Une migration par lots réussie repose sur une préparation rigoureuse de l’infrastructure Exchange on-premises. Avant de déplacer la première boîte aux lettres, plusieurs prérequis techniques doivent être satisfaits sans exception.
Exigences d’infrastructure : Outlook Anywhere et certificats
La préparation au staged migration Microsoft 365 exige en premier lieu que le protocole Outlook Anywhere (RPC over HTTP) soit activé et correctement configuré sur le serveur Exchange source. Ce mécanisme permet à Microsoft 365 de communiquer avec l’environnement on-premises pour extraire les données de messagerie. Il est également indispensable de disposer d’un certificat SSL valide, émis par une autorité de certification reconnue, et associé au nom d’hôte externe utilisé par Outlook Anywhere. Sans cette configuration, le point de terminaison de migration ne pourra pas s’authentifier correctement et l’ensemble du projet sera bloqué dès le départ.
Activation du MRS Proxy et permissions d’administration
Selon Microsoft, l’activation du MRS Proxy sur le serveur Exchange on-premises et la configuration d’un compte d’administration dédié aux migrations sont des étapes obligatoires avant de lancer toute migration par lots. (Source : Microsoft — 2025-05-21). Le Centre d’administration Exchange permet d’activer ce service sur le répertoire virtuel EWS et de déléguer les rôles nécessaires au compte de service. Ces permissions garantissent que Microsoft 365 peut accéder librement aux boîtes aux lettres sources lors de chaque vague de migration.
Synchronisation des identités via Azure AD Connect
La synchronisation des comptes via Azure AD Connect constitue un prérequis fondamental pour la migration par lots Exchange. L’outil synchronise les objets Active Directory on-premises vers Azure Active Directory, créant ainsi les utilisateurs à messagerie activée (mail-enabled users) nécessaires dans Microsoft 365. Sans cette synchronisation, les boîtes aux lettres migrées n’auraient pas de contrepartie dans le tenant cible, rendant la connexion des utilisateurs impossible après la bascule.
Création du fichier CSV et configuration du migration endpoint
La constitution du fichier CSV listant les boîtes aux lettres à migrer est une étape souvent sous-estimée mais stratégique. Ce fichier doit comporter au minimum l’adresse e-mail, le mot de passe du compte Exchange et le nom de domaine. Toute erreur de formatage entraîne le rejet du lot entier par Microsoft 365. En parallèle, la vérification de la connectivité via le migration endpoint — point de terminaison de migration Microsoft 365 — est indispensable : il est configuré directement depuis le Centre d’administration Exchange Online et teste automatiquement la disponibilité d’Outlook Anywhere.
| Prérequis | Outil concerné | Obligatoire |
|---|---|---|
| Outlook Anywhere activé + certificat SSL | Exchange on-premises | Oui |
| MRS Proxy activé sur EWS | Centre d’administration Exchange | Oui |
| Compte d’administration dédié avec permissions | Active Directory / Exchange | Oui |
| Synchronisation des identités | Azure AD Connect | Oui |
| Fichier CSV des boîtes aux lettres | Exchange Admin Center M365 | Oui |
| Migration endpoint validé | Exchange Online | Oui |
Une fois ces prérequis techniques validés et documentés, l’équipe projet peut aborder sereinement la configuration des lots de migration et la planification des vagues de déplacement des boîtes aux lettres.
Exécution et supervision des lots de migration
Exécuter une migration par lots requiert une séquence précise : préparer le fichier CSV, créer le batch, le lancer, puis surveiller son avancement jusqu’à validation complète. Chaque étape conditionne la réussite des suivantes.
Création du fichier CSV et import du lot
La première action consiste à constituer un fichier CSV listant les boîtes aux lettres à migrer dans le lot courant. Chaque ligne contient au minimum l’adresse e-mail de l’utilisateur, son identifiant et son mot de passe source. Ce fichier s’importe ensuite depuis le Centre d’administration Microsoft 365, via la section Destinataires > Migration, ou directement en PowerShell Exchange Online avec la cmdlet New-MigrationBatch. L’approche PowerShell offre davantage de contrôle, notamment pour définir la taille des lots et automatiser l’enchaînement des vagues. La Batch migration Office 365 peut ainsi être entièrement scriptée pour les environnements comprenant plusieurs centaines de boîtes aux lettres.
Connexion via Outlook Anywhere et démarrage du lot
Avant de lancer le batch, le point de terminaison Outlook Anywhere doit être configuré et validé. Il permet à Exchange Online de se connecter au serveur Exchange local pour lire et synchroniser les données. Une fois le point de terminaison testé avec succès, le lot peut être démarré. Selon Microsoft, lorsqu’un lot de migration démarre avec succès, son statut passe à Syncing dans le tableau de bord Exchange Online ; il convient de vérifier ce changement d’état via le tableau de bord et les journaux (Source : Microsoft — 2025-05-21). La progression de la migration par vagues Exchange Online se consulte également via la cmdlet Get-MigrationBatch et Get-MigrationUser.
Suivi des statuts et analyse des journaux
| Statut du batch | Signification | Action recommandée |
|---|---|---|
| Created | Lot créé, non démarré | Vérifier le CSV, démarrer le lot |
| Syncing | Synchronisation en cours | Surveiller les erreurs utilisateur |
| Synced | Synchronisation initiale terminée | Préparer la bascule MX |
| Completed | Migration finalisée | Mettre à jour les profils Outlook |
| Failed | Échec partiel ou total | Analyser les journaux, corriger et relancer |
Le suivi batch migration Exchange implique une lecture régulière des rapports d’erreurs disponibles dans l’interface de supervision migration Exchange Online. Les boîtes partagées et les permissions héritées (délégations, accès complet) nécessitent une attention particulière : elles ne migrent pas automatiquement et doivent être reconfigurées manuellement dans Exchange Online après le passage du lot.
Communication utilisateurs et mise à jour des profils Outlook
Parallèlement à la gestion des profils Outlook post-migration, une communication proactive auprès des utilisateurs concernés limite les interruptions. Dès qu’un lot atteint le statut Synced, il est recommandé d’informer les collaborateurs de la date de bascule et de leur fournir les instructions de reconfiguration de leur client Outlook. L’utilisation d’Exchange Online Archiving doit également être anticipée pour les utilisateurs disposant d’archives locales. La gestion rigoureuse de ces aspects prépare la phase de validation finale et la coupure des flux legacy, étape centrale du chapitre suivant.
Coexistence, validation et bascule finale vers Microsoft 365
La réussite d’une migration progressive Exchange Online repose sur une gestion rigoureuse de la coexistence entre l’infrastructure sur site et le cloud, suivie d’une bascule finale maîtrisée. Chaque étape doit être planifiée pour éviter toute interruption de service.
Gérer la coexistence entre Exchange sur site et cloud
Durant la phase de coexistence Exchange sur site et cloud, les utilisateurs migrés reçoivent leurs messages via Microsoft 365 tandis que les boîtes restantes continuent de fonctionner on-premises. Il est essentiel de maintenir la cohérence des listes d’adresses globales, la disponibilité free/busy pour la planification des réunions et le routage correct des flux hybrides. L’intégration avec Active Directory Federation Services (ADFS) garantit une authentification transparente pour les utilisateurs des deux environnements. Selon Microsoft, la méthode de migration staged copie l’ensemble des données de messagerie, contacts, éléments de calendrier et tâches depuis Exchange on-premises (Source : Microsoft — 2025-03-17), ce qui confirme l’importance d’une synchronisation continue pendant toute la durée de la coexistence.
Tests de validation et groupes pilotes
Avant la bascule finale messagerie Microsoft 365, il est recommandé de constituer un groupe pilote représentatif des différents profils métiers. Ce groupe valide la réception et l’envoi de messages, l’accès aux calendriers partagés, le fonctionnement de Microsoft Defender for Office 365 pour la protection des flux entrants, ainsi que les politiques d’étiquetage définies via Azure Information Protection. Les retours du pilote permettent d’identifier les anomalies avant le déploiement généralisé et d’ajuster les configurations si nécessaire. La procédure détaillée de validation de la staged migration est documentée par Microsoft et peut être consultée pour chaque lot migré.
| Étape de validation | Critère de succès | Responsable |
|---|---|---|
| Réception des e-mails | Zéro message perdu après bascule MX | Équipe IT |
| Accès calendriers | Free/busy visible cross-environnements | Équipe IT |
| Authentification SSO | Connexion transparente via ADFS | Équipe sécurité |
| Protection messagerie | Règles Defender for Office 365 actives | Équipe sécurité |
| Validation utilisateurs pilotes | Taux de satisfaction ≥ 90 % | Chef de projet |
Mise à jour DNS et enregistrements MX
La bascule des enregistrements MX et la mise à jour des entrées DNS (Autodiscover, SPF, DKIM, DMARC) constituent l’acte final de la migration par lots. Cette opération doit être réalisée lot par lot, en dehors des heures de pointe, en abaissant le TTL au préalable pour réduire le délai de propagation. Une procédure de rollback documentée permet de rétablir le routage vers Exchange on-premises en cas d’incident critique.
Communication utilisateurs et plan de rollback
Un plan de communication structuré informe les collaborateurs des dates de bascule, des changements d’URL d’accès et des nouveaux procédés d’authentification. Des sessions d’assistance courtes, organisées en amont de chaque lot, réduisent les tickets de support post-migration. La stratégie de rollback doit préciser les seuils de déclenchement, les délais d’intervention et les responsabilités associées, transformant ainsi la gestion du risque projet en processus contrôlé. Le chapitre suivant détaille les opérations de décommissionnement d’Exchange on-premises une fois la migration totalement finalisée.
Conclusion
La migration par lots vers Microsoft 365 constitue une approche structurée et fiable pour les organisations encore sous Exchange 2003 ou Exchange 2007. Elle repose sur trois piliers essentiels : une planification rigoureuse, une coexistence maîtrisée entre l’infrastructure existante et Exchange Online, et une validation progressive à chaque étape du projet.
Il convient toutefois de rappeler que, selon la Microsoft Tech Community, la staged migration n’est pas supportée pour Exchange 2010, ce qui impose d’envisager des méthodes alternatives dans ce cas précis (Source : Microsoft Tech Community — 2026-02-09). Connaître les limites de chaque méthode est indispensable avant tout engagement.
Pour réussir votre migration Exchange Online et accélérer votre transformation cloud, l’accompagnement d’un partenaire Microsoft expérimenté comme Eliadis fait toute la différence. Fort de plus de vingt ans d’expertise en Digital Workplace, Eliadis pilote vos projets de bout en bout, de l’audit initial jusqu’à l’adoption des utilisateurs. Poursuivez votre réflexion en explorant les solutions hybrides et les approches modernes pour une Digital Workplace pleinement optimisée.
