Ein Kunde wandte sich kürzlich mit einem Problem an uns, das vielen wachsenden Dienstleistungsunternehmen bekannt vorkommt. Seine Arbeit verteilte sich auf ClickUp und Freshservice. Er wünschte sich differenziertere Berechtigungen für seine stark regulierten Kundenbeziehungen und die nötige Automatisierungskapazität, um einen konsistenten Kundenservice in großem Umfang zu gewährleisten. Die Entscheidung fiel auf HaloPSA, das beide Tools ersetzen sollte. Allerdings stieß man dabei auf ein Hindernis: Jahrelange historische Daten mussten erhalten bleiben, auf die die Kunden für die Kontinuität des Services angewiesen waren. Dies bedeutete, dass die größte Hürde beim Wechsel zu einem neuen Tool die unbeliebte Aufgabe der Datenmigration.
Die technologische Lösung ist meist schon klar, wenn wir hinzugezogen werden – es gibt eine Zielplattform, die besser geeignet wäre. Das Problem ist nicht das Tool selbst, sondern die Befürchtung, dass der Weg dorthin langsam, teuer und unvorhersehbar wird. Tickets gehen verloren. Reporting funktioniert nicht mehr. Teams rebellieren. Aufsichtsbehörden oder Kunden könnten Einwände erheben. Die Kosten steigen.
Doch all das ist nicht unvermeidlich. Richtig umgesetzt, sollte die Datenmigration kein Hindernis für den Betrieb Ihres Unternehmens mit den richtigen Tools darstellen. Konsolidierung kann – und sollte – eine Chance sein, die Geschäftsprozesse zu verbessern, anstatt nur Daten von A nach B zu verschieben. So gehen wir dabei vor.
Die zwei Hälften der Konsolidierung
Ein Konsolidierungsprojekt besteht aus zwei Hälften, die leicht zu verwechseln sind, aber von sehr unterschiedlicher Natur.
Der erste Schritt ist die Datenmigration – das Übertragen von Tickets, Kommentaren, Anhängen, Benutzern, benutzerdefinierten Feldern und historischen Datensätzen von den Quellplattformen in das Zielsystem. Dies ist eine anspruchsvolle technische Aufgabe. Bei komplexeren Fällen arbeitet man mit APIs, oft in einer festgelegten Reihenfolge, da Anhänge von Tickets, Kommentare von Benutzern, benutzerdefinierte Felder von Schemas usw. abhängen. Der Import von Flatfiles ist nur ein Teilschritt. Genau für solche Aufgaben gibt es spezialisierte Tools wie Help Desk Migration .
Der zweite Schritt ist die des Betriebsmodells – die Festlegung, wie die neue Plattform konkret für das Unternehmen funktionieren soll. Welche Arbeitsabläufe werden darüber abgewickelt? Wie sieht ein aussagekräftiges Reporting aus? Wer ist für welche Warteschlangen zuständig? Welche neuen Funktionen – Abrechnung und Rechnungsstellung, Kundenselbstbedienung, integriertes Änderungsmanagement – stehen jetzt zur Verfügung, die vorher nicht möglich waren, und welche davon sollten jetzt bzw. später aktiviert werden?
Diese beiden Hälften bedingen einander. Führt man nur die erste durch, erhält man das alte Chaos in einem neuen System. Führt man nur die zweite durch, bleibt man auf der Stelle stehen, da die historischen Daten nicht übernommen werden.
Die meisten Konsolidierungsprojekte scheitern daran, dass sie als reine Datenmigration betrachtet werden. Die größten Vorteile – und die größten Risiken – liegen im Betriebsmodell.
Warum Konsolidierung schwieriger ist als sie aussieht
Ein Teil der Komplexität ist rein technischer Natur, ein anderer organisatorischer. Die häufigsten Fallstricke:
1. Die Datenzuordnung ist unübersichtlich. Unterschiedliche Tools strukturieren dieselben Konzepte unterschiedlich. Statusnamen, Prioritätsstufen, Tickettypen, benutzerdefinierte Felder, Kategorien, Anfragetypen – fast nichts lässt sich eins zu eins abbilden. Die Schwierigkeit liegt nicht im Erstellen der Zuordnung, sondern in der Festlegung, wie diese aussehen soll. Dies zwingt zu Entscheidungen über das Betriebsmodell, bevor man darauf vorbereitet ist.
2. Das Agenten-/Benutzer-/Kundenmodell variiert je nach Tool. Einige Plattformen trennen interne Agenten, externe Benutzer und externe Kunden als drei separate Entitätstypen. Andere führen sie zusammen. Manche erlauben Agenten, externe Partner zu sein, andere nicht. Die Art und Weise, wie Freshservice Personen modelliert Halo , unterscheidet sich von der Jira Service Management . Die Migration von Benutzern ist selten ein einfaches Kopieren und Einfügen – es ist eine Übersetzung, und die hier getroffenen Entscheidungen prägen Berechtigungen, Berichte und Lizenzierung über Jahre hinweg.
3. Benutzerdefinierte Felder und Tickettypen sammeln sich an. Die meisten Quellsysteme weisen über Jahre hinweg akkumulierte Anpassungen auf, von denen einige nützlich, viele aber in Vergessenheit geraten sind. Eine vollständige Migration führt zu denselben Wartungsproblemen in einem neuen Tool. Die Migration nur der benötigten Daten erfordert hingegen intensive Gespräche mit denjenigen, die diese Felder erstellt haben.
4. Berechtigungen werden komplexer, nicht einfacher. Eine konsolidierte Plattform wird in der Regel von mehr Teams genutzt als jede einzelne Quelle zuvor. Das bedeutet neue Berechtigungsmodelle, neue Sichtbarkeitsregeln und höhere Anforderungen an die korrekte Implementierung – da Fehler deutlicher sichtbar werden.
5. Fehler treten zuerst im Reporting auf. Quellsysteme verfügen oft über Berichte, die von spezifischen Feldstrukturen, Status oder Namenskonventionen abhängen. Ändern sich diese im Zielsystem, funktionieren die Berichte nicht mehr – und die Stakeholder bemerken dies sofort. Reporting-Anforderungen sollten in die Migration integriert und nicht nachträglich hinzugefügt werden.
6. In der Regel benötigen Sie eine vollständige Testmigration. Keine Stichprobe, keine Teilmigration – eine vollständige UAT-Migration mit realen Daten, gegen das konfigurierte Zielsystem, durchgeführt von den Personen, die das neue System später tatsächlich nutzen werden. Hier erleben Sie die wirklichen Überraschungen: unerwartete Datenstrukturen, fehlerhafte Mapping-Entscheidungen und Integrationen, die angepasst werden müssen. Planen Sie dafür ausreichend Zeit und Kosten ein. Diese Phase zu überspringen, ist der teuerste Weg, bei der Konsolidierung Kosten zu sparen.
7. Regulatorische und Kundenanforderungen bestimmen oft, was erhalten bleiben muss. Manchmal möchte ein Kunde das alte System komplett ablösen – doch seine eigenen Kunden oder die Aufsichtsbehörden verlangen, dass historische Tickets, Kommentare und Anhänge aus Prüfungsgründen aufbewahrt werden. Das verändert den Migrationsumfang grundlegend, denn die Kommentar- und Anhangshistorie erfordert den größten API-Aufwand und eine besonders sorgfältige Planung. Wir hatten Projekte, bei denen die Datenaufbewahrungspflicht der Hauptgrund für die Komplexität des Migrationsdesigns war. Klären Sie dies frühzeitig.
Ein praktischer Ansatz
Jede von uns durchgeführte Konsolidierung folgte im Großen und Ganzen demselben Muster. Die Bezeichnungen sind weniger wichtig als die Reihenfolge.
1. Verstehen Sie die tatsächliche Nutzung. Bevor Sie mit der Datenzuordnung beginnen, ermitteln Sie, wie die Quellsysteme aktuell genutzt werden – nicht wie sie ursprünglich gedacht waren und nicht, was die Dokumentation besagt. Erstellen Sie Nutzungsberichte. Sprechen Sie mit den Anwendern. Sie werden in der Regel feststellen, dass ein wesentlicher Teil der Anpassungen im Quellsystem ungenutzt oder nicht mehr relevant ist. Das ist kein Problem, sondern eine Chance zur Konsolidierung auf ein einfacheres Zielsystem.
2. Definieren Sie das Zielbetriebsmodell. Diese Frage steht immer wieder im Mittelpunkt: Was soll die neue Plattform für das Unternehmen leisten, was die alten nicht leisten? Verbesserte SLA-Berichte? Integrierte Abrechnung und Rechnungsstellung? Self-Service-Anfrageportale? Änderungsmanagement mit Anbindung an eine CMDB? Jede dieser Funktionen beeinflusst die Konfiguration. Legen Sie fest, worauf Sie optimieren möchten, bevor Sie mit der Datenzuordnung beginnen.
3. Entwerfen Sie die Datenzuordnung anhand des neuen Modells, nicht des alten. Der häufigste Fehler ist die direkte Abbildung der Quelldatenstruktur in das Zielsystem. Der richtige Ansatz besteht darin, die Quelldaten dem Zielbetriebsmodell zuzuordnen – welche Felder ihren Platz erhalten, welche archiviert, welche gelöscht und welche zusammengeführt werden. Hier laufen die Entscheidungen zum Betriebsmodell und die technische Migration zusammen.
4. Führen Sie gezielte Testmigrationen durch. vor der Generalprobe – beispielsweise die Tickets eines einzelnen Teams, einen benutzerdefinierten Workflow oder eine Benutzergruppe –, um zu validieren, dass die Zuordnungslogik und die API-Sequenzierung durchgängig funktionieren. Diese kurzen Tests decken Probleme auf, solange sie noch kostengünstig zu beheben sind.
5. Führen Sie eine vollständige UAT-Migration durch. Die Generalprobe. Vollständige Daten, vollständige Konfiguration, echte Benutzer testen reale Szenarien. Planen Sie ausreichend Zeit ein. Diese Phase entscheidet darüber, ob die eigentliche Umstellung reibungslos oder chaotisch verläuft.
6. Gehen Sie mit einem Plan vor, nicht mit Hoffnung. Kommunikation, Rollback-Kriterien, Support-Abdeckung, Zuständigkeiten während des Umstellungszeitraums. Die Umstellung selbst verläuft meist unspektakulär, wenn die UAT gründlich war.
7. Unterstützen Sie die Einführung angemessen. Ein neues Tool, das einwandfrei funktioniert, aber niemand nutzt, ist ein gescheitertes Projekt. Für die erfolgreiche Einführung braucht es interne Befürworter, eine klare Dokumentation, praxisnahe Schulungen und die sichtbare Unterstützung der Führungsebene. Genau diesen Aspekt unterschätzen rein technische Migrationsprojekte immer wieder.
Ein aktuelles Beispiel
Die Migration musste drei verschiedene Datenformate berücksichtigen:
- Dokumente von ClickUp, wo die Struktur wikiähnlich war und an Projekte gebunden war
- Aufgaben aus ClickUp, wo das Modell verschachtelt und abhängigkeitsbewusst war
- Tickets von Freshservice, wobei das Modell ein klassisches Ticket-Schema mit Kommentaren, Anhängen und Anfragendenbeziehungen war
Jedes dieser Elemente musste abgebildet werden – nicht als exakte Kopie des ursprünglichen Zustands im Quellsystem, sondern im für das Zielsystem entwickelten Betriebsmodell. Dokumente wurden auf die eine Weise übertragen, Aufgaben auf die andere, Tickets auf eine dritte, und in manchen Fällen waren Querverweise nötig, da dieselben Geschäftsprozesse in verschiedenen Systemen abgebildet wurden.
Für diese Art von Arbeit gibt es eine Do-it-yourself-Alternative: das direkte Schreiben von Migrationsskripten für die Quell- und Ziel-APIs. Das haben wir bereits in früheren Projekten angewendet, und KI-Tools beschleunigen diesen Prozess. Bei Projekten mit unterschiedlichen Datenstrukturen, komplexen Zielkonfigurationen und einem engen Zeitplan minimiert der Einsatz der Spezialtools von Help Desk Migrationjedoch das Risiko der Datenübertragung erheblich und verkürzt die Projektlaufzeit deutlich. Dadurch konnten wir uns auf die eigentlichen Anforderungen des Kunden konzentrieren: die Konfiguration, die Automatisierungsplanung und das Berechtigungsmodell.
Für den Kunden war nicht das Ergebnis „Die Datenmigration war erfolgreich“ entscheidend. Vielmehr ging es darum, dass die neue Plattform ihm die notwendigen Kontrollmöglichkeiten und Automatisierungen bot – ohne die historischen Daten zu verlieren, auf die seine Kunden angewiesen waren. Genau das ist der Unterschied zwischen einem Datenmigrationsprojekt und einem Konsolidierungsprojekt.
Ähnliche Dynamiken beobachten wir, wenn das Ziel eine PSA-Plattform ist – sie integriert Abrechnung, Rechnungsstellung, Projektrentabilitätsanalyse und Zeiterfassung in die operative Arbeit. Ein praktisches Beispiel für die Integration in HaloPSA finden Sie in unserer aktuellen Fallstudie zu bdq.cloud.
Wo passt Help Desk Migration
Wir geben nicht vor, ein Unternehmen für Datenmigrationstools zu sein. Die technische Arbeit, Migrationsskripte für verschiedene Plattform-APIs in der richtigen Reihenfolge zu erstellen und auszuführen sowie Sonderfälle wie Anhänge, Kommentare und Benutzerzuordnungen zu berücksichtigen – das ist eine Spezialdisziplin, und Help Desk Migration ist darin wirklich gut.
Genauso wichtig ist, dass spezialisierte Tools die Kosten und den Zeitplan der Datenmigration planbar machen. Die Migrationskosten sollten ein fester Kostenposten und kein unkalkulierbares Risiko darstellen – und wenn sie bekannt sind, lässt sich die Wirtschaftlichkeitsberechnung für die umfassendere Konsolidierung deutlich leichter genehmigen.
Der Punkt, zu dem wir immer wieder zurückkehren
Datenmigration sollte kein Hindernis für den erfolgreichen Einsatz der richtigen Tools in Ihrem Unternehmen darstellen. Sie kann zwar kostspielig, zeitaufwändig und riskant sein – doch mit den richtigen Partnern und dem richtigen Ansatz ist dies kein Grund, auf einer Plattform zu verharren, die Ihre Bedürfnisse nicht mehr erfüllt.
Unternehmen, die den größten Nutzen aus der Konsolidierung ziehen, nutzen sie als Chance zur Verbesserung ihres Betriebsmodells und nicht nur zur Datenübertragung. Der geschäftliche Mehrwert liegt nicht in den technischen Details von API-Skripten und Feldzuordnungen. Er liegt vielmehr in besseren Berichten, optimierten Prozessen, verbesserter Automatisierung und Teams, die die relevanten Aufgaben erkennen und darauf reagieren können.
Wenn Sie eine Konsolidierung in Erwägung ziehen, sollten Sie sich zunächst nicht fragen: „Wie übertragen wir die Daten?“, sondern: „Wie soll das Ergebnis aussehen?“ Die Datenmigration selbst ergibt sich dann von selbst.
Über BDQ
BDQ Cloud ist eine IT-Beratung mit Sitz in London, die sich auf die Migration, Konsolidierung und Modernisierung von Service-Management-Plattformen spezialisiert hat. Wir arbeiten mit HaloITSM, Atlassian, Freshworks, Asana und weiteren modernen Tools und kooperieren mit Help Desk Migration für die technische Datenmigration, die unseren Konsolidierungsprojekten zugrunde liegt. Wenn Sie eine konkrete Konsolidierungsherausforderung besprechen möchten, bieten wir Ihnen eine 30-minütige Migrationsanalyse an, die sich auf das Betriebsmodell und die angestrebten Ergebnisse konzentriert und nicht nur auf die Daten.
