Die Migration von E-Mail-Templates aus Pardot (Salesforce Account Engagement) sollte immer mit einer einzigen E-Mail beginnen, deren Struktur und Zweck Ihr Team lückenlos versteht. Definieren Sie das Ziel der Kampagne, erfassen Sie jedes dynamische Feld sowie alle Links und stellen Sie sicher, dass das Mailing im Zielsystem dieselbe Handlung auslöst. Eine saubere HTML-Datei zu übertragen, ist nur ein kleiner Teil dieser Aufgabe.
Nutzen Sie Migma, um eine freigegebene Design-Referenz aufzubauen, während die Verantwortlichen für Account Engagement und das Zielsystem Datenmodelle, Automationen und Versandregeln aufsetzen. Migma ersetzt weder Salesforce-Datensätze noch Lead-Scoring oder B2B-Journey-Logiken. Dieser Leitfaden konzentriert sich auf das E-Mail-Asset selbst und die Nachweise, die für eine belastbare Abnahme nötig sind.
Kreative Entscheidungen von der Plattformentscheidung trennen
Brevos Vergleich von Pardot-Alternativen vom 7. September 2026 zeigt typische Fragestellungen bei einem Systemwechsel auf. Der Artikel dient hier als Recherchequelle – nicht als Vorlage für Plattform-Rankings oder als Beleg dafür, dass ein anderes Tool alle Funktionen von Account Engagement 1:1 abbildet.
Dokumentieren Sie präzise, was tatsächlich migriert wird. Ein einzelner Newsletter, ein flexibles Master-Template und eine automatisierte Nurture-Mail haben grundlegend unterschiedliche Abhängigkeiten. Ein Design kann im Zielsystem einsatzbereit sein, während die zugehörige Marketing-Automation noch konfiguriert werden muss. Halten Sie diese Zwischenschritte im Projektverlauf getrennt fest.
Wählen Sie für den ersten Testlauf eine repräsentative E-Mail mit einer überschaubaren Anzahl an Variablen. Starten Sie weder mit Ihrem komplexesten Newsletter voller dynamischer Bedingungen noch mit einer trivialen Textnachricht, die keine der geschäftskritischen Funktionen nutzt.
Eine verlässliche Referenz für das Review aufbauen
Sammeln Sie den aktuellen, freigegebenen Text, das Layout, die Absenderangaben, die Reply-to-Adresse, Bildressourcen, Linkziele und das vorgesehene Zielsegment. Sichern Sie einen Screenshot und eine gerenderte Version des ursprünglichen Mailings. Dokumentieren Sie die Versionsnummer und das Freigabedatum durch den Kampagnenverantwortlichen.
Migma ermöglicht das Erstellen und Bearbeiten von E-Mails sowie den Import bestehender Designs. Nutzen Sie das Tool, um das gewünschte Mailing anzulegen oder anzupassen, und lassen Sie das Ergebnis abnehmen. Vermeiden Sie es, während der Migration stillschweigend visuelle Änderungen vorzunehmen: Das erschwert die spätere Prüfung, ob Abweichungen beabsichtigt sind oder auf Übertragungsfehlern beruhen.
Ist ein Redesign geplant, kennzeichnen Sie diesen Schritt eindeutig. Prüfen Sie das neue Mailing zunächst inhaltlich, bevor Sie das technische Verhalten im Zielsystem analysieren. Ein moderneres Layout hilft wenig, wenn der Abmeldepfad fehlt oder ein CTA-Button auf das falsche Angebot verlinkt.
Erst die Semantik abgleichen, dann die Syntax anpassen
Erstellen Sie eine Übersicht für Variablen mit fünf Spalten: Funktion in der E-Mail, Quellfeld, Zielfeld, geprüfter Beispielwert und Fallback-Verhalten bei fehlenden Daten. Die exakte Syntax für Merge-Tags entnehmen Sie der Dokumentation des jeweiligen Zielsystems. Vermeiden Sie pauschale Suchen-und-Ersetzen-Aktionen über Systemgrenzen hinweg.
Eine persönliche Anrede benötigt beispielsweise einen Vornamen sowie einen definierten Fallback-Wert. Kontaktangaben von Vertriebsansprechpartnern erfordern feste Routing-Regeln. Ein Produktlink muss zur jeweiligen Zielgruppe passen. Auch eine Variablenbezeichnung wie „Owner“ bleibt fehleranfällig, solange nicht geklärt ist, ob damit der Account Owner, der Lead Owner oder der Kampagnenautor gemeint ist.
Testen Sie kurze, lange und leere Feldwerte sowie Sonderzeichen anhand von Testdatensätzen. Beurteilen Sie immer die fertig gerenderte Nachricht, die beim Empfänger ankommt, nicht nur den Platzhalter im Template-Editor. Selbst wenn ein Tag im Quellcode vertraut wirkt, kann er nach dem Transfer fehlerhaft aufgelöst werden.
Die vier Klick- und Interaktionspfade testen
Prüfen Sie die primäre Handlungsaufforderung (CTA), den Antwortkanal, die Präferenzverwaltung und alle verlinkten Dokumente oder Landingpages. Für jeden dieser Pfade muss die Zuständigkeit geklärt sein. Ein optisch einwandfreier Button belegt nicht, dass das verknüpfte Formular auf der Zielseite noch wie vorgesehen funktioniert.
| Pfad | Erforderlicher Nachweis |
|---|---|
| Hauptaktion | Linkziel stimmt mit dem freigegebenen Angebot und der Zielgruppe überein |
| Antwort (Reply) | Eingehende Antworten erreichen das zuständige Team |
| Präferenzen | Das Zielsystem übernimmt das definierte Opt-out- und Consent-Verhalten |
| Begleitende Inhalte | Bilder, Grafiken und verlinkte Dateien bleiben wie vorgesehen erreichbar |
Diese Checkliste dient der Qualitätsprüfung, nicht als Übersicht über Migma-Integrationen. Klären Sie vorab, welche Export- und Übergabeformate Ihr Zielsystem unterstützt, bevor Sie automatisierte Transfers zusagen.
Die final befüllte E-Mail abnehmen
Führen Sie den Preflight-Check in Migma für die freigegebene Vorlage durch. Kontrollieren Sie Previews für gängige E-Mail-Clients, Textstände, Verlinkungen und Warnhinweise zur Zustellbarkeit. Vergleichen Sie anschließend die final mit Daten befüllte Test-E-Mail aus dem Zielsystem mit der abgenommenen Referenz. Änderungen, die erst durch das Versandsystem entstehen, müssen separat geprüft werden.
Achten Sie auf lange Betreffzeilen, Vorschautexte (Preheader), die mobile Darstellung und die Lesbarkeit bei blockierten Bildern. Kernbotschaften müssen auch dann verständlich bleiben, wenn Schmuckgrafiken nicht geladen werden. Ein Preflight-Check minimiert Fehlerquellen, garantiert jedoch kein identisches Rendering über alle Postfächer hinweg.
Legen Sie im Betriebsteam verbindlich fest, über welches System der erste reguläre Versand läuft. Verhindern Sie, dass Quell- und Zielsystem dieselbe Kampagne parallel versenden. Sollte ein Rollback nötig sein, bereinigen Sie offene Versandaufträge, bevor Zuständigkeiten erneut gewechselt werden.
Erst skalieren, wenn die Prüfschritte stehen
Dokumentieren Sie die Freigabe direkt am Template: mit Versionsstand, Variablen-Mapping, Testfällen, Namen der prüfenden Person und verbleibenden Einschränkungen. Dieser Nachweis beschleunigt die nächsten Vorlagen, da im Team klar definiert ist, welche Kriterien ein migriertes Template erfüllen muss.
Zeigen sich beim ersten Mailing unklare Zuständigkeiten oder fehlende Datenfelder, beheben Sie diese Ursachen, bevor Sie Vorlagen im Paket migrieren. Starten Sie die Design-Prüfung in Migma, halten Sie die freigegebene Referenz fest und übertragen Sie Kampagnen strukturiert Schritt für Schritt. Eine kontrollierte Umstellung liefert belastbare Ergebnisse – ein Verzeichnis importierter HTML-Dateien ohne Funktionsprüfung hingegen nicht.
Häufig gestellte Fragen
Ist ein Template-Export bereits eine vollständige Pardot-Migration?
Nein. Das Template muss getrennt von Kontakten, Lead-Scoring, Berechtigungen, Automationslogiken und Versandeinstellungen geprüft werden. Dieser Leitfaden behandelt die Design-Referenz und die Funktionsprüfung der final gerenderten E-Mail.
Kann die Syntax für Personalisierungsfelder direkt übernommen werden?
Nein. Nutzen Sie die vom Zielsystem unterstützte Syntax und gleichen Sie zuerst die Bedeutung der Felder ab. Prüfen Sie reguläre, leere, überdurchschnittlich lange und sonderzeichenhaltige Werte in der tatsächlichen Testnachricht.
Ist ein Redesign während der Migration sinnvoll?
Ja, sofern das Redesign ausdrücklich freigegeben wurde. Dokumentieren Sie die Referenzversion sauber, damit Prüfer zwischen beabsichtigten Designänderungen und technischen Übertragungsfehlern unterscheiden können.
Welche Dokumentation sollte für die erste migrierte Vorlage vorliegen?
Sichern Sie die abgenommene Design-Referenz, den Versionsstand, das Variablen-Mapping, die geprüften Linkpfade, anonymisierte Testfälle, das Review-Protokoll, die Versandzuständigkeit und bekannte Einschränkungen an einem zentralen Ort.