Der Datenexport lief sauber. 400.000 Kontakte, alle Felder gemappt, die ersten Profile sind im neuen System sichtbar. Und dann fragt jemand aus dem Team: „Wo sind eigentlich unsere Opt-ins?” Die Antwort dauert drei Tage, kostet Nerven und endet mit einer Erkenntnis, die im Migrationsleitfaden des Anbieters nicht vorkommt.
Wir begleiten CRM-Migrationen zwischen Braze, Klaviyo und Brevo. Was dabei auffällt: Die technische Datenmigration ist selten das Problem. Die Kontakte kommen rüber. Die Felder auch, meistens. Was auf der Strecke bleibt, ist alles andere.
Consent ist kein Datenfeld
Der häufigste Fehler bei CRM-Migrationen betrifft nicht Daten, sondern Rechte. Opt-in-Status ist in jeder Plattform anders abgebildet. Klaviyo speichert Consent als Property am Profil, Braze nutzt Subscription Groups, Brevo arbeitet mit Listen-basiertem Consent. Diese Strukturen sind nicht kompatibel.
Was das praktisch bedeutet: Ein Kontakt, der in Mailchimp als „subscribed” geführt wird, hat in Klaviyo nicht automatisch einen gültigen Opt-in. Wer trotzdem mailt, riskiert DSGVO-Verstöße. Kein theoretisches Risiko, sondern ein konkretes.
In fast jeder Migration, die wir begleiten, ist eine Re-Consent-Kampagne nötig. Das heißt: Kontakte, die im alten System aktiv und eingewilligt waren, müssen im neuen System erneut bestätigen. Das reduziert die adressierbare Liste, manchmal um 20 bis 40 Prozent. Für das Team fühlt sich das an wie ein Rückschritt. Ist es aber nicht. Es ist der Moment, in dem klar wird, wie viele Kontakte im alten System eigentlich schon nicht mehr erreichbar waren.
Wer tiefer in das Thema Consent-Strukturen einsteigen will: Unser Artikel zu Consent-Management in CRM-Plattformen beschreibt die Unterschiede im Detail.
Automationen nachbauen heißt neu denken
23 aktive Flows in Klaviyo, 14 Canvases in Braze, 9 Szenarien in Brevo. In jeder Instanz, die wir für eine Migration analysieren, finden wir Automationen, die seit Monaten oder Jahren laufen, ohne dass jemand sie grundlegend hinterfragt hat.
Eine Migration zwingt dazu, jede einzelne Automation anzufassen. Nicht weil der Export nicht klappt, sondern weil die Logik nicht portabel ist. Ein Klaviyo-Flow, der auf einem Custom Event „Added to Cart” triggert, funktioniert in Braze nur, wenn das gleiche Event mit dem gleichen Schema gesendet wird. Oft ist es das nicht. Die Datenstruktur hinter Custom Events unterscheidet sich zwischen den Plattformen grundlegend.
Das klingt nach einem Problem. Ist es auch, operativ gesehen. Gleichzeitig ist es die einzige Gelegenheit, Automationen zu hinterfragen, die niemand mehr anfasst. In einer typischen Migration fallen 30 bis 40 Prozent der bestehenden Automationen weg, weil sie veraltet, redundant oder wirkungslos sind. Die Migration macht sichtbar, was im Tagesgeschäft untergeht.
Der zeitliche Aufwand wird trotzdem unterschätzt. Drei bis sechs Wochen für den Neuaufbau der Kern-Automationen sind realistisch. Wer parallel zum Tagesgeschäft migriert, braucht länger.
Segmente, die es drüben nicht gibt
Segmente sind das dritte große Migrationsrisiko, das selten auf dem Radar auftaucht. Jede Plattform hat eigene Mechanismen für Segmentierung. Klaviyo arbeitet mit Conditions auf Profil-Properties und Event-Daten. Braze nutzt Segments mit Filtern auf Attributes und Custom Events. Brevo setzt auf Listen und dynamische Segmente mit begrenzter Logik-Tiefe.
Ein Segment wie „Kunden, die in den letzten 90 Tagen gekauft haben und mindestens zwei Newsletter geöffnet haben, aber nicht im VIP-Programm sind” lässt sich in Klaviyo mit drei Conditions abbilden. In Brevo braucht es dafür einen Workaround über berechnete Felder. In Braze funktioniert es über eine Kombination aus Segment Filters und Custom Attributes, die vorher angelegt werden müssen.
Segmente lassen sich nicht exportieren. Sie müssen im neuen System komplett neu gebaut werden. Das ist aufwendig, aber auch lehrreich. Bei jeder Migration, die wir begleiten, finden wir Segmente, die auf veralteten Annahmen basieren. Lifecycle-Stages, die seit einem Jahr nicht angepasst wurden. Engagement-Scoring, das auf Metriken beruht, die längst ihre Aussagekraft verloren haben. Wer sich für den Zusammenhang zwischen Segmentierung und Lifecycle-Stages interessiert, findet dort mehr Kontext.
Die Erwartungslücke ist das eigentliche Problem
Die technischen Herausforderungen sind lösbar. Was Migrationen wirklich gefährdet, ist die Erwartungshaltung. Teams gehen davon aus, dass nach dem Wechsel alles so funktioniert wie vorher, nur schneller, schöner, besser. Die Realität sieht anders aus.
Nach einer Migration gibt es eine Phase von vier bis acht Wochen, in der vieles nicht funktioniert wie gewohnt. Reports fehlen historische Vergleichsdaten. Automationen laufen noch nicht auf dem alten Niveau. Das Team muss sich in ein neues Interface einarbeiten. In dieser Phase sinkt die Produktivität, und wenn das vorher niemand kommuniziert hat, sinkt auch das Vertrauen in die Entscheidung.
Wir empfehlen jedes Mal das gleiche: Bevor die Migration startet, eine ehrliche Bestandsaufnahme machen. Was funktioniert heute wirklich? Was davon ist übertragbar? Und was bauen wir bewusst nicht nach, weil es ohnehin nicht funktioniert hat?
Was ihr daraus mitnehmt
Eine CRM-Migration ist kein Umzug. Es ist ein Neuaufbau mit Altbestand. Wer das akzeptiert, kann die Migration als Chance nutzen, das operative Setup grundsätzlich zu hinterfragen: Welche Automationen brauchen wir wirklich? Welche Segmente ergeben noch Sinn? Und wie sauber ist unser Consent eigentlich?
Die Plattform zu wechseln ist eine Entscheidung. Das operative Setup dabei nicht zu hinterfragen, ist ein Fehler. Wenn ihr wissen wollt, wie euer aktuelles Setup dasteht, bevor ihr migriert: Dafür gibt es unseren Instanz-Check.
