Migrez vos envois sans perdre en réputation, en historique ni en sommeil. Faites tourner les deux fournisseurs en parallèle, puis basculez par étapes.
L'IA aide à associer vos domaines, routes et webhooks Mailgun ; vous validez chaque changement
Listez vos domaines, clés, modèles, webhooks et suppressions.
Ajoutez les enregistrements DNS de MigoSMTP à côté des anciens.
Recréez les modèles et webhooks, importez les suppressions.
Déplacez le trafic par étapes et surveillez la livraison.
Supprimez les anciens enregistrements et clés une fois la situation stable.
La terminologie reflète la documentation du fournisseur au moment de la rédaction. Vérifiez la documentation à jour avant de publier.
curl https://api.mailgun.net/v3/YOUR_DOMAIN/messages \ --user "api:MAILGUN_KEY" \ -F from="hello@yourdomain.com" \ -F to="user@example.com" \ -F subject="Hello" \ -F html="<p>Hi there</p>"
curl https://api.migosmtp.com/v1/send \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"from": "hello@yourdomain.com",
"to": "user@example.com",
"subject": "Hello",
"html": "<p>Hi there</p>"
}'Requêtes données à titre d'illustration. Consultez la référence de l'API pour la liste complète des champs.
Pour migrer de Mailgun vers MigoSMTP, listez vos domaines d'envoi, clés API, routes et webhooks, puis authentifiez chaque domaine avec MigoSMTP tandis que les enregistrements Mailgun restent en place. Recréez les templates, reconstruisez les routes entrantes et importez vos listes de rebonds et de plaintes. Envoyez une petite part du trafic via MigoSMTP, comparez la délivrabilité, puis basculez le reste par étapes. Supprimez les enregistrements DNS et les clés Mailgun une fois qu'ils ne sont plus utilisés et que les résultats sont restés stables.
On change de fournisseur pour regrouper l'envoi, modifier la facturation ou obtenir un autre contrôle du routage. L'essentiel de la configuration se transpose sans difficulté. Chaque domaine Mailgun devient un domaine authentifié MigoSMTP, les clés deviennent des clés à portée limitée, les rebonds et plaintes s'importent comme suppressions, et les pools d'IP correspondent à des IP dédiées. Les spécificités de Mailgun, comme les endpoints par région et la priorité des routes, sont à vérifier dans la documentation actuelle du fournisseur avant de les reproduire.
L'assistant de migration IA lit votre configuration Mailgun exportée et propose la correspondance de chaque domaine, variable de template et webhook avec MigoSMTP, avec un score de confiance pour chaque élément. Les expressions de route qu'il ne peut pas traduire avec certitude sont signalées pour un traitement manuel. Une personne approuve chaque modification avant son application, et les approbations sont consignées pour permettre un audit ultérieur. Vous décidez de l'ordre des domaines, et l'assistant n'envoie jamais d'e-mails ni ne modifie le DNS de lui-même.
Mailgun organise l'envoi par domaine ; migrez donc de la même façon. Authentifiez un domaine, basculez son trafic, vérifiez les résultats, puis recommencez. Les sous-domaines dédiés au marketing et aux e-mails transactionnels peuvent migrer séparément.
Si vous utilisez les routes Mailgun pour transférer ou analyser les e-mails entrants, listez chaque expression de correspondance et chaque action, puis recréez-les sous forme de règle entrante. Testez avec de vraies adresses avant de modifier les enregistrements MX.
Les applications qui envoient via SMTP n'ont souvent besoin que d'un nouvel hôte, d'un nouveau port et de nouveaux identifiants. Changez un service à la fois et gardez les identifiants Mailgun actifs jusqu'à ce que les logs n'affichent plus aucune utilisation.
Si vous utilisez des pools d'IP, décidez quels flux obtiennent des IP dédiées. Lancez chacun avec un calendrier de warm-up et gardez les e-mails à faible volume sur l'infrastructure partagée tant que les IP dédiées n'ont pas fait leurs preuves.
Recréez les routes entrantes une par une et testez chacune avec une adresse d'essai avant de modifier les enregistrements MX.
Migrez un domaine d'envoi à la fois, en commençant par celui qui présente le moins de risques.
Lit les domaines, clés et paramètres webhook exportés, puis propose les équivalents MigoSMTP avec des scores de confiance. Les éléments à faible confiance sont listés à part, et un membre de l'équipe approuve chaque correspondance avant sa création.
Prend les expressions de correspondance et les actions des routes Mailgun et rédige des règles entrantes équivalentes. Il montre ce qu'il a modifié et ce qu'il n'a pas pu convertir, et vous approuvez ou modifiez chaque règle.
Analyse les templates à la recherche de variables et les compare aux données envoyées par votre code, en listant les champs manquants ou renommés. Les corrections ne sont que des suggestions, appliquées après votre validation.
Répond en langage clair aux questions sur votre plan, par exemple quel domaine migrer ensuite. Il cite la documentation pertinente, et chaque étape qu'il recommande exige toujours votre approbation.
Les suggestions de l'IA pour votre migration Mailgun sont examinées et approuvées par vous avant toute application.
Notez chaque domaine d'envoi, sa région et ce qui l'utilise. Les sous-domaines oubliés avec d'anciens scripts sont la cause habituelle des mauvaises surprises après la bascule.
Récupérez les listes de rebonds, de plaintes et de désabonnements de chaque domaine et importez-les avant d'envoyer. Cela protège votre réputation et évite d'écrire à des adresses qui vous ont déjà rejeté.
Capturez des exemples d'événements chez les deux fournisseurs et comparez les champs. Mettez à jour votre gestionnaire pour accepter le nouveau format et vérifiez le contrôle de signature avec la nouvelle clé de signature.
Abaissez les TTL des enregistrements que vous comptez modifier la veille. En cas de retour arrière, la modification prendra effet en quelques minutes plutôt qu'en plusieurs heures.
Laissez les anciennes clés actives jusqu'à ce que les logs n'affichent aucun trafic pendant plusieurs jours. Révoquez-les ensuite et supprimez les enregistrements DNS inutilisés.
Laissez les anciennes routes en place tant que les nouvelles n'ont pas traité du courrier réel sans problème.
Vous quittez Mailgun ? Notre équipe peut examiner vos domaines et routes avant le démarrage.
Inventoriez vos domaines, clés, routes et webhooks, authentifiez chaque domaine avec MigoSMTP en parallèle de Mailgun, recréez les templates et les routes, importez les suppressions et basculez le trafic progressivement. Retirez les enregistrements et clés Mailgun une fois le volume stable et les logs sans aucune utilisation restante. Testez d'abord sur une petite part du trafic et examinez les résultats avec votre équipe.
Un seul domaine envoyant en SMTP peut migrer en quelques jours. Plusieurs domaines, des routes entrantes et des IP dédiées prennent plus de temps, car chacun demande des tests et un warm-up. Prévoyez plusieurs semaines et migrez un domaine à la fois. Testez d'abord sur une petite part du trafic et examinez les résultats avec votre équipe.
Oui, mais vous devez les recréer. Exportez l'expression de correspondance et l'action de chaque route, puis reconstruisez-les sous forme de règles entrantes dans MigoSMTP. Testez avec une adresse d'essai avant de mettre à jour les enregistrements MX. Vérifiez le comportement des priorités dans la documentation actuelle du fournisseur. Gardez les anciennes routes actives jusqu'à confirmation du bon fonctionnement des nouvelles.
La réputation est liée à votre domaine et à vos IP d'envoi ; elle ne se transfère donc pas automatiquement. Authentifiez le domaine, commencez par une petite part, puis augmentez progressivement. Les IP dédiées nécessitent un vrai warm-up avant le volume complet. Testez d'abord sur une petite part du trafic et examinez les résultats avec votre équipe.
Exportez-les par domaine et importez-les dans MigoSMTP comme suppressions avant votre premier envoi. Cela évite d'écrire à des adresses ayant déjà généré un rebond ou une plainte. Vérifiez le format d'export dans la documentation actuelle du fournisseur avant l'import. Testez d'abord sur une petite part du trafic et examinez les résultats avec votre équipe.
Pour SMTP, généralement seulement l'hôte, le port et les identifiants. Pour l'API HTTP, l'endpoint, l'authentification et les noms de champs diffèrent : mettez à jour l'appel ou utilisez un SDK. Testez en préproduction et changez un service à la fois. Testez d'abord sur une petite part du trafic et examinez les résultats avec votre équipe.
Oui. Les deux peuvent authentifier votre domaine en même temps : vous pouvez donc faire passer une partie de vos e-mails par MigoSMTP et laisser le reste sur Mailgun. Séparer par domaine ou par application simplifie les comparaisons. Testez d'abord sur une petite part du trafic et examinez les résultats avec votre équipe.
Elle prend en charge la correspondance répétitive. L'assistant lit vos domaines, webhooks et templates exportés, propose des équivalents MigoSMTP avec des scores de confiance et signale les routes qu'il ne sait pas traduire. Une personne approuve chaque modification avant son application.
Oui. La plupart des équipes envoient d'abord une petite part via MigoSMTP, puis augmentent progressivement.
Passer d'un pool partagé à une IP dédiée exige un warm-up. Utilisez le guide ou le calculateur.
Notre équipe peut examiner votre plan pour Mailgun et le calendrier de bascule.
Parlez-nous de vos domaines, de votre volume et de votre configuration, et nous vous aiderons à planifier une bascule sûre et progressive.
Créez un compte, ajoutez votre domaine et envoyez votre premier e-mail.