Brownfield-CRM-Migrationen: Wie Sie eine HubSpot- oder Salesforce-Instanz übernehmen, ohne deren technische Schulden zu erben

Die meisten Teams, die von einer „CRM-Migration" sprechen, führen in Wahrheit gar keine Re-Plattformierung durch. Sie übernehmen eine HubSpot- oder Salesforce-Instanz, die jemand anderes gebaut, nie vollständig dokumentiert und dann zusammen mit den Quartalsumsatzzahlen übergeben hat. Die Instanz funktioniert, knapp, und das operative Modell ist nun durch sie eingeschränkt. Das ist eine Brownfield-CRM-Migration. Sie ist eine andere Projektkategorie als eine saubere Neuinstallation, und das Gegenteil zu behaupten ist der teuerste Fehler, den Sie in den ersten dreißig Tagen machen können.

Warum das jetzt wichtig ist

Die Wechselkosten bei CRMs sind nicht mehr das, was sie einmal waren. Wie Jason Lemkin im April formulierte: Bei zwei oder drei AI-Agenten ist ein CRM-Wechsel lästig; bei zehn ist er teuer; bei zwanzig ist er funktional unmöglich. Das System, das Sie heute tolerieren, ist das System, an das Sie für die nächste Agenten-Generation gebunden sein werden. Der Februar-Beitrag der Harvard Business Review darüber, warum digitale Investitionen keinen Wert schaffen, deutet aus einem anderen Blickwinkel auf dieselbe Ursache, Das Versagen liegt nicht im Tooling. Es liegt im Versäumnis, neu zu gestalten, wie die Vertriebsorganisation tatsächlich Erkenntnisse generiert, Entscheidungen trifft und Handlungen koordiniert. Eine Brownfield-Migration ist in der Praxis der Moment, in dem diese Neugestaltung entweder stattfindet oder für weitere zwei Jahre verschoben wird.

Die Brownfield-Regel: Es gibt keinen sauberen Schnitt, bauen Sie das Audit, bevor Sie die Architektur bauen

Eine Greenfield-Migration beginnt mit einem leeren Schema. Sie entscheiden, welche Objekte existieren, welche Felder auf ihnen liegen, welche Verknüpfungen erlaubt sind, was die Pipeline-Stages bedeuten. Eine Brownfield-Migration beginnt mit mehreren Jahren von Entscheidungen anderer, die in ein laufendes Umsatzsystem eingebrannt sind. Die meisten dieser Entscheidungen ergaben damals Sinn und tun es heute nicht mehr. Einige waren nie gut durchdacht. Eine überraschende Anzahl stellt sich als tragend heraus, in einer Weise, die niemand dokumentiert hat.

Die Regel, an der wir jedes Brownfield-Engagement messen, lautet, Verändern Sie nichts an der Datenarchitektur, bevor Sie nicht jede bestehende Entscheidung triagiert haben. Die Triage ist nicht optional, und die Triage ist das Projekt. Die Re-Plattformierung ist nur das, was am Ende passiert.

Das Keep / Edit / Delete-Framework

Für jeden bestehenden Datenpunkt, jedes bestehende Feld, jede bestehende Pipeline-Stage, jede bestehende Automatisierung, jeden bestehenden Report gibt es eine von drei Antworten:

1. Keep. Es dient weiterhin einem aktuellen kommerziellen Anwendungsfall. Es bedarf keiner Überarbeitung. Es ist dokumentiert, korrekt verdrahtet, und seine Entfernung würde einen Downstream-Report oder Workflow brechen, den jemand aktiv nutzt.
2. Edit. Es dient einem aktuellen Anwendungsfall, aber die Implementierung ist falsch, der Datentyp ist falsch, die Werte sind inkonsistent oder der Workflow ist teilweise kaputt. Edits werden umrissen, mit Namen versehen und vor jeder Zusammenführung terminiert.
3. Delete. Es diente einem Anwendungsfall, den es nicht mehr gibt, wurde nie verwendet oder dupliziert etwas anderes. Deletes werden auf Downstream-Auswirkungen geprüft und dann entfernt.

Das Framework wirkt auf dem Papier leichtgewichtig. Die Kosten liegen in der Disziplin. Jede Property, jeder Workflow, jeder Record-Type durchläuft die drei Buckets. Eine typische HubSpot-Instanz eines B2B-SaaS-Unternehmens in der Mid-Stage trägt zwischen mehreren Hundert und mehreren Tausend einzelne Triage-Entscheidungen. Das Team, das sagt „wir finden das schon unterwegs heraus", ist das Team, das die Migration mit den Schulden im Gepäck ausliefert.

Wo das Framework konkret wird

Drei Stellen, an denen sich das Keep / Edit / Delete-Framework in der Praxis schnell schärft:

Pipeline-Stages und ihre Definitionen

Die meisten übernommenen Pipelines haben Stages, die für verschiedene Personen Verschiedenes bedeuten. „Closed Won" heißt manchmal Vertrag unterzeichnet; manchmal Kickoff geplant; manchmal Umsatz realisiert. Die Migration ist der Moment, die Definition zu erzwingen. Edit, nicht Delete, aber jede Stage erhält eine ein-Satz-Definition, ein Eintrittskriterium, ein Austrittskriterium und einen Owner.

Custom Properties auf Deal, Contact, Company

Brownfield-Instanzen sammeln Custom Properties ungefähr in der Geschwindigkeit an, in der das Team Ideen sammelt. Ein ernsthaftes Audit löscht in der Regel 30–50 % davon. Die diagnostische Frage für jede einzelne, Wer hat sie in den letzten 90 Tagen gelesen, und welche Entscheidung wurde daraus getroffen? Wenn die Antwort niemand und nichts ist, dann weg damit.

Workflows und Automatisierungen

Die mit Abstand häufigste Quelle von Brownfield-Schulden sind Workflows, die auf veraltete Trigger feuern, Felder setzen, die niemand nutzt, oder ehemalige Mitarbeitende benachrichtigen. Jeder Workflow wird Ende-zu-Ende gelesen, sein Endzustand kartiert und triagiert. Workflows, die überleben, werden nach einer Konvention umbenannt; der Rest wird vor jeder Datenbewegung pausiert.

Muster aus der Praxis

Ein B2B-SaaS-Team aus dem DACH-Raum in Series B kam kürzlich mit zwei HubSpot-Portalen und einer Salesforce-Instanz auf uns zu, die in ein einziges System zusammengeführt werden mussten. Der Instinkt war Re-Plattformierung: alles übertragen, in ein neues Portal kippen, in acht Wochen liefern. Die tatsächliche Projektform nach der Triage sah anders aus. Etwa 38 % der Legacy Custom Properties wurden im ersten Audit-Durchlauf zur Löschung markiert. Weitere 24 % brauchten Edits, Typänderungen, Konsolidierung von Auswahllisten, Workflow-Verdrahtung. Die verbleibenden 38 % blieben unverändert. Die zusammengeführte Instanz ging mit etwa einem Drittel der Custom-Property-Oberfläche der kombinierten Legacy-Systeme live, und das erste Quartal an Reporting darauf war das erste seit zwei Jahren, das keinen manuellen Pre-Pull-Cleanup-Schritt brauchte. Die Migration war nicht die Speed-to-Platform, die wir initial geplant hatten. Sie war die Aufräumarbeit.

Auflösung, ein Brownfield-Migrations-Playbook

Für jedes Team, das gleich eine HubSpot- oder Salesforce-Instanz übernimmt oder zusammenführt:

1. Frieren Sie die Architektur ein. Keine neuen Properties, keine neuen Workflows, keine neuen Pipeline-Stages, bevor das Audit nicht abgeschlossen ist. Das Audit dauert länger, wenn Sie ständig Oberfläche hinzufügen.
2. Führen Sie den Keep / Edit / Delete-Durchlauf auf jedes Objekt durch. Properties, Pipelines, Workflows, Record-Types, Listen-Mitgliedschaften, Verknüpfungs-Labels. Dokumentieren Sie die Entscheidung in einem Spreadsheet, das jemand bereit ist zu verteidigen.
3. Gleichen Sie gegen das System ab, das tatsächlich Umsatz treibt. Wenn Sie Daten in zwei Systemen haben, behandeln Sie eines als Source of Truth und passen das andere daran an. Die Migration ist nicht der Moment, um zu debattieren, welches System gewinnt.
4. Reparieren Sie die Workflows, bevor Sie die Daten bewegen. Brownfield-Daten oben auf übernommener Automatisierung sind das Schlechteste aus beiden Welten. Pausieren Sie jede Automatisierung, die eine Property anfasst, die Sie editieren oder löschen; schreiben Sie die Überlebenden gegen das Post-Audit-Schema neu.
5. Inszenieren Sie die Zusammenführung in einer Sandbox. Produktionsmigrationen werden zuerst in der Sandbox getestet, gegen einen echten Reporting-Workload validiert und erst dann terminiert.
6. Schulen Sie auf das Post-Audit-System, nicht auf das Legacy-System. Eine Brownfield-Migration ist eine Verhaltensänderung für das Team. Dokumentation, die gegen das Legacy-System geschrieben ist, zementiert die Legacy-Schulden.

Wenn Sie Schritte eins bis sechs befolgen, ist die eigentliche Datenmigration ein Freitagnachmittag. Wenn Sie sie überspringen, ist die Migration die nächsten zwölf Monate.

Wo Checkpoint ins Spiel kommt

Der Grund, warum das Keep / Edit / Delete-Framework unter Druck standhält, ist, dass es kein Methodik-Poster ist, es ist die Arbeit. Brownfield-Migrationen machen den Großteil der CRM-Arbeit aus, die wir bei Checkpoint machen, und wir haben den Audit-Zyklus auf genug HubSpot-, Salesforce- und Pipedrive-Übernahmen durchlaufen, um zu wissen, welche Entscheidungen jedes Mal auftauchen und welche tatsächlich einzigartig für Ihren Stack sind. Wenn Ihre Brownfield-Migration aus übernommenen Schulden statt einem leeren Schema startet, sprechen Sie mit uns, bevor Sie die Plattform wählen, die richtige Plattform-Entscheidung fällt aus dem Audit heraus, nicht umgekehrt.

Quellen

• Sinha, Shastri, Lorimer. „Why Your Digital Investments Aren't Creating Value." Harvard Business Review, 16. Februar 2026. hbr.org
• Lemkin, Jason. „Which CRM Should You Use in 2026/2027? Follow the Agents." SaaStr, 6. April 2026. saastr.com