Une migration de boîte aux lettres vers le cloud peut se terminer avec succès alors que les factures, les alertes et les documents numérisés cessent d'arriver. Ces flux de travail peuvent être envoyés via des appareils, des applications ou des fournisseurs tiers en dehors du locataire de la boîte aux lettres. Créez l'inventaire de migration autour des chemins de messagerie professionnels, et pas seulement de la liste des comptes d'utilisateurs en cours de déplacement.
Cartographier les systèmes manquant à la liste des locataires
Demandez à chaque équipe commerciale et d'infrastructure quels systèmes envoient des messages. Incluez les communications clients, la facturation, les flux de travail d'identité, les alertes d'incident, les imprimantes, les formulaires de sites Web, les rapports planifiés et les campagnes SaaS. Enregistrez l'objectif, le propriétaire, la criticité, la méthode d'envoi, la dépendance au réseau et la preuve du dernier test de bout en bout.
Pour chaque chemin, distinguez visible De, expéditeur d'enveloppe, DKIM domaine de signature, portée de destination et gestion des rebonds. Indiquez si le service communique directement avec un fournisseur externe, un relais sur site ou un point de terminaison locataire. Microsoft documente explicitement plusieurs méthodes de messagerie d'application avec différentes conditions préalables et restrictions. L'envoi direct est limité aux destinataires de l'organisation ; Le relais SMTP et la soumission authentifiée ont des exigences de configuration différentes. Conseils Microsoft. Vérifiez la méthode actuellement prise en charge par le fournisseur actuel plutôt que de copier les paramètres d'une autre plate-forme.
Connecter le transport à l’authentification
La modification de la plate-forme de boîte aux lettres ne met pas automatiquement à jour la configuration de l'expéditeur ou DNS d'une application. Déterminer qui signe chaque flux, quelle identité enveloppe SPF évalue et comment un identifiant aligné se rapporte au domaine visible From. RFC 9989. Inventairez les sélecteurs DKIM et les dépendances tierces avant de supprimer les anciens enregistrements.
Identifiez également les restrictions de relais basées sur IP, les certificats, les règles de pare-feu, les dépendances des connecteurs et les références d'informations d'identification sans exporter les secrets. Enregistrez quelle équipe possède chaque dépendance. Un changement MX modifie principalement le routage entrant ; il ne s'agit pas d'un plan de migration complet pour le courrier d'application sortant.
Faire de la portée du destinataire une porte de migration
Supposons que les reçus des clients utilisent une route de signature SaaS, qu'une imprimante utilise un relais interne et qu'une demande d'incident soit soumise via l'ancienne plate-forme. L'itinéraire de réception peut rester en dehors du basculement de la boîte aux lettres, mais dépend toujours de son DNS et de son compte fournisseur. L'imprimante et l'application d'incident nécessitent leurs propres contrôles de destination, de réseau et de soumission ; la migration des comptes des employés ne résout pas ces dépendances.
Si l'application d'incident doit notifier une adresse de garde externe, Microsoft Direct Send n'est pas un itinéraire approprié pour cette livraison externe requise. Vérifiez plutôt une méthode prise en charge avec les conditions préalables réelles du compte et du réseau. Cette décision de portée hypothétique ne configure pas l’éligibilité d’un locataire ou d’un fournisseur de tests. Conservez une attente jusqu'à ce que l'itinéraire sélectionné ait des preuves autorisées de bout en bout.
Planifier délibérément la coexistence
Pour chaque service, spécifiez l'ancien chemin, le nouveau chemin, le propriétaire du basculement, les scénarios de test, les signaux d'échec et l'action de restauration. Conserver uniquement les autorisations parallèles requises pour la période de coexistence agréée. Les envois en double constituent un risque distinct : la migration d'une tâche d'application et le maintien de son ancien planificateur actif peuvent envoyer la même notification deux fois, même lorsque les deux messages sont authentifiés.
Exercez des destinations internes et externes là où l'entreprise les requiert. Testez le traitement des rebonds, le comportement des nouvelles tentatives et les alertes de surveillance ainsi que la réception d'un message réussi. Conserver les preuves du destinataire pour signature et alignement résultats. Une réponse d'acceptation SMTP à elle seule ne prouve pas que la boîte aux lettres de destination a affiché le message ou que l'application a traité correctement un échec.
Définir une condition de sortie pour l'ancienne plateforme
Ne mettez pas hors service l'ancien relais car toutes les boîtes aux lettres des utilisateurs ont été déplacées. Fermez chaque ligne de dépendance avec un succès observé, une exception approuvée ou une décision de retrait explicite. Incluez les flux planifiés qui ne se sont pas exécutés pendant la fenêtre de basculement. Exportez les preuves nécessaires au dépannage futur avant l’expiration de l’accès à l’ancienne plateforme.
Lorsque vous retirez des autorisations, utilisez les modifications exactes des enregistrements et les modifications de configuration du service sous approbation normale. Supprimez les anciennes informations d’identification et autorisations uniquement après la migration ou le retrait du service correspondant. Indiquez les inconnues restantes dans la décision de migration afin que des preuves incomplètes ne soient pas confondues avec des éléments complets.