.svg)
Kurz gesagt:
- Eine erfolgreiche Intercom-Migration folgt der Reihenfolge Kontakte zuerst, dann Attribute und schließlich Konversationen oder Tickets. Eine sorgfältige Planung inklusive Rollenverteilung, Tests und einem validen Rollback-Plan ist essenziell, um Fehler zu vermeiden. Fehlende Agenten, aktivierte Benachrichtigungen und falsche Reihenfolge führen häufig zu Problemen im Projekt.
Die effektivste Reihenfolge für eine Intercom-Datenmigration lautet: zuerst Kontakte importieren, dann benutzerdefinierte Attribute anlegen, danach Konversationen oder Tickets importieren. Wer diese Reihenfolge umdreht, bekommt fehlgeschlagene Importe. Kein Workaround, keine Ausnahme.
Bevor du den ersten Export startest, klär diese sechs Punkte:
Admin-Zugänge prüfen: Du brauchst Admin-Rechte in Zendesk und in Intercom.
Agenten vorab anlegen: Intercom hat keinen API-Agenten-Creator. Fehlende Agenten bedeuten, alle Tickets landen beim migrierenden Admin.
E-Mail-Benachrichtigungen abschalten: Sonst erhalten Kunden Benachrichtigungen zu Tickets aus der Vergangenheit.
Delta-Datum festlegen: Definiere einen festen Zeitpunkt, bis zu dem geschlossene Tickets migriert werden.
Conversation vs. Ticket entscheiden: Diese Wahl beeinflusst API-Endpunkte und Skript-Logik.
Message-by-message vermeiden: Nachricht-für-Nachricht-Import erhöht die API-Last um das 10- bis 100-Fache. Transkripte oder zusammengefasste Antworten sind die bessere Wahl.
Backup sichern: Vor jedem Lauf ein vollständiges Backup des Quellsystems.
Eine strukturierte Vorbereitung spart später Stunden. Diese zehn Schritte sind die Grundlage:
Profi-Tipp: Entscheide Conversation vs. Ticket vor dem Mapping, nicht danach. Wer das Skript erst schreibt und dann umschwenkt, fängt von vorne an.
Vollimport oder selektiver Import? Das Zendesk-Importtool von Intercom unterstützt keine Teilimporte. Entweder alles oder nichts. Wer nur einen Teil migrieren will, braucht die API.
Gute Migrationen scheitern selten an der Technik. Sie scheitern an unklaren Verantwortlichkeiten und fehlenden Rollback-Kriterien.
Projektrollen:
Scope-Checkliste:
Rollback-Kriterien: Brich den Cutover ab, wenn mehr als 5 % der Datensätze fehlschlagen, wenn Agenten-Zuordnungen systematisch falsch sind oder wenn E-Mail-Benachrichtigungen trotz Deaktivierung ausgelöst werden. Halte das Quellsystem mindestens 3–6 Monate im Lesezugriff.
Das Mapping ist der technisch kritischste Schritt. Fehler hier erzeugen Duplikate oder stille Datenverluste.
Reihenfolge zwingend einhalten: Kontakte zuerst, dann Attribute anlegen, dann Konversationen oder Tickets importieren. Wer Tickets vor Kontakten importiert, bekommt Fehler.
| Quellfeld (Zendesk) | Typ | Zielobjekt (Intercom) | Beispielwert | Transformationsregel |
|---|---|---|---|---|
requester_id |
Integer | Contact (user_id) |
— | Auf Intercom-Kontakt-ID mappen nach Kontakt-Import |
organization_id |
Integer | Company | — | Zuerst Companies importieren |
created_at |
Timestamp | Conversation created_at |
— | ISO 8601 beibehalten |
status |
Enum | Ticket State | solved → resolved |
Automatisches State-Mapping |
custom_field_multiselect |
Array | Custom Attribute (String) | ["A","B"] → "A, B" |
Zu kommagetrentem String flatten |
subject |
String | Conversation/Ticket Titel | „Rechnungsfrage März“ | Direkt übernehmen |
Pflichtfelder: Jeder Kontakt braucht mindestens eine user_id oder eine E-Mail-Adresse. Fehlt beides, schlägt der Import fehl.
Multiselect-Felder aus Zendesk lassen sich nicht direkt in Intercom importieren, weil Intercom nur Einzelwerte unterstützt. Werte müssen vor dem Import zu einem kommagetrennten String zusammengeführt werden, was die Filterfähigkeit einschränkt.
Diese Entscheidung beeinflusst API-Endpunkte und Skript-Logik grundlegend. Triff sie vor dem ersten Skript.
Kurzfassung:
| Kriterium | Conversation | Ticket |
|---|---|---|
| SLA-Tracking | Eingeschränkt | Vollständig |
| Sichtbar für Kunden | Ja (Messenger) | Konfigurierbar |
| Benutzerdefinierte Attribute | Gesprächsattribute | Ticket-Typ-Attribute |
| API-Endpunkte | Create/Update/Reply conversation | Create/Update/Reply ticket |
| Skript-Komplexität | Geringer | Höher |
| Reporting-Tiefe | Basis | Detailliert |
Eine Mischung beider Modelle ist möglich, erhöht aber die Skript-Komplexität erheblich. Wer sowohl Conversations als auch Tickets migriert, braucht separate Importskripte für jede Struktur. Halte die Anzahl der verschiedenen Strukturen so gering wie möglich.
Faustregel: Zendesk-Tickets, die Kunden-Support-Interaktionen waren, werden zu Conversations. Strukturierte interne Aufgaben werden zu Tickets.
Für Migrationen mit überschaubarem Ticketvolumen und ohne Teilimport-Bedarf reicht das native Zendesk-Importtool von Intercom. Bei größeren oder komplexeren Anforderungen ist die API der empfohlene Weg.
Wann CSV genügt:
Wann die API nötig ist:
Typische Zendesk-Exportfelder via API: ticket_id, requester_id, organization_id, created_at, updated_at, status, subject, comments, tags, custom_fields. Anhänge sind separate Objekte und müssen einzeln abgerufen werden. Zendesk-Anhang-URLs werden ungültig, sobald das Zendesk-Konto deaktiviert ist. Deshalb: Anhänge vor dem Cutover in einen eigenen Cloud-Speicher (S3 oder Google Cloud Storage) übertragen.
Exportiere aus Zendesk immer mit Prüfsummen oder Stichproben-Checks. Vergleiche die Gesamtzahl der exportierten Tickets mit der Anzahl in Zendesk, bevor du den Import startest. Eine größere Abweichung ist ein Stopp-Signal.
Profi-Tipp: Zendesk-Multiselect-Felder und Lookup-Felder lassen sich nicht direkt in Intercom importieren. Flatten sie bereits beim Export zu kommagetrennten Strings, nicht erst im Transformationsskript. Das spart einen Durchlauf.
Intercom bietet drei Wege: CSV-Import, das native Zendesk-Importtool und die API. Jeder hat seinen Platz.
CSV-Import: Geeignet für Kontakte und einfache Datensätze. Kein Scripting nötig, aber keine Unterstützung für Konversationen oder Tickets.
Natives Zendesk-Importtool: Unter Einstellungen > Daten > Importe & Exporte > „Import from Zendesk“. Importiert Users, Companies und Tickets automatisch mit Feld-Mapping. Limit: unter 150.000 Tickets, keine Teilimporte.
API-Import: Volle Kontrolle, volle Komplexität. Notwendig für große Datenmengen, Deltas und komplexe Transformationen.
Wichtige API-Endpunkte in der richtigen Reihenfolge:
POST /contacts (Users und Leads anlegen)POST /companies (Companies anlegen)PUT /contacts/:id/companies (Verknüpfung herstellen)POST /conversations oder POST /tickets (Konversationen oder Tickets anlegen)POST /conversations/:id/reply (Antworten hinzufügen)Rate-Limits sind real. Intercom drosselt API-Anfragen. Plane Batch-Größen von 50–100 Datensätzen pro Anfrage und implementiere einen exponentiellen Backoff bei 429-Fehlern. Wer das ignoriert, blockiert sich selbst mitten im Import.
E-Mail-Benachrichtigungen müssen vor jedem Import deaktiviert sein. Das native Tool pausiert Benachrichtigungen automatisch, aber bei API-Importen musst du das manuell sicherstellen. Alle importierten geschlossenen Tickets durchlaufen intern den Zustandswechsel offen → geschlossen, was aktive Workflows triggert.
Rohdaten aus Zendesk passen selten direkt in Intercom. Transformationsskripte sind kein Luxus, sondern Pflicht.
Typische Transformationsschritte:
external_id (Zendesk User-ID), sekundär über E-Mail. Reihenfolge im Skript festlegen.migrated_from_zendesk versehen. Erleichtert spätere Filterung und Validierung.Skript-Sequenz:
Profi-Tipp: Vermeide Nachricht-für-Nachricht-Import. Importiere stattdessen ein zusammengefasstes Transkript als einzelne Notiz. Das reduziert API-Aufrufe drastisch und hält die Datenbank schlank. Nur wenn du den vollständigen Gesprächskontext für aktive Support-Fälle brauchst, lohnt sich der Mehraufwand.
Kein Produktionslauf ohne UAT. Das ist keine Empfehlung, das ist eine Regel.
UAT-Ablauf:
UAT-Checkliste:
Abbruchkriterien für Testläufe: Mehr als 5 % Fehlerrate, systematische Fehler bei einem Feldtyp oder fehlende Agenten-Zuordnung bei mehr als 10 Datensätzen. Dokumentiere jeden Abbruch und die Ursache im Run Book. Das sind die wertvollsten Einträge für zukünftige Migrationen.
Der Cutover ist der riskanteste Moment der Migration. Ein klarer Plan verhindert Chaos.
Cutover-Optionen:
Empfohlener Ablauf:
Rollback-Kriterien: Mehr als 5 % Fehlerrate im Delta-Run, Agenten-Zuordnung systematisch falsch, oder Kunden-Benachrichtigungen trotz Deaktivierung. Kommuniziere Rollback-Entscheidungen sofort an alle Stakeholder.
Profi-Tipp: Plane den Cutover für einen Dienstag oder Mittwoch, nie für einen Freitag. Wenn etwas schiefläuft, willst du ein vollständiges Team zur Verfügung haben.
Validierung ist kein einmaliger Check, sondern ein strukturierter Prozess.
| Prüfpunkt | Methode | Erwartetes Ergebnis |
|---|---|---|
| Benutzeranzahl | CSV-Export aus Intercom vs. Zendesk | Abweichung unter 1 % |
| Company-Verknüpfungen | Stichprobe 50 Kontakte | Alle korrekt verknüpft |
| Konversationstiefe | Zufällige Transkriptprüfung (20 Tickets) | Vollständige Thread-Integrität |
| Ticket-Zustände | Statusverteilung Intercom vs. Zendesk | Mapping-konforme Verteilung |
| Anhänge | 10 Tickets mit Anhängen prüfen | Alle abrufbar |
| Agenten-Zuordnung | Reporting nach Agent | Kein unerwarteter Admin-Fallback |
Validierungs-Checkliste:
Automatisierungen 1:1 zu migrieren ist verlockend und fast immer falsch. Zendesk-Trigger und Intercom-Workflows folgen unterschiedlichen Zustandsmodellen. Was in Zendesk funktioniert hat, erzeugt in Intercom oft unerwartetes Verhalten.
Nutze die Migration als Chance für ein Prozess-Redesign. Welche Automatisierungen haben wirklich funktioniert? Welche waren Workarounds für Systemgrenzen, die Intercom gar nicht hat?
Prioritätenschema für den Go-live:
Vorgehen: Alle bestehenden Automatisierungen dokumentieren → priorisieren → in Intercom neu bauen → einzeln testen → schrittweise aktivieren.
Profi-Tipp: Aktiviere beim Go-live nur Must-have-Automatisierungen. Jede zusätzliche Regel ist ein potenzieller Fehler im Cutover. Nice-to-have kommt in Woche zwei.
Erwartungsmanagement ist Teil des Projektmanagements. Diese Grenzen sind dokumentiert:
Alle nicht migrierbaren Daten dokumentieren und entscheiden, ob das Quellsystem als Archiv erhalten bleibt. Für DACH-Projekte mit DSGVO-Anforderungen ist das oft ohnehin Pflicht. Halte den Lesezugriff auf Zendesk mindestens so lange aufrecht, wie es die Aufbewahrungspflichten erfordern.
Ein Run Book ist die wichtigste Determinante für eine erfolgreiche Validierung. Ohne sequenzierte Schritte fehlt die Basis für konsistente Tests und klare Verantwortlichkeiten.
Rollenmatrix:
| Rolle | Verantwortung | Wer |
|---|---|---|
| Owner | Scope, Termine, Eskalation | COO / Ops Lead |
| Migration Engineer | Skripte, API, Datenqualität | Technischer Lead |
| QA | Stichproben, Fehlerprotokoll | Ops-Mitarbeiter |
| Support Lead | Agenten-Onboarding, Workflow-Tests | Support Manager |
| Kommunikationsowner | Interne und externe Kommunikation | Projektmanager |
| Compliance-Kontakt | DSGVO, Datenschutz | Datenschutzbeauftragter |
Timeline-Template (4–8 Wochen):
Abnahme-Checkliste:
Eine erfolgreiche Intercom-Datenmigration steht und fällt mit der Reihenfolge: Kontakte zuerst, dann Attribute, dann Konversationen oder Tickets, und niemals ohne UAT und dokumentierten Rollback-Plan.
| Thema | Details |
|---|---|
| Reihenfolge einhalten | Kontakte vor Attributen vor Konversationen/Tickets importieren, sonst schlagen Importe fehl. |
| Agenten vorab anlegen | Fehlende Agenten leiten alle Tickets an den migrierenden Admin um und verzerren das Reporting. |
| E-Mail-Benachrichtigungen deaktivieren | Vor jedem Import unter Einstellungen > Kanäle > E-Mail > Benachrichtigungen ausschalten. |
| UAT vor Produktionslauf | Mindestens 50–100 Datensätze im Test-Workspace prüfen, Fehlerquote unter 1 % anstreben. |
| Noliam als Migrations-Partner | Noliam übernimmt Run Book, Skript-Entwicklung, UAT und laufende Betreuung nach dem Go-live. |
Die meisten Migrations-Probleme, die wir sehen, sind keine technischen Fehler. Sie sind organisatorische.
Das häufigste Muster: Das Team startet den Import, bevor alle Agenten in Intercom angelegt sind. Ergebnis: Hunderte Tickets landen beim Admin, der die Migration ausgeführt hat. Das Reporting ist für Wochen verzerrt. Reparieren kostet mehr Zeit als die ursprüngliche Migration.
Das zweithäufigste Problem: E-Mail-Benachrichtigungen bleiben aktiv. Kunden erhalten Nachrichten zu Tickets, die vor zwei Jahren geschlossen wurden. Das ist kein technisches Versagen, das ist ein Kommunikations-GAU. Und er ist vollständig vermeidbar.
Und dann ist da noch die Automatisierungs-Falle. Teams kopieren ihre Zendesk-Trigger 1:1 in Intercom-Workflows, ohne zu prüfen, ob die Zustandsmodelle übereinstimmen. Sie tun es nicht. Was in Zendesk „On hold“ war, landet in Intercom als „In progress“, und plötzlich eskalieren SLA-Regeln für Tickets, die eigentlich ruhig warten sollten.
Was wirklich hilft: ein Run Book, das vor dem ersten Skript existiert. Nicht danach. Und ein Rollback-Plan, den alle kennen, nicht nur der Migration Engineer. Wer diese beiden Dokumente hat, übersteht auch einen schlechten Cutover-Tag.
Wer eine Intercom-Migration plant, hat zwei Optionen: selbst durch alle Fallstricke lernen oder mit einem Team starten, das diese Projekte kennt. Noliam übernimmt den gesamten Migrationsprozess für mittelständische Teams im DACH-Raum, von der ersten Mapping-Tabelle bis zum laufenden Betrieb nach dem Go-live.
Konkret bedeutet das: Clarity Audit (Scope und Risikobewertung), Fast Foundations (Skript-Entwicklung, UAT, Cutover-Begleitung) und Admin als laufender Service nach der Migration. Kein langer Einführungsprozess, kein Overhead. Du bekommst ein Run Book, das funktioniert, und ein Team, das nach dem Cutover nicht verschwindet.
Schreib uns direkt über die Intercom-Service-Seite oder buche ein erstes Gespräch. Wir schauen uns deinen Fall an und sagen dir ehrlich, was realistisch ist.
%20invert.svg)