Microsoft Dynamics zu HubSpot migrieren

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

Wer zuerst die Dynamics-Objekte kopiert, baut die alte Komplexität nach, nicht den künftigen Prozess. Der erste Schritt ist deshalb, den HubSpot-Zielprozess zu dokumentieren – Lifecycle-Übergänge, offene Verkaufschancen-Zuordnung, Revenue-Eigentümerschaft – und Dynamics-Daten erst danach hineinzuordnen.

Sechs Fragen entscheiden über die künftige Struktur, bevor ein einziges Feld gemappt wird: Wann wird ein Contact zum Lead? Wann wird ein Lead zum Deal? Welcher offene Verkaufschancen gehören bestehende Verträge? Wie werden Verlängerungen gesteuert? Welches Objekt trägt die Umsatzwahrheit? Welche Teams brauchen Zugriff auf welche Information?

Das dahinterliegende Prinzip lässt sich in einem Satz zusammenfassen: Das HubSpot-Betriebsmodell wird zuerst entworfen. Dynamics-Daten werden danach hineingemappt – nicht umgekehrt.

Wer diesen Schritt überspringt, übernimmt 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 offene Verkaufschancen-Stage. Das neue CRM trägt dieselben gewachsenen Ausnahmen wie das alte – nur mit anderen Feldnamen.

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

Ein typisches Dynamics-Environment verteilt dieselbe Information über mehrere, teils überlappende Objekte: Accounts, Contacts, Opportunities, Orders, Contracts, Licenses, Products, Notes, Activities und Attachments. Vor jedem Mapping steht die Frage, welches Objekt für welche Tatsache die eigentliche Quelle ist.

In der Praxis liegt Recurring-Revenue-Information selten an einem sauberen Ort. Sie verteilt sich über Opportunities, Contracts, Orders und Lizenz-Datensätze – oft mit unterschiedlichem Stand. Genau das macht die Quellenfrage zur wichtigsten Vorarbeit, nicht zur Formsache.

• Die Firmenidentität kommt in der Regel aus dem Account.
• Der kommerzielle Kontext – wer hat wann was verkauft – steckt in der Opportunity.
• Die Vertragslaufzeit steht im Contract-Objekt, nicht im Deal.
• Der aktuelle wiederkehrende Preis liegt im License-Datensatz, oft manuell nachgepflegt.
• Rechtliche Dokumentation bleibt häufig in SharePoint oder als angehängtes PDF liegen.

Die Überlappung selbst ist das Risiko, nicht ein einzelnes Objekt. Wird der Verlängerungsbetrag im Lizenz-Datensatz geändert, nachdem die Opportunity schon geschlossen ist, stehen zwei Zahlen im System, die beide massgeblich wirken. Wer das Migrations-Mapping baut, muss sich bewusst und schriftlich für eine Quelle entscheiden – nicht dem letzten Export überlassen, welche gewinnt.

Wie werden Migrationsdaten klassifiziert, bevor sie gemappt werden?

Vier Kategorien trennen, was migriert werden muss, von dem, was nur dokumentiert werden sollte: operative Daten fürs Tagesgeschäft, Reporting-Daten für Dashboards, historische Referenzdaten für Kontext und rechtliche Archivdaten für die Nachweispflicht. Jede Kategorie verlangt einen anderen Detailgrad.

Historische Referenzdaten verdienen Kontext, aber selten einen eigenen HubSpot-Datensatz. Sie als natives Objekt nachzubauen kostet Aufwand, ohne dass ein Team später danach berichtet.

Wie werden Standard-CRM-Objekte zwischen Dynamics und HubSpot gemappt?

Die meisten Objekte lassen sich direkt übertragen – Account zu Company, Contact zu Contact, Opportunity zu Deal. Vertrags- und Lizenzobjekte sind die Ausnahme: Sie brauchen eine bewusste Entscheidung, kein automatisches 1:1-Mapping, 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 – die Funktion steht allerdings erst ab Revenue Hub Professional oder Enterprise zur Verfügung und bleibt strukturell auf HubSpot-eigene Quotes und Deal-Verknüpfungen ausgerichtet, nicht auf eine 1:1-Kopie der Dynamics-Vertragshistorie.

Wieso braucht jeder migrierte Datensatz eine eigene Dynamics-ID als Property?

Ohne eine stabile externe Kennung bleibt jede Verknüpfung zwischen migrierten Objekten fragil. Jedes importierte Objekt bekommt deshalb sein eigenes Legacy-ID-Feld – Company, Contact, Deal, Contract, License, plus eine Parent-Contract-ID für Hierarchien.

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

• Sie verknüpft Contacts korrekt mit ihrer Company, auch nach mehreren Import-Durchläufen.
• Sie ordnet Lizenzen ihrem ursprünglichen Deal zu, ohne manuelles Nachsuchen.
• Sie macht spätere Updates möglich, ohne Duplikate zu erzeugen.
• Sie macht fehlgeschlagene Imports nachvollziehbar und mit dem Dynamics-Export abgleichbar.

Die Faustregel dahinter: Nie allein über Namen verknüpfen. Stabile externe Kennungen sind die einzige verlässliche Basis für Assoziationen.

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

Drei Modelle stehen zur Wahl, je nach Nutzungsschwerpunkt: der Vertrag wird als Deal geführt, als eigenes Custom Object, oder er bleibt als rechtliches Dokument extern und nur Kennzahlen wandern nach HubSpot. Keine Option ist grundsätzlich richtig – die Entscheidung folgt dem tatsächlichen Anwendungsfall.

Bei Modell C reichen wenige Felder, um trotzdem arbeitsfähig zu bleiben: Contract-URL, Vertragsbeginn, Vertragsende, automatische Verlängerung, Kündigungsfrist, aktueller Jahreswert und nächstes Billing-Datum.

Eine einfache Faustregel entscheidet schneller als ein Workshop: Geht es hauptsächlich um Verlängerungserinnerungen und offene Verkaufschancen-Sichtbarkeit, reicht der Deal. Braucht Legal oder Finance eigenständiges Contract-Reporting unabhängig von der Sales-offene Verkaufschancen, rechtfertigt das den Mehraufwand des Custom Objects. Hat bisher niemand nach Contract-Reporting in HubSpot gefragt, wird nichts auf Vorrat gebaut – dann reicht der Link zum Dokument.

Wie werden wiederkehrende Lizenzen zu HubSpot Line Items?

Ein aktiver Vertrag oder Verlängerungsfall wird zu einem Deal. Jede einzelne Lizenzkomponente wird zu einem eigenen, verknüpften Line Item. Jeder individuelle Preispunkt wird zu einer eigenen Produktvariante – mit Priorität auf dem aktuellen Preis, nicht auf der vollständigen historischen Rekonstruktion.

Die Trennung dahinter ist bewusst: Produktdefinitionen gehören in die Produktbibliothek, kundenspezifische kommerzielle Werte gehören auf das Line Item. Wer das vermischt, baut sich eine Produktbibliothek voller Einzelfälle.

• 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. Es ist verlockend, für jeden Altpreis, der nicht ganz zu einem bestehenden Produkt passt, eine neue SKU anzulegen – aus "ein Produkt, mehrere Preise" wird so unbemerkt "ein Produkt pro je berechnetem Altpreis". Ein Rabatt oder eine Einzelanpassung gehört ins Rabattfeld des Line Items, nicht in eine neue Produktvariante.

Wieso sollte nicht jede historische Preisänderung nachgebaut werden?

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, unübersichtliche Deal-Ansichten und kaum Reporting-Nutzen.

Der pragmatischere Weg: den aktuellen aktiven Preis migrieren, den unterschriebenen Vertrag oder die Preishistorie als Dokument aufbewahren, und zusätzliche historische Datensätze nur dort anlegen, wo eine konkrete Reporting-Anforderung das rechtfertigt.

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

Total Contract Value, wiederkehrender Jahresumsatz, Rechnungsbetrag, realisierter Umsatz, Einmalumsatz und aktueller wiederkehrender Wert sind sechs unterschiedliche Grössen, die in HubSpot je nach Abrechnungsfrequenz, Laufzeit, Line-Item-Konfiguration und Deal-Stage unterschiedlich berechnet werden können.

Governance-Properties schaffen hier Eindeutigkeit, statt die Verwirrung stillschweigend weiterzureichen: aktueller wiederkehrender Jahresumsatz, Einmalumsatz, Gesamtvertragswert, wiederkehrender Jahresumsatz-Start- und Enddatum, nächstes Billing-Datum, Vertragsende, Umsatzquelle und eine wiederkehrender Jahresumsatz-Reporting-Kategorie.

Zwei Deals mit demselben Gesamtvertragswert können einen unterschiedlichen wiederkehrender Jahresumsatz tragen, allein weil einer jährlich und der andere quartalsweise mit anderer Laufzeit abgerechnet wird. Ohne eine vereinbarte wiederkehrender Jahresumsatz-Property berichtet Sales eine Zahl, Finance eine andere – beide technisch korrekt, beide beantworten nur eine andere Frage unter demselben Namen.

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

HubSpot ist stark bei offene Verkaufschancen-Reporting, deal-basiertem Umsatz, Produkt- und Line-Item-Analyse, verlässliche Umsatzprognose und aktuellem wiederkehrendem Wert. Komplexe periodengerechte Umsatzrealisierung über mehrere Geschäftsjahre hinweg braucht dagegen zusätzliche Werkzeuge.

Ein zwölfmonatiger Rechnungsbetrag, der im Juli beginnt, muss für die Finanzberichterstattung häufig auf zwei Geschäftsjahre aufgeteilt werden – eine andere Logik als reines Deal- oder Rechnungs-Reporting. Für solche Fälle braucht es je nach Setup Sales-Hub-Enterprise-Recurring-Revenue-Properties, Data Hub mit eigenem Code, externe Berechnung in Excel oder Google Sheets, eine BI-Plattform oder eine ERP-Integration. HubSpots eigene wiederkehrender Jahresumsatz-Definition zeigt schon auf Begriffsebene, wie viele einzelne Annahmen in dieser einen Kennzahl stecken.

Die Unterscheidung, die es explizit zu benennen lohnt: gebuchter versus realisierter Umsatz. Ein Deal kann am Tag des Abschlusses vollständig gebucht werden, während die Buchhaltung denselben Umsatz über die Vertragslaufzeit monatsweise realisiert. HubSpot bildet das kommerzielle Ereignis gut ab – es ist kein Buchhaltungssystem, und Deal-Close-Reporting mit realisiertem Umsatz gleichzusetzen, ist nach Migrationen eine häufige Quelle für Reibung zwischen Finance und Sales.

In welcher Reihenfolge sollte der Import tatsächlich ablaufen?

Eine feste Phasenfolge verhindert, dass Assoziationen fehlen oder Duplikate entstehen: erst Quelldaten bereinigen, dann Properties anlegen, dann Companies, Contacts, Verknüpfungen, Produkte, Deals, Line Items – erst danach Notizen, Validierung, Tests und Schulung.

1. Quelldaten bereinigen und vereinheitlichen.
2. Benötigte HubSpot-Properties anlegen.
3. Companies importieren.
4. Contacts importieren.
5. Assoziationen herstellen.
6. Produkte importieren.
7. Deals importieren.
8. Line Items importieren.
9. Line Items mit Deals verknüpfen.
10. Notizen und Dokument-Links importieren.
11. Summen und Datensatzzahlen validieren.
12. Verlängerungs- und Rechnungsprozesse testen.
13. Nutzer schulen.
14. Quelldateien und Mapping-Dokumentation archivieren.

Wie wird die Migration vor dem Go-live wirklich validiert?

Reine Datensatzzahlen bestätigen nur, dass etwas importiert wurde – nicht, dass es funktioniert. Repräsentative Geschäftsfälle zeigen das: ein Kunde mit einer Lizenz, ein Vertrag mit mehreren Modulen, eine automatische Verlängerung, eine feste Laufzeit, wiederkehrende und einmalige Komponenten im selben Deal.

• Erkennt der Nutzer 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?
• Lässt sich wiederkehrender Jahresumsatz und offene Verkaufschancen berichten?
• Lässt sich der Datensatz aktualisieren, ohne Dynamics zu öffnen?

Welche Governance hält HubSpot nach der Migration sauber?

Migration ist kein einmaliges Projekt, sondern der Startpunkt für laufende Datenpflege. Pflichtfelder je offene Verkaufschancen-Stage, kontrollierte Produktnamen, dokumentierte Custom Properties und klare Objekt-Eigentümerschaft verhindern, dass sich die alte Komplexität langsam zurückschleicht.

• Pflichtfelder je offene Verkaufschancen-Stage definieren.
• Doppelte Produkte verhindern, kontrollierte Namen und SKUs nutzen.
• Alle Custom Properties dokumentieren.
• Objekt-Eigentümerschaft klar zuweisen.
• Festlegen, wer neue Produkte anlegen darf.
• Regeln für Vertragsänderungen etablieren.
• Aktuelle und historische Werte konsequent trennen.
• Gespeicherte Ansichten für fehlende Daten anlegen.
• Importe vor der Abschaltung des Altsystems auditieren.

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 – und ein halbes Jahr später sieht das saubere Datenmodell genauso aus wie das abgelöste Dynamics-Environment, nur jünger.

Der kleinste zuverlässige Datensatz gewinnt gegen die vollständigste Kopie: Eine Migration, die Sales, Verlängerungen, Rechnungsstellung, Reporting und künftiges Wachstum trägt, braucht nicht jedes Dynamics-Objekt – sie braucht die richtigen.