Standard- und eigene Datenfelder sind die Basis jedes Helpdesks. Sie bestimmen Ticketstrukturen, Workflows, Berichte und Leistungswerte. Beim Systemwechsel ist die Feldzuordnung so wichtig wie der Datentransfer selbst.
Kurz gesagt: Help Desk Migration macht Datenmapping und Umzug sicherer und leichter — sofern man die Regeln befolgt.
In diesem Leitfaden führen wir Sie durch die Grundprinzipien.
Standard- vs. Benutzerfelder bei Help Desk Migration
Jeder Helpdesk basiert auf Feldern. Manche sind im System; andere erstellen Sie selbst.
Standardfelder
In Zendesk sind das etwa: Anforderer, Bearbeiter, CCs, Betreff, Text, Status, Typ, Priorität.
Sie bilden das strukturelle Fundament jedes Tickets.
Benutzerfelder
Das sind z. B. Bestell-ID, Abo-Plan, Produkttyp, SLA-Stufe etc.
Sie erfassen Informationen, die speziell auf Ihren Arbeitsablauf zugeschnitten sind, und ermöglichen maßgeschneiderte Automatisierung und Berichterstellung.
Help Desk Migration überträgt beide Feldtypen.
Da diese das Datengerüst bilden, ist die korrekte Zuordnung beim Wechsel kritisch. Hier beginnen oft die Sorgen der Kunden.
Warum Datenmapping die größte Migrationsangst schürt
Bei Help Desk Migration entstehen die meisten Risiken während der Feldzuordnung.
Nutzer befürchten:
- Verlust an Detailtiefe (z. B. Multi-Select wird zu Single-Select mit nur einem Wert)
- Geänderte oder fehlerhafte Ticketstatus
- Fehlende Fahrkarten
- Doppelte Benutzer oder Organisationen
- Unerwünschte Automatisierungsauslöser
Die gute Nachricht? All diese Risiken, ob Datenverlust oder Auslöser, sind durch Vorbereitung und Konfiguration kontrollierbar. Man muss nur wissen, was das Tool kann.
Beginnen wir beim Basiswissen: Welche Objekte überträgt Help Desk Migration?
Welche Objekte ordnet Help Desk Migration zu?
Help Desk Migration unterstützt den Transfer von Standard- und eigenen Feldern in Tickets, Problemen, Änderungen, Kontakten, Firmen, Artikeln und PM-Aufgaben plattformübergreifend.
Unterstützte Feldtypen in Help Desk Migration
Das Tool migriert alle gängigen Feldtypen:
- Felder mit Vorgaben. Inklusive Dropdown, Checkbox und Mehrfachauswahl
(z. B. Problemtyp, Region, SLA-Stufe). Im Migration Wizard erscheinen sie als Dropdown. - Text / String. Freitextfelder für kurze oder lange Texte.
- Numerisch. Felder, die Zahlen wie IDs, Mengen oder interne Referenzen speichern.
- Datum. Felder, die Kalenderdaten speichern (z. B. Verlängerungsdatum, Vertragsbeginn, benutzerdefinierte Frist).
- Regex-Felder. Felder, die anhand einer musterbasierten Regel validiert werden. Beispielsweise ein Feld, das nur eine korrekt formatierte Bestellnummer wie ORD-12345 akzeptiert. Diese Felder werden zur plattformübergreifenden Zuordnung angezeigt, ihre Daten werden jedoch nur für Zendesk und Pylon , da dort die Musterlogik vollständig unterstützt wird.
- Formelfelder. Felder, deren Werte automatisch berechnet werden. Zum Beispiel Gesamtkosten aus Menge × Preis oder ein Prioritätswert. In einigen Plattformen sind sie als Feldtyp verfügbar. Ob der berechnete Wert wandert, hängt davon ab, wie die Plattform diese Daten speichert.
Der erste Schritt zur korrekten Zuordnung dieser Feldtypen beginnt mit einer wichtigen Regel.
Grundregel: Standard- und Eigenfelder nach Typ zuordnen
Präzise Migration beginnt bei der Konsistenz der Feldtypen. Achten Sie beim Mapping von Standard- und Eigenfeldern auf Übereinstimmung zwischen Quell- und Zielsystem.
- Ein Textfeld kann nur einem anderen Textfeld zugeordnet werden.
- Ein numerisches Feld muss einem anderen numerischen Feld zugeordnet werden.
- Ein Dropdown-Feld muss mit einem Dropdown-Feld mit entsprechenden Werten verbunden sein.
- Ein numerisches Feld oder ein Datumsfeld kann auch einem Textfeld auf der Zielseite zugeordnet werden.
- Und so weiter.
Wenn die Datentypen nicht übereinstimmen, kann es zu Problemen bei der Datenmigration oder zum Verlust der Datenstruktur kommen.
Auswahlfelder: Mapping von Dropdown (Einzelwahl), Mehrfachauswahl und Checkboxen
Das Dropdown-Mapping erfordert den Abgleich einzelner Optionswerte, nicht nur des Feldnamens. Das gilt für alle Auswahltypen.
Es reicht nicht, „Problemtyp“ mit „Kategorie“ zu verknüpfen. Jede Option im Feld muss ihrem Gegenstück zugeordnet sein (z. B. „Vorfall“ zu „Vorfall“ oder „Problem“ zu „Problem“).
Achten Sie beim Mapping im Wizard zudem auf Einzelwahl- (nur eine Option) und Mehrfachauswahl-Felder (mehrere Optionen). Einzel > Einzel und Einzel > Mehrfach funktionieren wie erwartet. Bei Mehrfach > Einzel wird jedoch nur der erste gewählte Wert übertragen.
Umgang mit nicht zugeordneten Optionen bei Checkbox-, Mehrfach- und Dropdown-Werten
Manchmal schlagen Feldwerte bei der Migration fehl, weil sie zwischen Quell- und Zielsystem nicht exakt übereinstimmen.
Falls nötig, passt unser Team die Konfiguration an, damit jeder Wert dort landet, wo er hingehört.
Felder, die nicht migriert werden
Dropdown-Felder ohne Optionen erscheinen gar nicht erst in der Mapping-Oberfläche; dies ist ein häufiges Problem bei diesen Feldern.
Zudem werden gelöschte Dropdown-Werte nicht im Interface angezeigt. Ein Ticket kann zwar noch einen alten Wert enthalten, doch wurde dieser aus der aktuellen Liste entfernt, erscheint er nicht beim Mapping. In solchen Fällen ordnet das System diese Datensätze automatisch dem Standard-Dropdown-Wert im Zielsystem zu.
Da keine Werte zum Abgleich vorhanden sind, schließt das System diese automatisch aus der Mapping-UI aus.
Erstellung von Eigenfeldern vor der Migration
Eigenfelder müssen im Zielsystem existieren, bevor sie zugeordnet werden können.
Gibt es kein Feld auf der Zielseite, fehlt die Verbindung und Daten fließen nicht korrekt. Daher ist die frühe Vorbereitung von Eigenfeldern ein kritischer Migrationsschritt.
Doch es gibt Ausnahmen.
Plattformspezifische Logik zur Felderstellung
Meist müssen Kunden Felder vorab direkt im Ziel-Helpdesk anlegen.
Beachten Sie diese plattformspezifischen Mapping-Regeln:
Freshdesk
Auswahlfelder werden als custom_dropdown erstellt.
Zendesk
Das System prüft, ob das Feld ein Tagger (Einzelwahl) oder Multi-Select sein soll, und erstellt es.
Intercom
Auswahlfelder werden mit dem Typ list angelegt.
Jira Service Management
Das System bestimmt basierend auf der Quellstruktur, ob es ein Einzel- oder Mehrfachauswahltyp wird.
Zudem kann das Erstellen via Wizard bei Dropdowns mit hunderten Werten Fehler melden. Teils wird das Feld erstellt, aber nicht dem Projekt zugefügt; ein Techniker muss dies dann prüfen.
Intercom
Die API begrenzt Dropdowns auf 250 Werte, das Interface unterstützt jedoch oft mehr.
Wichtige Limits für alle Plattformen
Duplikate können nicht via Wizard erstellt werden; Dropdowns behalten die Optionen des Quellsystems.
Einschränkungen beim Kontakt- und Firmen-Mapping
Help Desk Migration unterstützt den Transfer von Eigenfeldern für Kontakte und Firmen bei ausgewählten Migrationspaaren.
Prüfen Sie unter „Entität → Daten“, ob der Transfer in Ihrem Fall unterstützt wird.
Steht „Describe - 1“ neben den Eigenfeldern für Kontakt oder Firma, erfolgt die Migration im Standard-Automatisierungsfluss.
Falls nicht, werden diese Felder nicht automatisch übertragen, selbst wenn identische Felder im Zielsystem existieren. In solchen Fällen bietet unser Technik-Team eine individuelle Anpassung an.
Kunden sehen bei ihrem spezifischen Plattformpaar nur die Standardfelder zum Mapping (wie Name, E-Mail etc.), falls der Transfer von Eigenfeldern für Kontakte und Firmen nicht unterstützt wird.
Migration von abhängigen Feldern auf mehreren Ebenen
Ein mehrstufiges Feld (auch verschachteltes oder abhängiges Feld genannt) enthält mehrere Ebenen von Optionen. Die auf der ersten Ebene getroffene Auswahl bestimmt, welche Optionen auf der nächsten Ebene verfügbar sind.
Ein einfaches Beispiel ist ein Adressfeld:
Ebene 1 → Land
Ebene 2 → Stadt (gefiltert nach Land)
Ebene 3 → Straße (gefiltert nach Stadt)
Jede Auswahl verringert die nächste Auswahlmöglichkeit.
Warum Mehrebenfelder Probleme beim Mapping machen
Herausforderungen entstehen oft, wenn die Struktur im Zielsystem nicht exakt nachgebildet wird.
Wie Help Desk Migration Mehrebenfelder ohne Ziel-Support handhabt
Falls das Quellsystem ein mehrstufiges Feld enthält, die Zielplattform aber keine abhängigen Felder unterstützt, stehen praktische Umgehungsmöglichkeiten zur Verfügung.
Option 1: Aufteilung eines mehrstufigen Felds in separate Dropdown-Felder
Falls das Quellsystem über ein mehrstufiges Feld verfügt, das Zielsystem jedoch nicht, kann der Kunde im Zielsystem separate Dropdown-Felder erstellen – eines für jede Ebene.
Zum Beispiel:
- Land (Auswahlmenü)
- Stadt (Auswahlmenü)
- Straße (Auswahlmenü)
Bei dieser Konfiguration werden Optionen aus demselben Quellfeld mehreren Zielfeldern zugeordnet, und zwar entsprechend ihrer jeweiligen Ebenen.
Option 2: Mehrere Felder in ein mehrstufiges Feld abbilden
Wenn das Quellsystem separate Dropdown-Felder (z. B. Land, Stadt, Straße) besitzt, das Zielsystem aber ein einzelnes mehrstufiges Feld unterstützt, ist eine benutzerdefinierte Zuordnung möglich.
In diesem Fall kann unser Team die Zuordnung konfigurieren.
Der Kunde muss eine strukturierte Mapping-Datei bereitstellen, die vorgibt, wie die Ebenen kombiniert werden sollen.
Mehrstufige Felder erfordern besondere Aufmerksamkeit, da sie nicht nur Werte, sondern auch strukturierte Beziehungen zwischen diesen speichern. Eine sorgfältige Vorbereitung stellt sicher, dass diese Struktur während der Migration nicht verloren geht.
Regeln zum Überspringen, Pflichtfelder und Migration von Standardwerten
Beim Mapping geht es nicht nur um das Abgleichen. Es geht auch darum, welche Daten im Zielsystem erscheinen — konsistent und skaliert.
Feld überspringen
Nur für optionale Felder verfügbar.
Diese Option lässt das Zielfeld in allen migrierten Tickets leer, unabhängig vom Quellwert.
Verwenden Sie „Dieses Feld in Migrationen überspringen“, wenn:
- Das Feld ist im Zielsystem vorhanden, aber nicht mehr relevant.
- Das Feld ist optional und kann bedenkenlos leer gelassen werden.
Standardwert
Diese Option lässt das Zielfeld in allen migrierten Tickets leer, unabhängig vom Quellwert.
Wählen Sie z. B. Typ → Problem, erhält jedes migrierte Ticket den Wert „Problem“, egal wie der Originalwert lautete.
Die Option „Standardwert“ ist nützlich bei:
- Standardisierung alter Daten
- Wechsel zu einer vereinfachten Feldstruktur.
- Anwendung eines neuen Kategorisierungsmodells.
Verwendung für Standardwerte oder leere Werte
Nur verfügbar, wenn Pflichtfelder zugeordnet werden.
Diese Option füllt ein erforderliches Zielfeld standardmäßig nur dann aus, wenn das zugeordnete Quellfeld in einem bestimmten Ticket leer ist.
Das heisst:
- Wenn der Quellwert existiert → wird er normal migriert.
- Ist der Quellwert leer, wird der ausgewählte Ausweichwert angewendet.
Dadurch werden Migrationsfehler vermieden und gleichzeitig vorhandene reale Daten erhalten.
Kein Ausfüllen erforderlich
Verfügbar für optionale Feldzuordnung.
Wenn in der Quelle bestimmte zugeordnete Werte ausgewählt sind, bleibt das Zielfeld bei dieser Option leer.
Es ist nützlich, wenn:
- Einige Quellwerte sind nicht mehr relevant.
- Sie möchten bestimmte Kategorien gezielt von der Migration ausschließen.
- Das Feld ist optional und muss unter bestimmten Bedingungen leer bleiben.
Diese Steuerelemente geben Ihnen die Flexibilität, Daten während des Umzugs zu verfeinern und zu standardisieren.
Häufige Mapping-Fehler und deren Behebung
Die meisten Probleme entstehen durch zwei Ursachen: Duplikate im Zielsystem oder Pflichtfeld-Bedingungen, die das Erstellen oder Schließen von Tickets blockieren.
Namensduplikat
Dieser Fehler tritt auf, wenn im Zielsystem bereits ein Feld mit demselben Namen existiert.
Auch wenn man es nicht sofort sieht, könnte das Feld:
- Existieren, aber inaktiv sein
- Zu einem anderen Projekt gehören (in projektbasierten Systemen)
- Durch Konfigurationseinstellungen ausgeblendet werden
So beheben Sie das Problem:
- Prüfen Sie, ob das Feld im Ziel bereits existiert.
- Aktivieren oder verwenden Sie das vorhandene Feld wieder, anstatt ein neues zu erstellen.
- Bei projektbasierten Plattformen muss sichergestellt werden, dass das Feld dem richtigen Projekt hinzugefügt wird.
Erforderlich = Fehlendes Feld
Dieser Fehler tritt auf, wenn ein Pflichtfeld im Zielsystem beim Umzug keinen Wert erhält.
Ein Feld kann erforderlich sein:
- Für die Ticketerstellung
- Ticketschließung
- Aufgrund bestimmter Regeln oder Bedingungen
Ein System könnte beispielsweise das Schließen eines Tickets verhindern, wenn ein Pflichtfeld (z. B. Lösungsart) leer ist. Diese Anforderungen lassen sich direkt in den Feldeinstellungen konfigurieren oder über Workflow-Bedingungen steuern.
Manchmal wird ein Feld während der Zuordnung nicht als erforderlich angezeigt, da bedingte Regeln nur in bestimmten Szenarien gelten. Nach der Migration können diese Regeln jedoch Ticketaktualisierungen blockieren, wenn das Feld leer ist.
So beheben Sie den Fehler „Pflichtfeld“:
- Stellen Sie sicher, dass alle erforderlichen Felder zugeordnet sind.
- Verwenden Sie „Standardwert“ oder „Für Standard- oder leere Werte verwenden“, um leere Pflichtfelder zu vermeiden.
- Überprüfen Sie die Feldbedingungen und Workflow-Regeln, bevor Sie die vollständige Migration starten.
Das Bewusstsein für diese beiden Fehlertypen hilft, Unterbrechungen zu vermeiden und die Migration von Anfang bis Ende reibungslos zu gestalten.
Demo-Migration als Validierung (Keine Theorie)
Eine Demo zeigt, wie Ihre Regeln greifen, bevor Sie die Vollmigration starten.
Unbegrenzte Gratis-Demo
Die migriert 20 zufällige Tickets samt Anhängen sowie 20 Artikel. Ein Bericht zeigt danach exakt, welche Datensätze Erfolg hatten und welche scheiterten.
Sie können die Demo beliebig oft wiederholen, bis alles korrekt aussieht.
Einmalige Custom-Demo
Statt Zufallsdaten erlaubt die Custom-Demo das Wählen spezifischer Tickets. Dies hilft, Grenzfälle vor der eigentlichen Vollmigration zu validieren.
Checkliste für das Field Mapping
Prüfen Sie vor dem Start der Vollmigration diese Kernpunkte:
- Feldtypen stimmen überein (Text → Text, Dropdown → Dropdown usw.).
- Alle erforderlichen Zielfelder sind zugeordnet oder verfügen über Ausweichwerte.
- Benutzerdefinierte Felder sind im Ziel vorhanden (oder werden, sofern unterstützt, über den Assistenten erstellt).
- Die Optionen für Einzel- und Mehrfachauswahl sind aufeinander abgestimmt, es bleiben keine nicht zugewiesenen Werte übrig.
- Die Unterstützung für benutzerdefinierte Kontakt- und Firmenfelder wurde überprüft (Entität → Daten).
- Mehrstufige Felder sind korrekt strukturiert oder angepasst.
- Im Ziel dürfen keine doppelten Felder oder blockierende Workflow-Bedingungen vorhanden sein.
- Eine kostenlose Demo (und bei Bedarf eine kundenspezifische Demo) wurde durchgeführt und validiert.
Die Feldzuordnung ist nicht nur ein technischer Schritt. Sie sichert die Automatisierungslogik, die Genauigkeit der Berichte und die täglichen Arbeitsabläufe nach der Migration. Eine sorgfältige Checkliste heute verhindert strukturelle Nachbesserungen morgen.
FAQs zum Mapping von Standard- und Eigenfeldern
Help Desk Migration ordnet Felder durch den Abgleich kompatibler Typen zwischen Quell- und Zielsystem zu. Felder werden nach Typ (Text, Dropdown, Zahl, Datum etc.) ausgerichtet; Dropdown-Werte werden Option für Option gemappt. Alles ist per Gratis-Demo vor der Vollmigration prüfbar.
Ja, meist müssen Eigenfelder im Ziel existieren, bevor sie zugeordnet werden können. Bei vielen Plattformen lassen sich diese jedoch direkt im Migration Wizard während des Setups anlegen.
Das Tool unterstützt Text, Numerik, Datum, Dropdown (Einzelwahl), Mehrfachauswahl, Checkbox, Regex- und Formelfelder. Fortgeschrittene Typen wie Regex oder Formeln können plattformspezifische Limits haben.
Stimmen die Typen nicht überein (z. B. Dropdown auf Textfeld), können Daten fehlerhaft übertragen werden oder die Struktur verlieren. Die Regel „Mapping nach Typ“ sichert einen präzisen Datentransfer.
Jede Option in einem Dropdown, einer Checkbox oder Mehrfachauswahl muss einzeln ihrem Gegenstück im Ziel zugeordnet werden. Wird ein Mehrfachauswahl- auf ein Einzelwahl-Feld gemappt, wandert nur der erste Wert.
Dies erscheint, wenn Quell-Dropdown-Werte keine Entsprechung im Ziel haben. Diese Werte werden vor der Vollmigration markiert, damit Sie diese vorab korrigieren und Datenlücken vermeiden können.
Dieser Transfer wird nur für spezifische Plattform-Paare unterstützt. Die Verfügbarkeit prüfen Sie unter Entität → Daten. Falls nicht unterstützt, bietet das Technik-Team individuelle Anpassungsoptionen an.
Unterstützen beide Seiten diese Felder, müssen sie identisch strukturiert sein. Fehlt der Support im Ziel, können Daten in separate Dropdowns gesplittet oder per Custom-Mapping konfiguriert werden.
Häufig sind doppelte Feldnamen im Ziel oder Pflichtfelder ohne Werte. Dies lässt sich durch Nutzung bestehender Felder, Mapping aller Pflichtfelder oder Anwendung von Standard-Ersatzwerten lösen.
Die Demo validiert Ihr Mapping mit echten Datensätzen. Sie können unbegrenzt Gratis-Demos oder eine Custom-Demo für spezifische Tickets nutzen. Dies stellt sicher, dass alles vor dem Gesamtransfer korrekt läuft.
