Microsoft Dynamics zu HubSpot migrieren

Warum kommt der künftige HubSpot-Prozess vor dem Dynamics-Datenmodell?

Kopierst du zuerst die Dynamics-Objekte, baust du die alte Komplexität nach und nicht den Prozess, den du künftig brauchst. Deshalb dokumentierst du als Erstes den HubSpot-Zielprozess: Lifecycle-Übergänge, Pipeline-Zuordnung und die Frage, wem welcher Umsatz gehört. Erst danach ordnest du die Dynamics-Daten dort ein.

Sechs Fragen entscheiden über die künftige Struktur, bevor du ein einziges Feld mappst: Wann wird ein Contact zum Lead? Wann wird ein Lead zum Deal? Zu welcher Pipeline gehören bestehende Verträge? Wie steuerst du Verlängerungen? Welches Objekt trägt die Wahrheit über den Umsatz? Welche Teams brauchen Zugriff auf welche Information?

Das Prinzip dahinter passt in einen Satz: Erst entwirfst du das Betriebsmodell in HubSpot, dann mappst du die Dynamics-Daten hinein. Nicht umgekehrt.

Überspringst du diesen Schritt, übernimmst du jeden Workaround, den Dynamics je angesammelt hat. Ein Rabattfeld, das 2021 für einen einzelnen Deal angelegt wurde, wird zur Standard-Property. Ein Vertragstyp, dessen Zweck niemand mehr kennt, wird zur Pipeline-Stage. Das neue CRM trägt dann dieselben gewachsenen Ausnahmen wie das alte, nur mit anderen Feldnamen.

Welche Dynamics-Objekte gehören überhaupt ins Migrations-Inventar?

In einem typischen Dynamics-Environment steht dieselbe Information an mehreren Stellen, und die Objekte überlappen sich teilweise. Die Stammdaten liegen in Accounts, Contacts und Verkaufschancen. Das Kommerzielle steckt in Orders, Contracts, Licenses und Products. Dazu kommen Notes, Activities und Attachments. Vor jedem Mapping klärst du deshalb, welches Objekt für welche Tatsache die eigentliche Quelle ist.

In der Praxis liegt die Information über wiederkehrende Umsätze selten an einem sauberen Ort. Meist verteilt sie sich über Verkaufschancen, Contracts, Orders und Lizenz-Datensätze, oft mit unterschiedlichem Stand. Deshalb ist die Frage nach der Quelle die wichtigste Vorarbeit und keine Formsache.

• Die Firmenidentität kommt in der Regel aus dem Account.
• Der kommerzielle Kontext, also wer wann was verkauft hat, steckt in der Verkaufschance.
• Die Vertragslaufzeit steht im Contract-Objekt, nicht im Deal.
• Den aktuellen wiederkehrenden Preis findest du im License-Datensatz, oft von Hand nachgepflegt.
• Die rechtliche Dokumentation bleibt häufig in SharePoint oder als angehängtes PDF liegen.

Das Risiko ist die Überlappung selbst, nicht ein einzelnes Objekt. Ein Beispiel: Jemand ändert den Verlängerungsbetrag im Lizenz-Datensatz, nachdem die Verkaufschance schon geschlossen ist. Dann stehen zwei Zahlen im System, und beide wirken massgeblich. Baust du das Migrations-Mapping, entscheide dich deshalb bewusst und schriftlich für eine Quelle. Sonst entscheidet der letzte Export, welche Zahl gewinnt.

Wie klassifizierst du Migrationsdaten, bevor du sie mappst?

Nicht alles, was in Dynamics steht, muss nach HubSpot. Vier Kategorien trennen, was du migrierst, von dem, was du nur dokumentierst: operative Daten fürs Tagesgeschäft, Reporting-Daten für Dashboards, historische Referenzdaten für den Kontext und rechtliche Archivdaten für die Nachweispflicht. Jede Kategorie verlangt einen anderen Detailgrad.

Historische Referenzdaten verdienen Kontext, aber selten einen eigenen HubSpot-Datensatz. Baust du sie als natives Objekt nach, kostet das Aufwand, und später berichtet trotzdem kein Team danach.

Wie mappst du die Standard-CRM-Objekte zwischen Dynamics und HubSpot?

Die meisten Objekte ziehen direkt um: Aus dem Account wird die Company, der Contact bleibt ein Contact, und die Verkaufschance wird zum Deal. Die Ausnahme sind Verträge und Lizenzen. Dort triffst du eine bewusste Entscheidung statt eines automatischen 1:1-Mappings, weil HubSpot Verträge anders modelliert als Dynamics.

HubSpots eigenes Contracts-Objekt kann bestehende Verträge importieren und mit Line Items, Contacts und Deals verknüpfen. Zwei Einschränkungen gehören dazu. Die Funktion gibt es erst ab Revenue Hub Professional oder Enterprise. Und sie ist auf HubSpot-eigene Quotes und Deal-Verknüpfungen ausgerichtet, nicht auf eine 1:1-Kopie der Dynamics-Vertragshistorie.

Warum braucht jeder migrierte Datensatz seine Dynamics-ID als Property?

Ohne stabile externe Kennung bleibt jede Verknüpfung zwischen migrierten Objekten fragil. Deshalb bekommt jedes importierte Objekt ein eigenes Legacy-ID-Feld: Company und Contact, Deal, Contract und License. Für Vertragshierarchien kommt eine Parent-Contract-ID dazu, damit zusammengehörige Verträge verknüpft bleiben.

Diese Kennungen lösen ein konkretes, wiederkehrendes Problem: Namen sind keine zuverlässige Verknüpfungsbasis. Zwei Firmen können gleich heissen, und ein Kontakt kann mehrfach mit leicht unterschiedlicher Schreibweise importiert werden. Eine stabile ID verhindert genau das und bringt dir vier Dinge:

• Contacts landen auch nach mehreren Import-Durchläufen bei der richtigen Company.
• Lizenzen finden ihren ursprünglichen Deal, ohne dass jemand von Hand nachsucht.
• Spätere Updates laufen durch, ohne Duplikate zu erzeugen.
• Fehlgeschlagene Imports bleiben nachvollziehbar, weil du sie mit dem Dynamics-Export abgleichen kannst.

Die Faustregel dahinter: Verknüpf nie allein über Namen. Stabile externe Kennungen sind die einzige verlässliche Basis für Assoziationen.

Welches Modell bildet bestehende Verträge in HubSpot am besten ab?

Welches Modell passt, hängt davon ab, wofür dein Team den Vertrag im Alltag braucht. Drei stehen zur Wahl: Du führst den Vertrag als Deal oder als eigenes Custom Object. Oder er bleibt als rechtliches Dokument extern, und nur die Kennzahlen wandern nach HubSpot. Keine Option ist immer richtig, es entscheidet der konkrete Anwendungsfall.

Bei Modell C reichen wenige Felder, damit du trotzdem arbeitsfähig bleibst. Für den Vertrag selbst sind das Contract-URL, Vertragsbeginn und Vertragsende. Für die Steuerung kommen automatische Verlängerung, Kündigungsfrist, aktueller Jahreswert und nächstes Billing-Datum dazu.

Eine einfache Faustregel entscheidet schneller als ein Workshop. Geht es vor allem um Verlängerungserinnerungen und Pipeline-Sichtbarkeit, reicht der Deal. Braucht Legal oder Finance ein eigenes Contract-Reporting unabhängig von der Sales-Pipeline, rechtfertigt das den Mehraufwand des Custom Objects. Und hat bisher niemand nach Contract-Reporting in HubSpot gefragt, baust du nichts auf Vorrat. Dann reicht der Link zum Dokument.

Wie werden aus wiederkehrenden Lizenzen HubSpot Line Items?

Lizenzen brauchen eine klare Zuordnung, sonst wächst die Produktbibliothek unkontrolliert. Ein aktiver Vertrag oder Verlängerungsfall wird zum Deal. Jede einzelne Lizenzkomponente wird zu einem eigenen, verknüpften Line Item, und jeder individuelle Preispunkt zu einer eigenen Produktvariante. Vorrang hat dabei der aktuelle Preis, nicht die vollständige Rekonstruktion der Historie.

Die Trennung dahinter ist bewusst: Produktdefinitionen gehören in die Produktbibliothek, kundenspezifische kommerzielle Werte auf das Line Item. Vermischst du beides, baust du dir eine Produktbibliothek voller Einzelfälle. Auf jedes Line Item gehören diese Angaben:

• Name, SKU und Produktbeschreibung.
• Produkttyp und Modul.
• Menge, Einzelpreis und Abrechnungsfrequenz.
• Abrechnungsbeginn, Laufzeit und Vertragsende.
• Währung, Rabatt und Produktkategorie.
• Legacy Product ID und Parent Deal ID für die Rückverfolgung.

An dieser Stelle lohnt ein Blick auf stille Duplikate in der Produktbibliothek. Die Versuchung ist gross, für jeden Altpreis, der nicht ganz zu einem bestehenden Produkt passt, eine neue SKU anzulegen. So wird aus „ein Produkt, mehrere Preise“ unbemerkt „ein Produkt pro je berechnetem Altpreis“. Ein Rabatt oder eine Einzelanpassung gehört ins Rabattfeld des Line Items, nicht in eine neue Produktvariante.

Warum solltest du nicht jede historische Preisänderung nachbauen?

Ein Altvertrag enthält oft mehrere Preiserhöhungen, individuelle Rabatte, Rundungsanpassungen und uneinheitlich benannte Produkte. Technisch liesse sich jede Periode als eigenes Line Item rekonstruieren. Praktisch entstehen dabei hunderte Datensätze und unübersichtliche Deal-Ansichten, und für das Reporting bringt es kaum etwas.

Pragmatischer ist ein anderer Weg. Du migrierst den aktuellen aktiven Preis und bewahrst den unterschriebenen Vertrag oder die Preishistorie als Dokument auf. Zusätzliche historische Datensätze legst du nur dort an, wo eine konkrete Reporting-Anforderung das rechtfertigt.

Was gilt als Quelle der Wahrheit für Deal Amount und ARR?

Nach einer Migration reden Sales und Finance oft über denselben Umsatz und meinen verschiedene Zahlen. In HubSpot stecken sechs unterschiedliche Grössen: Total Contract Value und ARR, Rechnungsbetrag und realisierter Umsatz, Einmalumsatz und aktueller wiederkehrender Wert. Je nach Abrechnungsfrequenz, Laufzeit, Line-Item-Konfiguration und Deal-Stage kann HubSpot sie unterschiedlich berechnen.

Hier schaffen Governance-Properties Eindeutigkeit, statt die Verwirrung stillschweigend weiterzureichen. Für die Umsatzseite sind das aktueller ARR, Einmalumsatz und Gesamtvertragswert. Für die Zeitachse kommen ARR-Start- und Enddatum, nächstes Billing-Datum und Vertragsende dazu. Und fürs Reporting brauchst du eine Umsatzquelle und eine ARR-Reporting-Kategorie.

Zwei Deals mit demselben Gesamtvertragswert können einen unterschiedlichen ARR tragen, allein weil einer jährlich und der andere quartalsweise mit anderer Laufzeit abgerechnet wird. Ohne vereinbarte ARR-Property berichtet Sales eine Zahl und Finance eine andere. Beide sind technisch korrekt, sie beantworten nur verschiedene Fragen unter demselben Namen.

Wo liegen die echten Reporting-Grenzen von HubSpot bei wiederkehrendem Umsatz?

Eng wird es bei der periodengerechten Umsatzrealisierung über mehrere Geschäftsjahre hinweg. Dafür brauchst du zusätzliche Werkzeuge. Stark ist HubSpot dagegen bei Pipeline-Reporting und deal-basiertem Umsatz, bei Produkt- und Line-Item-Analysen, beim Forecast und beim aktuellen wiederkehrenden Wert.

Ein Beispiel: Ein zwölfmonatiger Rechnungsbetrag, der im Juli beginnt, muss für die Finanzberichterstattung häufig auf zwei Geschäftsjahre aufgeteilt werden. Das folgt einer anderen Logik als reines Deal- oder Rechnungs-Reporting. Je nach Setup löst du das mit Sales-Hub-Enterprise-Recurring-Revenue-Properties oder mit Data Hub und eigenem Code. Die Alternativen sind eine externe Berechnung in Excel oder Google Sheets, eine BI-Plattform oder eine ERP-Integration. HubSpots eigene ARR-Definition zeigt schon auf Begriffsebene, wie viele einzelne Annahmen in dieser einen Kennzahl stecken.

Eine Unterscheidung solltest du ausdrücklich benennen: gebuchter und realisierter Umsatz. Ein Deal kann am Tag des Abschlusses vollständig gebucht werden, während die Buchhaltung denselben Umsatz monatsweise über die Vertragslaufzeit realisiert. HubSpot bildet das kommerzielle Ereignis gut ab, ist aber kein Buchhaltungssystem. Setzt du Deal-Close-Reporting mit realisiertem Umsatz gleich, ist das nach Migrationen eine häufige Quelle für Reibung zwischen Finance und Sales.

In welcher Reihenfolge läuft der Import ab?

Importierst du in der falschen Reihenfolge, fehlen Assoziationen oder es entstehen Duplikate. Deshalb gilt eine feste Phasenfolge. Erst bereinigst du die Quelldaten und legst die Properties an. Dann folgen Companies und Contacts samt ihren Verknüpfungen, danach Produkte, Deals und Line Items. Notizen, Validierung, Tests und Schulung kommen ganz am Schluss.

1. Bereinige und vereinheitliche die Quelldaten.
2. Leg die benötigten HubSpot-Properties an.
3. Importier die Companies.
4. Importier die Contacts.
5. Stell die Assoziationen her.
6. Importier die Produkte.
7. Importier die Deals.
8. Importier die Line Items.
9. Verknüpf die Line Items mit den Deals.
10. Importier Notizen und Dokument-Links.
11. Validiere Summen und Datensatzzahlen.
12. Teste die Verlängerungs- und Rechnungsprozesse.
13. Schule dein Team.
14. Archivier Quelldateien und Mapping-Dokumentation.

Wie validierst du die Migration vor dem Go-live?

Stimmen die Datensatzzahlen, weisst du nur, dass etwas importiert wurde. Ob es auch funktioniert, zeigen erst repräsentative Geschäftsfälle. Nimm dir einen Kunden mit einer Lizenz und einen Vertrag mit mehreren Modulen vor. Dazu eine automatische Verlängerung, eine feste Laufzeit und einen Deal mit wiederkehrenden und einmaligen Komponenten.

• Erkennt dein Team den aktuellen wiederkehrenden Betrag?
• Lässt sich die nächste Rechnung vorbereiten?
• Ist das Verlängerungsdatum sichtbar?
• Öffnet sich das Vertragsdokument?
• Ist die richtige Company verknüpft?
• Sind alle aktuellen Lizenzen sichtbar?
• Lassen sich ARR und Pipeline berichten?
• Lässt sich der Datensatz aktualisieren, ohne Dynamics zu öffnen?

Welche Governance hält HubSpot nach der Migration sauber?

Steuert nach dem Go-live niemand gegen, schleicht sich die alte Komplexität langsam zurück. Die Migration ist deshalb kein einmaliges Projekt, sondern der Startpunkt für laufende Datenpflege. Dagegen helfen Pflichtfelder je Pipeline-Stage, kontrollierte Produktnamen, dokumentierte Custom Properties und eine klare Verantwortung für jedes Objekt.

• Leg Pflichtfelder je Pipeline-Stage fest.
• Verhindere doppelte Produkte mit kontrollierten Namen und SKUs.
• Dokumentiere alle Custom Properties.
• Weise für jedes Objekt klar zu, wem es gehört.
• Leg fest, wer neue Produkte anlegen darf.
• Führ Regeln für Vertragsänderungen ein.
• Trenn aktuelle und historische Werte konsequent.
• Leg gespeicherte Ansichten für fehlende Daten an.
• Auditiere die Importe, bevor du das Altsystem abschaltest.

Governance entscheidet, ob die Disziplin der Migration den ersten hektischen Deal übersteht. Ohne sie legt der erste Vertriebsmitarbeiter, der das passende Produkt nicht findet, einfach ein neues an, statt nachzufragen. Ein halbes Jahr später sieht das saubere Datenmodell dann genauso aus wie das abgelöste Dynamics-Environment, nur jünger.

Für dich heisst das: erst klassifizieren, dann mappen. Der kleinste zuverlässige Datensatz gewinnt gegen die vollständigste Kopie. Deine Migration muss Sales und Verlängerungen tragen, dazu Rechnungsstellung, Reporting und künftiges Wachstum. Dafür braucht sie nicht jedes Dynamics-Objekt, sondern die richtigen.