CRM-Go-live: der Dry Run, der findet, was Ihr Projektplan übersieht

Die meisten CRM-Migrationen werden als Aufgabenliste gemanagt. Daten mappen, Workflows bauen, Schulungen terminieren, ein Launch-Datum wählen. Die Liste wird grün, jemand erklärt das Projekt für abgeschlossen, und am Morgen des Go-live loggt sich das kundennahe Team in ein System ein, das niemand durchgängig benutzt hat. Genau dann zeigen sich die Lücken, in der Produktion, mit echten Kunden in den Datensätzen.

Das Problem: Eine Aufgabenliste bestätigt, dass die Arbeit erledigt ist. Sie bestätigt nicht, dass der Ablauf funktioniert. Ein Workflow kann gebaut sein und trotzdem beim falschen Trigger feuern. Eine Property kann gemappt sein und trotzdem in einem View landen, den der Rep nie öffnet. Eine Pipeline kann konfiguriert sein und trotzdem keinen Weg von der Stage haben, in die ein Lead eintritt, bis zu der Stage, in der ein Deal gewonnen wird. Nichts davon steht im Status-Sheet. Es zeigt sich beim ersten Mal, wenn ein echter Datensatz die ganze Journey durchlaufen will, und wenn dieses erste Mal Ihr Go-live ist, debuggen Sie Revenue-Infrastruktur, während Ihre Leute darauf verkaufen sollen.

Früher gab es im System Puffer, um einen holprigen Launch aufzufangen. Ein paar Leute haben die kaputten Workflows eine Woche lang gelöscht, der Admin hat live nachgebessert, und das Team hat sich in die Adoption gehangelt. Dieses Polster ist weitgehend weg. SaaStrs GTM-Analyse 2026 zeigt: Das Medianunternehmen plant null Prozent RevOps-Headcount-Wachstum in diesem Jahr, mit GTM-Orgs, die 20 bis 30 Prozent schlanker und deutlich flacher sind als früher. Die Leute, die einen missglückten Cutover früher aufgefangen haben, gibt es im Org-Chart nicht mehr.

Auch auf der anderen Seite ist mehr im Spiel. Sie haben nicht viele Versuche. Wie SaaStr in seinem Beitrag 2026 zum CRM-Lock-in schreibt, ist die Migration meist „zu schmerzhaft, um sie zu rechtfertigen“, ein zweites Mal zu machen, und je mehr Agents und Automatisierungen Sie auf dem CRM verdrahten, desto mehr wird der Wechsel von lästig zu „faktisch unmöglich“. Der CRM-Go-live ist fast eine Einbahnstraße. Der Dry Run sorgt dafür, dass die Tür in den richtigen Raum führt.

Hier ist die Unterscheidung, die ich in jeden Migrationsplan einbrennen würde. Es gibt zwei Arten der Bestätigung, und Teams sammeln routinemäßig die erste und überspringen die zweite.

Die erste ist die Aufgaben-Bestätigung: Die Daten sind gemappt, die Workflows gebaut, die Views konfiguriert, das Schulungs-Deck geschrieben. Das ist notwendig, und das verfolgt Ihr Projektplan. Die zweite ist die Ablauf-Bestätigung: Ein echter Datensatz, der dort startet, wo ein echter Kunde starten würde, kommt bis zum gewonnenen Deal durch, und jede Stage, Property, jeder Workflow und View, den er unterwegs berührt, tut, was er soll. Für die zweite plant fast niemand Zeit ein. Sie ist die günstigste Absicherung, die Sie vor einem CRM-Go-live kaufen können, und sie ist der Schritt, den man streicht, wenn das Launch-Datum eng wird.

Ein Dry Run ist keine Demo und kein UAT in einer Sandbox, in der der Admin die Happy Paths durchklickt. Er ist eine getaktete, durchgängige Generalprobe der gesamten Customer Journey in dem System, das Sie launchen wollen, durchgeführt von den Personen, die jeden Teil verantworten, mit gezieltem Blick darauf, was bricht.

Was ich empfehle: Blocken Sie zwei Stunden, legen Sie einen Datensatz auf den Bildschirm und führen Sie ihn vor dem ganzen Team vom ersten Kontakt bis zum gewonnenen Deal. Ein Lead kommt rein. Landet er in der richtigen Pipeline? Feuert der Workflow, der feuern soll, tatsächlich? Wenn der Rep den Contact öffnet, sieht er denselben View wie sein Kollege, oder gibt es fünf verschiedene Layouts, sodass niemand auf dieselben Daten schaut? Wenn der Deal eine Stage weiterzieht, wird die nächste Aktion erzeugt? Wenn er gewonnen wird, triggert die Übergabe an Onboarding oder Service? Sie testen nicht, ob die Teile existieren. Sie testen, ob die Teile zusammenhängen.

Der Grund, es live, gemeinsam und laut zu machen: Die Lücken liegen in den Nahtstellen zwischen der Arbeit verschiedener Personen. Die Person, die den Lead-Routing-Workflow gebaut hat, und die Person, die die Deal-Stages gebaut hat, haben jeweils ihr eigenes Teil isoliert getestet, und jedes Teil hat bestanden. Die Journey kreuzt beide, und der Bruch sitzt fast immer an der Naht. Sie sehen die Naht nur, wenn ein Datensatz das Ganze in einer Sitzung durchläuft.

Wir haben kürzlich mit einem Series-B-B2B-SaaS-Unternehmen in der DACH-Region gearbeitet, das von Salesforce auf HubSpot umstieg, mit einem festen Go-live-Datum und einem kundennahen Team, das das neue Setup noch nie angefasst hatte. Der Projektplan war in gutem Zustand: Daten-Mapping gescoped, Workflows gebaut, Schulung terminiert.

Aus dem Beharren auf einem Dry Run vor dem Cutover kamen zwei Dinge. Erstens: Als wir einen Datensatz durch die Journey führten, waren mehrere Workflows isoliert korrekt gebaut, aber nie mit dem Trigger verdrahtet, den die tatsächliche Customer Journey erzeugt, sodass ein Contact eintreten und einfach ohne nächsten Schritt liegen bleiben konnte. Ein Status-Sheet hätte diese Workflows als „erledigt“ gezeigt. Der Dry Run zeigte sie als Sackgassen. Zweitens: Das Team hatte nicht geplant, historische Notizen und Aktivitäten aus dem alten System zu migrieren, nur offene Datensätze. Das klingt vernünftig, bis man merkt, dass ein Rep an Tag eins einen aktiven Account übernimmt, keine Historie sieht und stillschweigend das alte CRM in einem zweiten Tab öffnet, um sie zu finden. In dem Moment, in dem Ihre Leute das Altsystem offen halten, ist die Adoption schon verloren, und Sie zahlen für zwei CRMs, um eines zu betreiben. Wir haben beides vor dem Launch erwischt, weil wir die Journey durchgespielt haben, nicht die Checkliste.

1. Buchen Sie den Dry Run als eigenes Event, vor dem Go-live. Zwei Stunden, das ganze Team, im Kalender als Working Session, nicht als Status-Call. Steht er nicht mit klarem Owner im Kalender, wird er vom Launch-Datum verdrängt. Behandeln Sie ihn als Gate, das der Go-live bestehen muss, nicht als Nice-to-have.
2. Führen Sie einen echten Datensatz vom ersten Kontakt bis zum gewonnenen Deal. Wählen Sie ein repräsentatives Szenario und folgen Sie ihm den ganzen Weg: Lead-Erstellung, Routing, Qualifizierung, jede Stage, der Abschluss und die Übergabe nach dem Abschluss. Springen Sie nicht zum interessanten Teil. In den langweiligen Übergängen verstecken sich die Sackgassen.
3. Testen Sie die Nahtstellen, nicht die Einzelteile. Fragen Sie an jeder Übergabe, ob das Nächste feuert: der Workflow, die Aufgabe, die Benachrichtigung, der View-Wechsel, die Zuweisung. Die einzelnen Objekte wurden bereits von dem getestet, der sie gebaut hat. Ihre Aufgabe im Dry Run sind die Verbindungen dazwischen.
4. Migrieren Sie die Historie, nicht nur offene Datensätze. Entscheiden Sie explizit, welche Kundenhistorie mitkommt: Notizen, vergangene Aktivitäten, vorheriger Kontext. Können Reps nicht sehen, was vor dem Go-live war, halten sie das alte System offen, und das ist der schnellste Weg, die Adoption zu verlieren. Wenn Sie nicht alles mitnehmen können, nehmen Sie genug mit, damit kein Rep einen Grund hat, das alte CRM erneut zu öffnen.
5. Standardisieren Sie die Views vor dem Launch, nicht danach. Ein gemeinsamer, rollengerechter View, damit alle dieselben Daten sehen, wenn sie einen Datensatz teilen. Meine Regel: Ändern Sie den View danach, wo der Datensatz in seinem Lifecycle steht, nicht danach, wer ihn ansieht. Ein Contact, bevor er Kunde ist, sollte anders aussehen als ein Contact, der Kunde ist. Fünf persönliche Layouts an Tag eins heißen fünf Leute, die in Woche eins aneinander vorbeireden.
6. Schreiben Sie die Dokumentation aus der funktionierenden Version. Nehmen Sie den Dry Run auf und bauen Sie den User Guide aus dem Ablauf, den Sie gerade bestätigt haben, mit Screen Grabs der echten Schritte. Dokumentation, die vor der Bestätigung des Systems geschrieben wird, dokumentiert ein System, das es noch nicht gibt.
7. Legen Sie den Dry Run früh in den Tag und buchen Sie die Fix-Zeit danach. Gehen Sie davon aus, dass der Dry Run Lücken findet, denn das wird er, und dass einige neue Workflows brauchen. Führen Sie ihn am Morgen durch, damit die Person, die nachbessern muss, noch den Nachmittag hat. Ein Dry Run ohne danach gebuchte Fix-Zeit ist nur eine Liste von Problemen, die Sie jetzt kennen und vor dem Launch nicht lösen können.

Sie brauchen kein formelles Programm dafür. Sie brauchen zwei Stunden, einen Datensatz, die richtigen Leute im Raum und die Disziplin, der ganzen Journey zu folgen statt nur den Teilen, bei denen Sie sich sicher sind. Der Dry Run ist der Unterschied zwischen Lücken finden in einer terminierten Working Session eine Woche vor dem Launch und Lücken finden in der Produktion mit einem Kunden in der Leitung. Das eine ist günstig. Das andere kostet Sie den Go-live und ein Stück Ihrer Adoption.

Wenn Sie einen CRM-Go-live planen und einen Partner wollen, der den Dry Run vor dem Cutover durchführt, ist das genau die Art von Arbeit, die wir machen: die Migration scopen, die Workflows verdrahten und die gesamte Customer Journey proben, bevor jemand darauf verkaufen muss. Lesen Sie den begleitenden Beitrag über die CRM-Adoption-Lücke, die sich nach dem Launch öffnet, oder sehen Sie, wie wir Revenue Operations end to end angehen.

• SaaStr. „The Modern GTM Org in 2026: Leaner, Flatter, and More Revenue Per Rep.“ SaaStr, Januar 2026. saastr.com
• SaaStr. „Which CRM Should You Use in 2026/2027? Follow the Agents.“ SaaStr, Februar 2026. saastr.com