Welche alten Tickets verdienen im neuen ITSM-Tool noch Vertrauen?

Ein neues ITSM-Tool wirkt oft wie ein sauberer Neustart. Die Oberflächen sind klarer, Workflows sind moderner und alte Umwege sollen verschwinden. Genau dann entsteht aber eine riskante Frage: Welche alten Tickets dürfen überhaupt mitkommen, ohne den neuen Betrieb sofort mit veralteten Entscheidungen, falschen Zuständigkeiten und schwachen Daten zu belasten?

ITSM steht für IT Service Management. Gemeint sind die Prozesse, mit denen IT-Organisationen Störungen, Anfragen, Änderungen, Wissen und Servicequalität steuern. Ein Toolwechsel ist deshalb nicht nur ein Softwareprojekt. Er entscheidet mit darüber, ob Service Desk, Betrieb, Fachbereiche und Management nach dem Start noch dieselbe Lage sehen.

Alte Tickets sind nicht automatisch Betriebswissen

In vielen Migrationsprojekten wird zuerst technisch gefragt, ob Tickets exportiert und importiert werden können. Das ist verständlich, aber zu kurz gedacht. Ein Ticket ist nur dann wertvoll, wenn es heute noch einen nachvollziehbaren Zweck erfüllt. Ein sauber geschlossener Vorfall aus dem Vorjahr kann als Lernfall nützlich sein. Ein halbfertiges Ticket mit falschem Besitzer, unklarem Status und fehlender Servicezuordnung wird im neuen System dagegen schnell zum Störsignal.

Die wichtigste Trennung lautet deshalb nicht alt gegen neu, sondern verwendbar gegen irreführend. Migration darf nicht bedeuten, jedes historische Feld blind in ein neues Datenmodell zu pressen. Sie muss klären, welche Informationen für Wiedererkennung, Nachweis, Auswertung, SLA-Bewertung, Knowledge Management oder Kundenkommunikation noch gebraucht werden.

Der Service Desk braucht weniger Ballast und mehr Kontext

Für den Service Desk ist ein alter Ticketbestand nur dann hilfreich, wenn er ähnliche Fälle schneller einordnet. Dafür reichen Betreff, Kategorie und Abschlussdatum selten aus. Entscheidend sind Ursache, betroffener Service, betroffene Nutzergruppe, Lösungsschritt, Eskalationsweg und die Frage, ob aus dem Fall ein Wissensartikel oder eine Problem-Management-Spur entstanden ist.

Wer stattdessen tausende alte Tickets ohne Bereinigung übernimmt, erzeugt Scheinsicherheit. Mitarbeitende finden Treffer, wissen aber nicht, ob sie aktuell, korrekt oder noch erlaubt sind. Das neue Tool sieht gefüllt aus, doch die Suche liefert alte Workarounds, nicht belastbares Betriebswissen. Genau an dieser Stelle verliert ein frisch eingeführtes ITSM-Tool Vertrauen.

Offene Tickets brauchen eine eigene Go-live-Entscheidung

Besonders kritisch sind offene Tickets. Sie gehören nicht einfach in einen Migrationsstapel, sondern in eine Vorabprüfung. Jedes offene Ticket braucht vor dem Go-live eine klare Entscheidung: wird es geschlossen, aktiv übernommen, an einen neuen Prozess übergeben oder als Altfall sichtbar markiert?

Diese Prüfung schützt vor zwei Fehlern. Der erste Fehler ist operativ: Ein echter Kundenfall verschwindet zwischen altem und neuem System. Der zweite Fehler ist organisatorisch: Ein übernommener Altfall trägt im neuen Tool eine Zuständigkeit, die es so gar nicht mehr gibt. Beides fällt nach dem Start oft erst auf, wenn der Kunde nachfragt oder ein Eskalationsbericht Lücken zeigt.

Historie darf nicht die neue Steuerung verzerren

Auch Reporting ist ein Risiko. Alte Prioritäten, Kategorien und Statuswerte passen selten eins zu eins zu einem neuen ITSM-Modell. Wenn historische Tickets ungeprüft in Dashboards laufen, können Kennzahlen nach dem Go-live falsch wirken. Plötzlich steigen Lösungszeiten, weil Altfälle mitwandern. Oder ein Service erscheint instabil, weil alte Kategorien nicht sauber auf neue Services abgebildet wurden.

Darum sollte historische Information häufig getrennt behandelt werden: aktuelle Arbeit im neuen Prozess, alte Fälle als Archiv oder Referenzbestand. Das Archiv muss auffindbar bleiben, aber es darf nicht ungekennzeichnet in operative Steuerungskennzahlen rutschen. Ein klarer Migrationsschnitt ist für das Management oft wertvoller als eine scheinbar vollständige, aber vermischte Historie.

Die praktische Prüfliste vor dem Import

Vor dem Import hilft eine einfache Redaktionslogik für Ticketdaten. Erstens: Welche Ticketarten werden noch operativ gebraucht? Zweitens: Welche Felder sind im neuen Tool Pflicht und wie werden alte Werte darauf abgebildet? Drittens: Welche offenen Fälle brauchen eine manuelle Entscheidung? Viertens: Welche historischen Fälle sollen nur lesbar archiviert werden? Fünftens: Welche Daten dürfen aus Datenschutz-, Vertrags- oder Qualitätsgründen nicht übernommen werden?

Diese Fragen klingen weniger technisch als ein Migrationsskript, sind aber entscheidend für den Start. Atlassian beschreibt bei Cloud-Migrationen zum Beispiel ausdrücklich, dass nicht jede Information gleich migriert wird und Vorarbeiten zur Daten- und Projektprüfung nötig sind. ServiceNow verweist bei Importen ebenfalls auf strukturierte Importmechanismen statt auf ein blindes Kopieren beliebiger Daten. Für ITSM-Verantwortliche heißt das: Die technische Migration braucht eine fachliche Importpolitik.

Ein gutes Migrationsziel ist Vertrauen im Alltag

Ein neues ITSM-Tool soll Arbeit klarer machen. Dafür muss der alte Ticketbestand nicht maximal groß sein, sondern nachvollziehbar. Wer Tickets übernimmt, sollte bei jedem Datenpaket erklären können, welchem Zweck es dient: laufende Arbeit, Nachweis, Lernen, Suche, Reporting oder Archiv.

Die beste Migration ist deshalb selten die vollständigste. Sie ist diejenige, bei der Service Desk, Betrieb und Management nach dem Go-live wissen, welche Informationen belastbar sind und welche nur historische Spuren darstellen. Genau dort entscheidet sich, ob das neue Tool als Arbeitsgrundlage akzeptiert wird oder nur als frische Oberfläche für alte Unklarheit.

Quellen: Atlassian Support zu Jira Cloud Migration Assistant und migrierten Daten, support.atlassian.com; ServiceNow Dokumentation zu Import Sets, servicenow.com; Atlassian ITSM-Grundlagen, atlassian.com. Stand: 05.07.2026.

Bildquelle: Pexels, Foto 4792285, Aktenordner als Symbol für zu prüfende Ticket- und Falldaten, https://www.pexels.com/photo/4792285/