Was bei CRM-Migrationen schiefläuft (und wie Sie es verhindern)

CRM-Migrationen scheitern selten an der Technologie.

Sie scheitern aus vorhersehbaren, vermeidbaren Gründen: Daten, die ohne Audit migriert werden, Akzeptanz und Nutzung, die als Schulungstag behandelt werden, ein Projektumfang, der entdeckt statt definiert wird, ein Umstellungstermin, der durch eine Vertragsverlängerung statt durch die Einsatzbereitschaft bestimmt wird, und kein Plan für die Zeit nach dem Go-live.

Jeder dieser Fehlerpunkte ist frühzeitig erkennbar, wenn man weiß, worauf man achten muss.

Dieser Artikel benennt sie. Nicht weil Migrationen von Natur aus gefährlich sind, sondern weil die Angst vor einer gescheiterten Migration der wichtigste Grund ist, warum Enterprise-Teams auf einer Plattform verbleiben, die ihren Anforderungen nicht mehr gerecht wird.

Wenn Ihre letzte Implementierung schlecht verlaufen ist oder Sie durch eine Akquisition ein CRM übernommen haben, dem niemand vollständig vertraut, wurde dieser Artikel für Sie geschrieben.

Warum scheitern CRM-Migrationen wirklich?

Fragen Sie einen Softwareanbieter, und Sie hören von Daten-Mapping-Tools und API-Limits.

Fragen Sie die Führungskräfte, die eine gescheiterte Migration erlebt haben, und Sie hören etwas anderes: Das Vertriebsteam ist still zu Tabellenkalkulationen zurückgekehrt, der Vorstand hat Fragen gestellt, die das neue System nicht beantworten konnte, und achtzehn Monate später zahlte das Unternehmen für zwei Plattformen und vertraute keiner von beiden.

Das Muster hinter nahezu jeder gescheiterten Migration ist organisatorischer, nicht technischer Natur. Fünf Fehlerpunkte verursachen die überwältigende Mehrheit der Probleme: Daten, Akzeptanz und Nutzung, Projektumfang, Zeitplanung der Umstellung und das Vakuum nach dem Go-live.

Was sie gefährlich macht, ist nicht, dass sie schwer zu lösen wären; es ist, dass sie sich leise bemerkbar machen, Monate bevor jemand das Projekt als „gefährdet“ einstuft.

Der Rest dieses Artikels behandelt jeden einzelnen Punkt, zusammen mit den jeweiligen Frühwarnsignalen.

Was läuft bei den Daten schief?

Der häufigste Datenfehler ist zugleich der einfachste: das vorhandene Chaos unverändert zu migrieren.

Teams unter Zeitdruck übertragen jeden Datensatz, jedes Feld und jeden halbfertigen Workflow vom alten System in das neue und wundern sich dann, warum das neue CRM sich genauso anfühlt wie das alte, nur dass jetzt niemand mehr weiß, wo sich etwas befindet.

Drei Datenentscheidungen werden bei gescheiterten Migrationen übersprungen:

• Das Audit, das nie stattfand. Niemand hat entschieden, was zurückgelassen werden soll. Zehn Jahre veralteter Kontakte, doppelter Unternehmensdatensätze und aufgegebener benutzerdefinierter Felder werden nicht dadurch zum Vermögenswert, dass man die Plattform wechselt. Ein ehrliches Datenaudit, das klärt, was Sie tatsächlich nutzen und worüber das Unternehmen wirklich berichtet, ist der Schritt mit dem größten Hebel im gesamten Projekt. Er wird am häufigsten gestrichen, wenn Zeitpläne enger werden.
• Feld-Mapping ohne Fachverantwortliche. Felder werden eins zu eins von der Person gemappt, die über Administratorrechte verfügt, ohne die notwendigen Gespräche mit Vertrieb und Finanzen darüber, was diese Felder bedeuten. Das Ergebnis zeigt sich im ungünstigsten Moment: bei der ersten Vorstandssitzung nach dem Go-live, wenn die Pipeline-Zahlen nicht übereinstimmen und niemand erklären kann, warum. Wenn der Vorstand Fragen stellt, die das neue System nicht beantworten kann, ist die Migration gescheitert, unabhängig davon, wie sauber die technische Umstellung verlief.
• Kein Verantwortlicher nach dem Go-live. Datenqualität wird als Projektphase behandelt statt als dauerhafte Funktion mit klarer Verantwortung. Saubere Daten am Tag des Go-live verschlechtern sich innerhalb eines Quartals, wenn niemand dafür verantwortlich ist. Migrationen, die Bestand haben, weisen die Datenverantwortung vor der Umstellung zu, nicht danach.

Dies gilt in doppeltem Maße für Konsolidierungen nach Akquisitionen, bei denen ein regional zugekauftes Unternehmen sein eigenes CRM, eigene Definitionen einer „qualifizierten Opportunity“ und eigene Duplikate mitbringt.

Plattformen zu konsolidieren, ohne zuvor diese Definitionen abzugleichen, verlagert die Verwirrung in ein einziges System; es beseitigt sie nicht.

Warum hören Teams auf, das neue CRM zu nutzen?

Fehlende Akzeptanz und Nutzung sind die Probleme, die Führungskräfte am persönlichsten spüren, weil sie in jeder Pipeline-Review sichtbar sind: Das CRM sagt das eine, die Vertriebsmitarbeiter sagen etwas anderes, und irgendwo enthält eine parallel geführte Tabelle die echten Zahlen.

Es passiert selten, weil das Team „sich gegen Veränderung sträubt“. Es passiert, weil die Einführung bei den Anwendern auf Schulungen reduziert wurde: ein Launch-Webinar, ein Hilfsdokument, eine E-Mail der Führungskraft.

Sie wurde nicht als eigenständiger Arbeitsbereich mit demselben Gewicht wie Daten und Integrationen behandelt. Schulung zeigt den Mitarbeitern, wo die Schaltflächen sind.

Akzeptanz und Nutzung zu fördern ist die schwierigere Aufgabe, das neue System zum Weg des geringsten Widerstands für die Menschen zu machen, die es befüllen: weniger Pflichtfelder als im alten System, nicht mehr; Berichte, die Führungskräfte tatsächlich in Meetings verwenden; eine Vertriebsleitung, die das CRM ab der ersten Woche in jeder Pipeline-Review nutzt, sodass es keinen anderen Ort für die maßgeblichen Zahlen gibt.

Es gibt einen verstärkenden Faktor, der benannt werden muss: Wenn die letzte Implementierung gescheitert ist, erinnert sich Ihr Team daran. Eine Belegschaft, die bereits einmal erlebt hat, wie ein CRM-Projekt angekündigt, gefeiert und still wieder aufgegeben wurde, wird rational abwarten, ob es diesem Projekt ebenso ergeht.

Diese Skepsis ist kein Kommunikationsproblem, das mit einer Launch-Kampagne zu lösen wäre; sie ist eine Vorgabe für die Gestaltung des Projekts.

Das Projekt muss frühzeitig sichtbare Erfolge für die operativen Teams liefern, oder es wird am Ausgang des letzten Projekts gemessen.

Was läuft beim Projektumfang und bei der Zeitplanung schief?

Fehler im Projektumfang folgen einem erkennbaren Muster.

Das Projekt wird rund um das CRM selbst definiert; die Integrationen sind „eine Liste, die wir später finalisieren“. Dann beginnt die Discovery-Phase, und die Liste wächst: die ERP-Synchronisierung, das Abrechnungssystem, die Marketing-Automation-Plattform und das Angebots-Tool, das ein akquiriertes Unternehmen mitgebracht hat und ohne das eine Region nicht arbeiten kann.

Jede einzelne Ergänzung ist für sich genommen nachvollziehbar. Zusammengenommen verwandeln sie eine Plattformmigration in ein Systemintegrationsprogramm, das weder als solches kalkuliert noch geplant wurde.

Der zweite Fehler im Projektumfang ist die Big-Bang-Umstellung: jedes Team, jede Region, jede Integration an einem einzigen Wochenende aktiviert. Big-Bang wirkt entschlossen, konzentriert aber sämtliche Risiken des Projekts in ein einziges Ereignis ohne einen Rollback-Plan, an den irgendjemand ernsthaft glaubt.

Stufenweise Rollouts, nach Geschäftseinheit, Region oder Funktion, sind auf dem Papier langsamer und in der Praxis deutlich schneller, weil Probleme auftreten, wenn sie noch klein und behebbar sind, statt alle auf einmal vor der gesamten Organisation.

Der dritte Fehler besteht darin, den Zeitplan von etwas anderem als der tatsächlichen Einsatzbereitschaft bestimmen zu lassen. Umstellungstermine, die gewählt werden, weil ein Altvertrag zur Verlängerung ansteht, oder die in die letzten Wochen eines Quartals gelegt werden, wenn Vertriebsteams keinerlei Kapazitäten frei haben, gehören zu den zuverlässigsten Vorzeichen für einen schwierigen Go-live.

Die Vertragsverlängerung ist eine kommerzielle Verhandlung; behandeln Sie sie als solche, anstatt sie die risikoreichste Phase des Projekts verkürzen zu lassen.

Was läuft nach dem Go-live schief?

Der Go-live ist der gefährlichste Moment einer Migration, gerade weil er wie die Ziellinie aussieht. Drei Lücken nach dem Go-live verursachen den größten Schaden:

• Keine Hypercare-Phase. Die ersten Wochen nach der Umstellung erzeugen einen Anstieg von Fragen, Sonderfällen und kleinen Korrekturen. Projekte, die eine Hypercare-Phase einplanen, mit dediziertem, namentlich benanntem Support und schneller Reaktionszeit, wandeln diesen Anstieg in Vertrauen um. Projekte, bei denen das Implementierungsteam am Tag des Go-live abgezogen wird, wandeln ihn in die erste parallel geführte Tabelle um.
• Der Single Point of Failure. Viele Organisationen bündeln ihr gesamtes CRM-Wissen bei einem einzigen Administrator. Wenn diese Person das Unternehmen verlässt, stellt man fest, dass niemand sonst versteht, warum die Automatisierung so funktioniert, wie sie funktioniert. Dokumentation und ein Partner, der das Architekturwissen gemeinsam mit Ihrem Team hält, sind die Absicherung.
• Konfigurationsdrift. Das System, das zum Zeitpunkt des Go-live perfekt auf das Unternehmen abgestimmt war, passt allmählich nicht mehr zum Unternehmen, weil es sich weiterentwickelt und kein Prozess zur Änderungskontrolle existiert. Konfigurationsdrift ist der Grund, warum CRMs, die gut implementiert wurden, drei Jahre später trotzdem das Vertrauen verloren haben. Governance ist keine Bürokratie; sie bewahrt den Wert der Go-live-Investition über die Zeit.

Was sind die Frühwarnsignale, dass Ihre Migration gefährdet ist?

Jedes der oben beschriebenen Fehlerbilder ist sichtbar, bevor es teuer wird. Wenn Sie eine Migration planen oder gerade durchführen, sind dies die Signale, die Sie eskalieren sollten; jedes einzelne entspricht einem Fehlerpunkt in diesem Artikel:

• Es gibt keinen namentlich benannten Executive Sponsor, der das Ergebnis verantwortet; das Projekt berichtet ausschließlich an die IT, wobei die kommerziellen Führungskräfte lediglich Stakeholder statt Verantwortliche sind.
• Das Datenaudit wurde übersprungen oder aufgeschoben („wir bereinigen die Daten im laufenden Projekt“).
• Der Plan für Akzeptanz und Nutzung passt auf eine einzige Folie und besteht hauptsächlich aus Schulungsterminen.
• Die Integrationsliste wächst weiter, nachdem der Projektumfang bereits festgelegt ist.
• Der Umstellungstermin wurde durch eine Vertragsverlängerung oder einen Kampagnenkalender bestimmt, nicht durch Bereitschaftskriterien.
• Niemand hat aufgeschrieben, was „Erfolg“ in Zahlen bedeutet, die der Vorstand anerkennen wird, sodass das Projekt nicht scheitern kann und daher auch nicht sichtbar erfolgreich sein kann.
• Es gibt keinen Plan für die zwei Wochen nach dem Go-live und keinen Verantwortlichen für das System nach Projektabschluss.

Wenn drei oder mehr dieser Signale vorliegen, ist es der ehrliche Schritt, innezuhalten und neu zu planen. Es ist weitaus günstiger, einen Umstellungstermin zu verschieben, als eine Plattform neu einzuführen, der Ihre Teams bereits beschlossen haben, nicht zu vertrauen.

Wie reduzieren Enterprise-Teams das Risiko einer CRM-Migration?

Die kurze Antwort: Behandeln Sie die Migration als ein geschäftliches Veränderungsprogramm mit einer technischen Komponente, nicht umgekehrt. In der Praxis teilen erfolgreiche Migrationen eine gemeinsame Struktur:

• Eine Discovery- und Datenaudit-Phase, bevor irgendetwas versprochen wird, damit Umfang, Integrationen und Datenentscheidungen bewusst getroffen werden, mit Fachverantwortlichen am Tisch.
• Ein stufenweiser Rollout mit definierten Bereitschaftskriterien für jede Phase, statt einer Big-Bang-Umstellung.
• Ein Arbeitsbereich für Akzeptanz und Nutzung mit demselben Status wie Daten und Integrationen, unterstützt von der kommerziellen Führungsebene, darauf ausgelegt, das neue System zum einfachsten Arbeitsweg zu machen.
• Eine Hypercare-Phase nach jedem Go-live, mit namentlich benannten Ansprechpersonen und schneller Reaktionszeit.
• Governance ab dem ersten Tag: dokumentierte Architektur, Änderungskontrolle und Datenverantwortung, die den Weggang einzelner Personen überdauern.

Die Partnerwahl ist hier von größerer Bedeutung, als die meisten Beschaffungsprozesse abbilden. Die Bewertungsfrage lautet nicht „Wer kann die Daten migrieren?“, denn nahezu jeder kann die Daten migrieren. Die Frage lautet: „Wer verfügt über die Governance, die Methodik und das Betreuungsmodell nach dem Go-live, damit die Veränderung Bestand hat?“

Das ist eine Frage der Prozessreife und Verantwortlichkeit, weshalb Nachweise wie ISO-zertifizierte Informationssicherheit und Qualitätsmanagement (ISO 27001:2022 und ISO 9001:2015), die Partnerstufe Triple Elite von HubSpot und Auszeichnungen wie HubSpot Global Partner of the Year 2024 bei einer Enterprise-Bewertung berücksichtigt werden sollten: Sie sind unabhängige Belege dafür, wie ein Partner Projekte durchführt, nicht nur dafür, ob er es kann.

Bei Huble werden Migrations- und Konsolidierungsprogramme genau auf diese Weise durchgeführt: Discovery-gesteuert, stufenweise, auf Akzeptanz und Nutzung ausgerichtet und mit Governance nach dem Go-live, die von Anfang an integriert statt nachträglich ergänzt wird.

Wenn Ihnen eines der Warnsignale in diesem Artikel bekannt vorkommt, lohnt sich das Gespräch vor dem Umstellungstermin, nicht danach.

Was ist der häufigste Grund für das Scheitern von CRM-Migrationen?

Fehlende Akzeptanz und Nutzung, dicht gefolgt von Datenproblemen. Die meisten gescheiterten Migrationen sind technisch „erfolgreich“: Die Daten wurden migriert, das System funktioniert, aber das Unternehmen hat nie seine Arbeitsweise geändert.

Teams arbeiten weiter in Tabellenkalkulationen, die Datenqualität verschlechtert sich, und innerhalb eines Jahres wird der neuen Plattform nicht mehr vertraut als der alten. Deshalb sollte die Förderung von Akzeptanz und Nutzung ein finanzierter Arbeitsbereich sein, nicht ein Posten im Schulungsbudget.

Wie viel Prozent der CRM-Projekte scheitern?

Veröffentlichte Misserfolgsquoten variieren enorm, von unter einem Drittel bis weit über die Hälfte, je nachdem, wie jede Studie „Scheitern“ definiert. Mehrere der am häufigsten zitierten Zahlen lassen sich nicht auf eine verifizierbare Quelle zurückverfolgen.

Die nützlichere Übung für ein Enterprise-Team ist nicht der Branchendurchschnitt, sondern die Identifikation der spezifischen Fehlerbilder: Daten ohne Audit migriert, zu wenig Ressourcen für Akzeptanz und Nutzung, Umfang spät entdeckt, Big-Bang-Umstellungen und fehlende Verantwortung nach dem Go-live.

Diese sind in Ihrem eigenen Projekt diagnostizierbar und vermeidbar, unabhängig davon, was die Schlagzeile besagt.

Sollten wir alle historischen Daten migrieren?

Mit hoher Wahrscheinlichkeit nicht alle. Der Ausgangspunkt sollte ein Datenaudit sein, das trennt, was das Unternehmen aktiv nutzt und worüber es berichtet, von dem, was es lediglich speichert. Aktiv genutzte Daten werden migriert und mit Fachverantwortlichen gemappt; historische Daten mit gelegentlichem Nutzen werden in einer zugänglichen Form archiviert; tatsächlich unbrauchbare Daten werden zurückgelassen.

Alles unterschiedslos zu migrieren importiert die Probleme des alten Systems in das neue und verlangsamt jede Phase des Projekts.

Wer sollte eine CRM-Migration intern verantworten?

Ein namentlich benannter Executive Sponsor von der kommerziellen Seite des Unternehmens, typischerweise der CRO, CMO oder COO, je nachdem, wo der Schwerpunkt der Plattform liegt, unterstützt von einer funktionsübergreifenden Arbeitsgruppe aus Vertrieb, Marketing, Kundenservice, Finanzen und IT.

Migrationen, die allein von der IT verantwortet werden, neigen dazu, technisch zu gelingen und kommerziell zu scheitern, weil die Entscheidungen, die Akzeptanz und Nutzung bestimmen, geschäftliche Entscheidungen sind.

Wie lange dauert eine Enterprise-CRM-Migration?

Monate, nicht Wochen. Die ehrliche Antwort ist, dass der Zeitplan durch die Datenkomplexität, die Integrationslandschaft und das Tempo des organisatorischen Wandels bestimmt wird, weit mehr als durch das Volumen der Datensätze.

Ein stufenweiser Ansatz mit Bereitschaftskriterien pro Phase wird im Hinblick auf die gesamte Zeit bis zur Wertschöpfung fast immer schneller sein als ein ambitionierter einzelner Umstellungstermin, weil er die verlängerte Erholungsphase vermeidet, die auf einen überstürzten Go-live folgt.

Ist es sicherer, einfach beim aktuellen CRM zu bleiben?

Beim Status quo zu bleiben fühlt sich sicher an, weil die Kosten vertraut sind, aber sie sind real: Verlängerungspreise für eine Plattform, der Sie entwachsen sind, administrativer Aufwand, den Ihr Team täglich trägt, Berichte, denen der Vorstand nicht mehr vertraut, und nach Akquisitionen die kumulierenden Kosten für den Betrieb paralleler Systeme.

Das Risiko einer Migration ist konzentriert und mit der richtigen Struktur beherrschbar; das Risiko des Status quo ist diffus und wächst jedes Jahr. Der richtige Vergleich ist nicht „Migrationsrisiko versus kein Risiko“, sondern „beherrschtes Risiko jetzt versus unbeherrschtes Risiko auf unbestimmte Zeit“.