Une migration de plateforme de messagerie n'est pas terminée lorsqu'un message test arrive dans la boîte de réception d'un administrateur. L'application doit toujours créer la bonne notification, la soumettre par l'itinéraire prévu, gérer les échecs et atteindre les destinataires requis. Élaborez le plan de transition autour de ces résultats afin que les messages importants ne disparaissent pas entre les équipes d'application et de messagerie.
Inventorier chaque dépendance de notification
Enregistrez le travail d'application, le déclencheur, la planification, l'audience, la criticité, le propriétaire, le point de terminaison, la méthode d'authentification, les identités de l'expéditeur, la file d'attente des nouvelles tentatives et la destination du traitement des rebonds. Incluez l'accès au réseau, les certificats, les références d'informations d'identification et les dépendances DNS sans copier les secrets. Distinguer la génération de courrier du transport de courrier ; un planificateur arrêté ne peut pas être réparé en modifiant SPF.
Les méthodes des fournisseurs diffèrent. Microsoft documente la soumission client authentifiée, le relais SMTP et l'envoi direct comme des choix distincts avec des conditions préalables et une portée de destinataire différentes. Conseils sur la messagerie des applications Microsoft. Sélectionnez un itinéraire actuellement pris en charge pour les capacités réelles de l'application et les exigences de destination. Ne présumez pas qu'une licence de boîte aux lettres ou une mise à jour MX migre sa configuration de soumission.
Concevoir une coexistence sans tâches en double
Pour chaque dépendance, nommez l'ancienne et la nouvelle route, qui peut la changer et comment la restaurer. Décidez quel planificateur fait autorité pendant la coexistence. Conserver l’ancienne route pour la restauration ne signifie pas que les deux planificateurs doivent émettre la même notification. Utilisez un identifiant d'événement au niveau de l'application pour réconcilier les tentatives lorsque l'application le prend en charge, tout en reconnaissant qu'un identifiant seul ne constitue pas une garantie de déduplication SMTP .
Gardez les autorisations parallèles d’une portée étroite et limitées dans le temps. Le nouvel itinéraire nécessite l’identité authentifiée et alignée prévue, et pas simplement la signature d’un fournisseur. RFC 9989. Conserver les clés de signature nécessaires et sélecteur disponibilité des messages encore en transit dans le cadre du plan de retraite.
Enquêter sur les tentatives en double et les traces incomplètes
Supposons qu'un événement de réception ait deux tentatives de soumission pendant la coexistence, alors qu'une notification reçue différente n'a pas d'enregistrement de déclencheur d'application correspondant. Le premier nécessite un planificateur et une nouvelle tentative d'enquête ; deux tentatives ne prouvent pas deux messages délivrés. La seconde nécessite une reconstruction de trace ou un écart de journalisation explicite, et non un événement d'application inventé. Corrélez l’itinéraire, les horodatages et les preuves du destinataire avant de choisir une action corrective.
Il s’agit d’observations hypothétiques, et non d’un grand livre fourni ou d’un chèque exécuté. Conservez l'ancien itinéraire pour une récupération autorisée sans permettre aux deux planificateurs de générer le même événement. Avant de déclarer l'acceptation, collectez la génération de l'application, la soumission prévue, l'observation réelle du récepteur et les tests de gestion des échecs pris en charge comme preuves distinctes. Un formulaire d'apparence complète ne peut pas certifier une candidature non testée.
Testez tout le chemin
Utilisez des destinataires approuvés et des modèles représentatifs. Déclenchez l'application normalement, conservez son ID d'événement et son journal de travail, inspectez la soumission ou le relais des preuves et capturez le message reçu par la destination. Vérifiez le contenu attendu et les résultats d’authentification du destinataire final. Enregistrez l'heure et l'itinéraire du test afin que la coexistence ne masque pas le système qui l'a délivré.
Exercez un échec de soumission transitoire, un comportement de nouvelle tentative et un cas de destinataire non valide autorisé lorsque l'environnement de test le prend en charge. Confirmez qui reçoit et traite les rebonds. Vérifiez les destinations internes et externes séparément. Une transaction SMTP acceptée peut toujours être suivie d'un échec de livraison ; un test de destinataire réussi ne valide pas la gestion des échecs de l'application.
Exporter les preuves avant de retirer l'ancien service
Conservez la base de configuration autorisée, la carte des dépendances, l’état de la file d’attente, les résultats des tests et les journaux opérationnels pertinents avec une décision de conservation définie. Vérifiez que les preuves restent lisibles après la fin de l’accès à l’ancienne plateforme. Exportez uniquement ce qui est nécessaire et conservez les informations d’identification hors du package.
Définissez des critères de sortie explicites : exécution des tâches planifiées critiques, contrôle des risques en double, examen des preuves du destinataire, gestion des rebonds confirmée et restauration de l'ancienne route testée ou délibérément abandonnée par le propriétaire responsable. Si une tâche mensuelle n'a pas été exécutée, enregistrez cet écart au lieu de déclarer la migration terminée. Retirez les anciennes autorisations et points de terminaison via un contrôle des modifications approuvé après la fermeture de leurs dépendances.