Wieso scheitern CRM-Migrationen?
Aus der Innensicht eines Maklerbüros wirkt eine CRM-Migration wie ein „Daten exportieren, Daten importieren, fertig"-Projekt. In der Realität sind es drei Migrationen gleichzeitig — und alle drei müssen gelingen, sonst wird die Umstellung als Fehlschlag wahrgenommen:
- Datenmigration — Estates, Adressen, Verknüpfungen, Anhänge, Verlauf.
- Prozess-Migration — die in das alte System eingeübten Workflows auf das neue System abbilden, oft mit anderer Logik (z. B. Aufgaben-Modul, Termin-Verknüpfungen).
- Mensch-Migration — Mitarbeitende, die jahrelang im alten Tool waren, müssen in 4-8 Wochen das neue Tool beherrschen und ihm vertrauen.
Die meisten gescheiterten Migrationen sind technische Erfolge, aber Mensch-Misserfolge. Ein sauberes Playbook plant alle drei Migrationen explizit ein.
Phase 0 — Entscheidung: Wechseln oder optimieren?
Bevor du eine Migration anfasst, prüfe ehrlich, ob das aktuelle CRM wirklich das Problem ist — oder ob ein paar Workflow- und Schulungs-Optimierungen den Schmerz beheben. Wir haben Kunden, die nach einer Workflow-Beratung gar nicht mehr migrieren wollten.
Wechsel ist sinnvoll, wenn:
- das alte System eine zentrale Schwäche hat, die nicht durch Workflow-Anpassungen lösbar ist (z. B. fehlende API, fehlende Mobile-Apps, fehlende Multi-Office-Struktur),
- der Vendor selbst Probleme macht (Support-Qualität, Pricing-Erhöhungen, Strategiewechsel),
- eine Akquisition oder Fusion zwei verschiedene Systeme auf einem konsolidieren soll,
- ihr in eine neue Größenklasse wachst (Single-Office → Multi-Office, regional → DACH-weit, deutsch → international).
Wechsel ist riskant, wenn:
- das alte System „nur" schlecht konfiguriert ist — das überträgt sich oft auf das neue,
- der Hauptgrund eine einzelne fehlende Funktion ist, die als Modul oder über eine API-Integration nachgerüstet werden kann,
- du in den nächsten 12 Monaten ohnehin Personalumbrüche oder andere große Veränderungen geplant hast.
Eine ehrliche Vor-Migration-Frage: Wenn die nächste Marktphase (Hochzins, schwankendes Inventar) drei Monate Produktivitäts-Dip nicht erlaubt — verschiebe den Wechsel und mach erst ein Workflow-Audit. Eine Migration ist nicht zeitkritisch, ein gutes Quartal schon.
Phase 1 — Inventory & Field-Mapping
Hier entscheidet sich die Migration. Bevor irgendein Skript läuft, brauchst du eine vollständige Kartierung beider Systeme:
- Daten-Inventar aus dem Quell-System: Wie viele Estates, Adressen, Aufgaben, Termine, Dokumente, Beziehungen, Notizen? Welche sind aktiv, welche archiviert?
- Feld-Inventar: Welche Standard- und Custom-Felder sind im Quell-System belegt, welche werden tatsächlich genutzt, welche enthalten nur Altdaten?
- Workflow-Inventar: Welche Automatisierungen laufen im Quell-System (E-Mail-Sequenzen, Dokumenten-Vorlagen, Erinnerungs-Tasks)? Welche müssen in das neue System abgebildet werden?
- Integrations-Inventar: Welche externen Tools (E-Mail, Portale, Buchhaltung) hängen am Quell-System? Müssen sie umgehängt werden?
Aus diesen vier Inventaren wächst die Mapping-Tabelle — pro Feld im Quell-System die Zuordnung im Ziel-System, inklusive Datentyp-Konvertierungen und Enum-Übersetzungen. In den Mappings stecken die meisten Stolpersteine:
- Enum-Werte heißen in jedem System anders — „gepflegt" vs. „WELL_KEPT" vs. „good".
- Multi-Wert-Felder wie Ausstattungs-Listen müssen aufgespalten oder zusammengefasst werden.
- Verknüpfungen wie Eigentümer-Beziehungen brauchen oft eine andere Modellierung (in OnOffice: separates Relation-Modul; in Propstack: Felder am Property direkt).
- Custom-Felder die im Quell-System mit Excel-Logik gefüllt wurden, müssen im Ziel-System neu validiert werden.
Phase 2 — Pilot-Migration
Niemals direkt mit dem kompletten Bestand starten. Wir migrieren immer zuerst eine repräsentative Stichprobe:
- 10-20 Estates aus verschiedenen Kategorien (Wohnung, Haus, Gewerbe, Grundstück),
- 20-30 verknüpfte Adressen (Eigentümer, Interessenten),
- 3-5 Dokument-Workflows,
- einen vollständigen Beispiel-Mandanten falls Multi-Office.
Diese Pilot-Migration läuft in eine Sandbox-Instanz des Ziel-Systems. Mitarbeitende aus Vertrieb, Backoffice und IT testen 1-2 Wochen lang: Sind alle Felder richtig zugeordnet? Funktionieren die typischen Tagesgeschäft-Workflows? Sind Berechtigungen korrekt? Tauchen unerwartete Drift-Effekte auf?
Jede gefundene Abweichung wird im Mapping-Doc verzeichnet — nicht „beim nächsten Mal merken", sondern systematisch fixiert. Erst wenn das Pilot-Set fehlerfrei in der Sandbox liegt, geht der Vollbestand in die nächste Phase.
Phase 3 — Cut-Over
Der Cut-Over ist der Tag, an dem operativ aufs neue System umgestellt wird. Die wichtigste Entscheidung: Big-Bang oder Parallel-Betrieb?
Stichtag-Migration in 1-2 Tagen
- Wochenende oder Brückentag wählen.
- Quell-System am Stichtag eingefroren, finale Migration läuft.
- Montag morgen: alle starten im neuen System.
Vorteil: Klare Trennung, kein Daten-Drift zwischen zwei Systemen. Nachteil: Wenn etwas schief geht, ist die ganze Belegschaft betroffen.
Wochen-Übergang mit Daten-Sync
- Pilot-Team startet im neuen System.
- Eine Bridge synchronisiert Änderungen zwischen den Systemen.
- Schrittweises Onboarding aller Mitarbeitenden.
Vorteil: Risiko-arm, fehlerverzeihend. Nachteil: Mehr Aufwand für die Bridge, höhere Komplexität. Bei zwei Wochen Parallel-Betrieb deutlich höhere Migrations-Kosten.
Unsere Empfehlung: Single-Office-Büros mit weniger als 10 Mitarbeitenden fahren mit Big-Bang gut. Multi-Office oder Büros mit kritischem Tagesgeschäft (z. B. live in Verhandlungen mit Käufern) sollten Parallel-Betrieb mit Sync planen.
Phase 4 — Post-Migration & Stabilisierung
Die ersten zwei bis vier Wochen nach Cut-Over sind kritisch. Drei Aktivitäten sind nicht-verhandelbar:
- Daily Standup mit Vertrieb, Backoffice und IT — jede Anomalie sofort eskalieren.
- Reconciliation-Reports — automatischer Abgleich zwischen den Estate-Listen und Adressen-Beständen beider Systeme. Drift-Effekte (Felder die nicht durchkopiert wurden, Verknüpfungen die brachen) müssen aktiv gesucht werden.
- User-Coaching — die typischen „in OnOffice war das anders"-Fragen werden zu einer FAQ und in Schulungs-Sessions adressiert.
Erst nach 4-8 Wochen ohne kritische Findings wird das alte System endgültig stillgelegt. Die Lizenzen für das Quell-System lieber 2-3 Monate länger laufen lassen als sofort kündigen — der Backup-Zugriff hat sich oft bezahlt gemacht.
Tooling-Empfehlungen
Eine CRM-Migration kommt ohne eigene Skripte nicht aus. Drei Tooling-Bausteine, die wir konsequent einsetzen:
1. Migration-Pipeline mit Node.js + Postgres
Statt direkt Quell-API → Ziel-API zu pumpen, schalten wir eine Zwischendatenbank dazwischen. Das Quell-System wird in eine normalisierte Schema-Form gezogen, alle Mappings werden dort ausgeführt, dann wird ins Ziel-System geschrieben. Vorteil: Wenn der Cut-Over fehlschlägt oder wiederholt werden muss, ist die Mittelschicht der konsistente Quell-of-Truth. Die Multi-System-Sync-Patterns, die wir in unserer eigenen Jobflare-Plattform für ATS-Bridges einsetzen, übertragen wir 1:1 auf CRM-Migrationen.
2. Idempotente Schreib-Operationen
Jedes Schreib-Skript muss wiederholbar sein, ohne Duplikate zu erzeugen. Wir verlassen uns dabei auf externe Referenz-IDs (Propstack-ID als externalReference in Idealista, objektnr_extern in OnOffice). So kann ein abgebrochener Migrations-Lauf einfach neu gestartet werden.
3. Reconciliation-Dashboard
Nach jedem Lauf läuft eine Reconciliation-Schicht, die zählt: Wie viele Estates im Quell-System? Wie viele im Ziel? Welche fehlen? Welche haben unterschiedliche Pflichtfelder? Das Ergebnis landet in einem internen Dashboard, das die IT- und Vertriebsleitung jeden Morgen prüft.
Die acht häufigsten Fehler
- Unterschätzung der Mapping-Phase. Wer Mapping in der Hälfte der Zeit schaffen will, die wir empfehlen, baut Daten-Müll auf.
- Migration ohne Pilot. Direkt mit dem Vollbestand zu starten ist die häufigste Fehler-Quelle.
- Fehlende DSGVO-Diligenz. Adressen mit fehlendem Opt-In im Ziel-System landen — direkt rechtliches Risiko.
- Verknüpfungen vergessen. Estates und Adressen einzeln migrieren, aber die Beziehungs-Tabelle vergessen. Anschließend ist nichts mehr verknüpft.
- Dokumente und Bilder zuletzt. Anhänge werden „später" eingespielt. „Später" wird nie. Bilder müssen Teil des ersten Pilot-Sets sein.
- Kein Recovery-Plan. Wenn am Cut-Over-Wochenende eine Migration fehlschlägt, fehlt der Rollback-Plan.
- Mitarbeitende erst am Cut-Over involvieren. Resultat: Ablehnung, nicht Adoption. Schulungen müssen 2-4 Wochen vor Cut-Over starten.
- Quell-System sofort kündigen. Die Lizenz noch 2-3 Monate weiterlaufen lassen ist günstig versus die Alternative, in einer Krise keinen Zugang mehr zu haben.
Wie lange dauert es realistisch?
Eine ehrliche Daumenregel aus unseren Projekten:
- Single-Office, ≤ 5 Mitarbeiter, ≤ 500 Estates: 6-10 Wochen Projektlaufzeit, 15-30k Euro Gesamt-Aufwand.
- Mittel, 6-15 Mitarbeiter, 500-3.000 Estates: 3-5 Monate, 30-60k Euro.
- Multi-Office / Franchise, 15+ Mitarbeiter, 3.000+ Estates: 6-9 Monate, 60-150k Euro inklusive Beratung, Custom-Bridge-Entwicklung und Coaching.
Wer eine Migration unterhalb dieser Zahlen anbietet, lässt entweder die DSGVO-Compliance, das Mapping oder die Mensch-Migration weg. Alle drei kommen später als noch teurere Folgekosten zurück.
Wir bei DevNest begleiten CRM-Migrationen zwischen Propstack, OnOffice, FlowFact und kundeneigenen Systemen — von der Entscheidungsberatung über die technische Umsetzung bis zur Reconciliation-Phase. Wenn du ein Migrations-Projekt vor dir hast: lass uns 30 Minuten reden, oft hilft das mehr als ein Vendor-Pitch. Projekt anfragen oder mehr zu unserer Propstack-Entwicklung und Immobilien-CRM-Beratung.
Weitere Themen: Propstack vs OnOffice vs FlowFact · OnOffice-API anbinden · Propstack-Webhooks zu Portalen pushen · Jobflare — Multi-Tenant-SaaS-Showcase