Eine E-Mail mit dem Hinweis „Ihr Dokument liegt als Anhang bei“ gibt ein klares Versprechen. Bei einer Migration von Mailgun kann das Mailing auf den ersten Blick fehlerfrei wirken, während die Datei fehlt, veraltet ist oder zum falschen Ereignis ausgeliefert wird. Prüfen Sie Anhänge deshalb immer aus Sicht der Empfänger – nicht als nebensächliches Implementierungsdetail.
Erstellen Sie die freigegebenen Mailings in Migma. Lassen Sie Application- und Versandverantwortliche vorab prüfen, wie Dokumente ausgewählt werden, welche Zugriffsrechte gelten und wie das Zielsystem Anhänge aktuell unterstützt. Dieser Leitfaden setzt nicht voraus, dass sich jeder Anhang-Workflow aus Mailgun unverändert zu Loops oder einem anderen Anbieter migrieren lässt.
Vor der Umstellung: Bestandsaufnahme aller Versprechen
Identifizieren Sie alle Transaktions- und Marketing-Mails, die in Betreff, Vorschautext, Fließtext oder Support-Hinweisen auf einen Anhang verweisen. Erfassen Sie auch Formulierungen wie „Öffnen Sie den beigefügten Leitfaden“, selbst wenn die eigentliche Datei an anderer Stelle in der Applikation angehängt wird. Das Mailing-Template allein zeigt oft nicht die gesamte technische Abhängigkeit.
Der Mailgun-Migrationsleitfaden von Loops beschreibt, wie Sie Versandlogiken zuordnen und vorlagenbasierte Workflows analysieren. Nutzen Sie diese Dokumentation zur Orientierung. Ob Anhänge wie geplant übernommen werden können, müssen Sie jedoch direkt anhand Ihrer Quell-Implementierung und der aktuellen Dokumentation des Zielsystems verifizieren.
Dokumentieren Sie für jede Nachricht:
- den Zweck des Dokuments,
- die Auswahl- und Generierungslogik,
- die freigegebene Version,
- Dateiname und Dateiformat,
- die erwartete Dateigröße,
- die fachliche und technische Zuständigkeit.
Unterscheiden Sie strikt zwischen statischen Inhalten (z. B. einem Onboarding-Guide) und personalisierten Dokumenten (z. B. einer Abrechnung). Beide Typen stellen grundlegend andere Anforderungen an Freigabe und Datenschutz.
Anhang oder Download-Link: Was erfüllt die Anforderung?
Ersetzen Sie Anhänge nicht stillschweigend durch Download-Links, nur weil es die Migration vereinfacht. Empfänger benötigen häufig eine lokale Offline-Kopie, einen unveränderlichen Nachweis oder einen geschützten Bereich. Klären Sie mit den zuständigen Stakeholdern, welcher Bereitstellungsweg die geschäftlichen Anforderungen erfüllt.
Ein Link ist meist dann sinnvoll, wenn sich Dokumente häufig ändern oder einer Zugriffskontrolle unterliegen. In diesem Fall muss das Mailing den Klickpfad präzise beschreiben. Ein Dateianhang eignet sich für feste, freigegebene Dokumente – setzt aber voraus, dass Versionierung und Versandweg sauber geprüft sind. Beide Ansätze haben ihre Berechtigung; es gibt keine Universallösung.
Ändert sich der Bereitstellungsweg, passen Sie das Migma-Copywriting gezielt an. „Rufen Sie Ihr Dokument im Portal ab“ weckt andere Erwartungen als „Ihr Dokument liegt als Anhang bei“. Überarbeiten Sie auch Betreffzeile und Preheader, da Empfänger Entscheidungen oft schon anhand dieser Vorschau treffen.
Zielsystem prüfen – vor dem finalen Cutover
Lassen Sie das zuständige Versandteam die aktuellen Schnittstellen des Zielanbieters prüfen: unterstützte Dateiformate, Größenbeschränkungen, Encoding-Vorgaben und tarifabhängige Limits. Halten Sie das Prüfdatum fest. Verlassen Sie sich nicht auf alte Dokumentationsstände und übertragen Sie reine SMTP-Workflows nicht unbesehen auf vorlagenbasierte APIs.
Klären Sie genau, an welcher Stelle im System die Datei generiert und wo sie an die Nachricht angehängt wird. Ein Template-Identifier mit dynamischen Parametern definiert zwar den Inhalt der E-Mail, überträgt das Dokument aber unter Umständen nicht automatisch. Das Migrationskonzept muss beide Schritte abbilden.
Unterstützt das Zielsystem die benötigte Anhang-Logik nicht, bleibt das bisherige Versandsystem für diesen Nachrichtentyp aktiv, bis eine freigegebene Alternative bereitsteht. Schließen Sie eine Migration keinesfalls formal ab, indem Sie den Anhang einfach aus den Testfällen streichen.
Testen mit einer Abnahmematrix
Ein fiktiver Onboarding-Leitfaden ermöglicht praxisnahe Tests ohne Risiko. Prüfen Sie das freigegebene Standarddokument, einen unfertigen Entwurf, den Fall einer fehlenden Datei sowie Dateinamen mit Leer- und Sonderzeichen. Testen Sie zudem realistische Grenzwerte bei Dateigröße und Format auf Basis der Limits des Zielsystems.
| Testfall | Erforderliche Prüfung |
|---|---|
| Freigegebenes Dokument | Korrekte Version und einwandfreie Lesbarkeit |
| Fehlende Datei | Klar definiertes Fehlerverhalten vor dem Versand |
| Falsche Version | Abgleich schlägt bei abweichendem Versionsstand an |
| Dokument mit Zugriffsbeschränkung | Berechtigungen und Empfängerkreis verifiziert |
| Geänderter Bereitstellungsweg | Wording im Mailing passt exakt zu Anhang bzw. Link |
Verwenden Sie für Tests keine echten Kundendokumente. Testdaten genügen vollständig, um den Übertragungsweg zu validieren, und verhindern Datenschutzrisiken. Protokollieren Sie Referenzen zu Produktivdaten ausschließlich in Ihren regulären Produktivsystemen.
Mailing und Anhang gemeinsam freigeben
Migma erstellt bearbeitbare E-Mail-Vorlagen auf Basis freigegebener Inhalte. Generieren Sie klare Transaktions-Mailings mit einem eindeutigen Call-to-Action und einem direkten Kontakt zum Support. Übergeben Sie dem Prompting nur die Informationen, die für die Texterstellung relevant sind – laden Sie keine vertraulichen Quelldokumente hoch.
Führen Sie vor dem Versand Email Preflight durch, um Links, Formulierungen, Posteingangsvorschauen und Zustellbarkeitsrisiken zu kontrollieren. Prüfen Sie anschließend die finale Testnachricht direkt im Versandsystem. Öffnen Sie die angehängte Datei über den vorgesehenen Testprozess und stellen Sie sicher, dass Inhalt und E-Mail-Text übereinstimmen.
Eine Design-Vorschau belegt nicht, dass die Datei tatsächlich mitgesendet wurde. Ebenso wenig garantiert die Annahme durch den Mail-Server, dass der Empfänger die Datei öffnen oder lesen kann. Dokumentieren Sie beide Prüfschritte separat im Abnahmeprotokoll.
Migration nach Dokumententypen staffeln
Legen Sie eine feste Zuständigkeit für den geplanten Versand fest und arbeiten Sie bestehende Versand-Queues vollständig ab, bevor Sie den Cutover durchführen. Vermeiden Sie es, dasselbe Dokument für Vergleichstests parallel über beide Anbieter an echte Empfänger zu senden. Vergleichen Sie stattdessen kontrollierte Test-Outputs und folgen Sie dem definierten Rollout-Prozess.
Archivieren Sie Dokumentenversion, Template-Stand, Schnittstellenprüfung, Testmatrix, Freigabeverantwortliche und die finalen Testnachweise an einem zentralen Ort. So bleiben spätere Anpassungen jederzeit nachvollziehbar. Die Vorlage entsteht in Migma – als abgeschlossen gilt die Migration jedoch erst, wenn das Dokument verlässlich und wie versprochen beim Empfänger ankommt.
Häufig gestellte Fragen
Lässt sich jeder Anhang-Workflow aus Mailgun eins zu eins übernehmen?
Davon sollten Sie nicht ausgehen. Prüfen Sie vor der Freigabe des Cutovers die aktuellen Spezifikationen, Limits, Dateiformate und das API-Verhalten des Zielsystems für den konkreten Nachrichtentyp.
Können wir Anhänge einfach durch einen Portal-Link ersetzen?
Nur wenn der Fachbereich dieser Bereitstellungsmethode ausdrücklich zustimmt. Passen Sie Betreff, Vorschautext, Fließtext und CTA an, damit das Mailing den tatsächlichen Bereitstellungsweg widerspiegelt.
Prüft Email Preflight auch den übertragenen Anhang?
Nein. Kontrollieren Sie die tatsächlich versendete Testnachricht samt Datei direkt im Versandsystem. Preflight analysiert Layout, Links, Wording und Zustellbarkeitsrisiken.
Was passiert, wenn das Zielsystem das geforderte Anhang-Szenario nicht unterstützt?
Behalten Sie das bisherige Versandsystem für diesen Nachrichtentyp bei, während Sie eine freigegebene Alternative evaluieren. Entfernen Sie die Datei nicht einfach aus dem Testfall, um die Migration künstlich als abgeschlossen zu deklarieren.